At 09:25 -0400 1999/04/29, Chris Okasaki wrote:
>For example, if you have an implementation of ordered sets represented as
>unbalanced binary search trees, then the abstract fold probably has a type
>something like
>
> abs_fold :: (a -> b -> b) -> b -> Set a -> b
>
>whereas the concrete fold (whi
Me:
>> There is another good reason to have a total order: it makes reduction
>> operations (folds) over the structure well-defined.
Kevin Atkinson:
>But how important is having a fold well defined. For many common
>numerical operations such as summing a list, taking the product of a
>list, etc.
Bjorn Lisper wrote:
>
> There is another good reason to have a total order: it makes reduction
> operations (folds) over the structure well-defined.
But how important is having a fold well defined. For many common
numerical operations such as summing a list, taking the product of a
list, etc. T
John Launchbury wrote:
> test :: [Int]
> test = do (x,z) <- [(y,1),(2*y,2), (3*y,3)]
> Just y <- map isEven [z .. 2*z]
> return (x+y)
>
> isEven x = if even x then Just x else Nothing
I would expect this to be equivalent to
test = do (~(x,z), ~(Just y)) <-
Hi Sarah,
I'd like to respond to your questions about licensing etc., at least
as far as Hugs is concerned. Our goal is to make our tools as widely
useful as possible, and with that in mind, we have been considering
matters of licensing very carefully. The most recent versions of
Hugs(*) are di
At 10:59 +0200 1999/04/29, Bjorn Lisper wrote:
>Just a final comment on total orders on sets: this makes sense, as regards
>operations where the order is important for the semantics, only if the
>elements of the set are drawn from an enumerable set. It would not be very
>sensible to, for instance,
This has been reposted to haskell.org after it didn't seem to get through
via dcs.ed.ac.uk. If you get this twice, many apologies.
After a few years writing VC++ for banks and financial institutions, I've
now reached a point where I have found a valid excuse to use a functional
p
Hans Aberg:
>The total order is needed in order to make the balanced trees used for the
>sets/maps. So what I have in my mind is that somehow Haskell produces a
>default total order on elements. This could be the declaration order or an
>alphabetical order, or whatever (and it is nice to humans t
Dave Tweed wrote:
> For me what would make an STL-like library useful would be having
> collections of algorithms available which operate on any `bulk type' for
> which they make sense, but I suspect that to be suitably efficient
> handwritten versions would be needed for each type. (Folding over
Laszlo Nemeth wrote:
> > For me what would make an STL-like library useful would be having
> > collections of algorithms available which operate on any `bulk type' for
> > which they make sense, but I suspect that to be suitably efficient
> > handwritten versions would be needed for each type. (F
John Launchbury posed a nice puzzle about
mutual recursive bindings in the do notation:
test :: [Int]
test = do (x,z) <- [(y,1),(2*y,2), (3*y,3)]
Just y <- map isEven [z .. 2*z]
return (x+y)
isEven x = if even x then Just x else Nothing
---
> I would be great to get to know which address one should use for the
> Haskell mailing list. Could not somebody please post info
> about that to
> that list, as there has been problems with that in the past
> (haskell.org
> not working, etc.).
The official address for the haskell mailing list
12 matches
Mail list logo