Re: [Haskell] getArgs, maxBound, float division: pure functions?

2005-10-12 Thread Bjorn Lisper
John Meacham: >On Wed, Oct 12, 2005 at 12:05:39AM -0400, David Menendez wrote: >> In principle, you could use seperate types to distinguish floats with >> different rounding modes, but I imagine this would be difficult or >> annoying to implement. > >I think it would make more sense to have differe

RE: [Haskell] getArgs, maxBound, float division: pure functions?

2005-10-12 Thread Ralf Lammel
Just for the record, Cobol has a long history of specifying local rounding options. More recently, the options for rounding are elaborated in the context of adding standard arithmetic. http://www.cobolportal.com/j4/files/05-0152.doc Ralf > -Original Message- > From: [EMAIL PROTECTED] [ma

[Haskell] Re: How to zip folds: A library of fold transformers

2005-10-12 Thread oleg
Correction: > We show how to merge two folds into another fold `elementwise'. ... We > need recursive types -- but again, never value recursion. There is no need for recursive types, actually. Higher-rank types are still present, which we need for fold anyway. Introducing recursive types wasn't

[Haskell] ANNOUNCE: Haskell XML Toolbox Version 5.3

2005-10-12 Thread Uwe Schmidt
Haskell XML Toolbox 5.3 I would like to announce a new version of the Haskell XML Toolbox for processing XML. main new features: * a cookbook for using the new arrow programming interface of the toolbox * an integrated Relax NG validator implemented with the arrow interface More information an

[Haskell] setSocketOption unusable?

2005-10-12 Thread John Goerzen
I'm wanting to set the SO_RCVTIMEO and SO_SNDTIMEO options on a socket from Haskell. socket(7) say that these take a struct timeval ad a parameter. (Other options, such as SO_LONGER, also could have this problem.) In Haskell, we see: setSocketOption :: Socket -> SocketOption -> Int -> IO () No

[Haskell] Interest in helping w/ Haskell standard

2005-10-12 Thread Isaac Jones
At the end of the Haskell Workshop at ICFP, we had the traditional "Future of Haskell" discussion (chaired by Andres Loeh). One of the main topics was the perceived need of a new standard, because the Haskell 98 standard is quite old already, and Haskell has evolved in the meantime, leading to a si

[Haskell] Re: [Haskell-cafe] Interest in helping w/ Haskell standard

2005-10-12 Thread Sebastian Sylvan
On 10/13/05, Isaac Jones <[EMAIL PROTECTED]> wrote: > At the end of the Haskell Workshop at ICFP, we had the traditional > "Future of Haskell" discussion (chaired by Andres Loeh). One of the > main topics was the perceived need of a new standard, because the > Haskell 98 standard is quite old alrea

Re: [Haskell] Re: [Haskell-cafe] Interest in helping w/ Haskell standard

2005-10-12 Thread Isaac Jones
(Trimming CC list. Maybe we should take this to haskell-cafe?) Sebastian Sylvan <[EMAIL PROTECTED]> writes: (snip quotes) > I'm wondering what "incremental and moderate" extension means? > Does it mean "completely backwards compatible" or can it mean > completely new features including ones whic

[Haskell] PROPOSAL: class aliases

2005-10-12 Thread John Meacham
= Class Aliases = This is a proposal for a language extension which will hopefully mitigate the issues holding back evolution of the standard prelude as well as provide useful class abstraction capabilities in general. It's main goals are to * remove the false tension between the granularity of

Re: [Haskell] PROPOSAL: class aliases

2005-10-12 Thread Philippa Cowderoy
On Wed, 12 Oct 2005, John Meacham wrote: ideally we would want to split it up like so (but with more mathematically precise names): Might it also be reasonable to provide less mathematical names for some classes, and possibly allow users to let the compiler know which ones they find more re

Re: [Haskell] PROPOSAL: class aliases

2005-10-12 Thread John Meacham
On Thu, Oct 13, 2005 at 01:14:19AM +0100, Philippa Cowderoy wrote: > On Wed, 12 Oct 2005, John Meacham wrote: > > >ideally we would want to split it up like so (but with more mathematically > >precise names): > > > > Might it also be reasonable to provide less mathematical names for some > class