Sorry, the definition of filterArray should read:
filterArray f z b list =
array b [ i := foldr f z [ x | j:=x <- list, i==j ]
| i <- indices b
]
-- Thomas
> I agree, but I also agree with Lennart that both sorts of arrays are needed.
Yes, I agree on that; language design is, as always, a compromise
between the desirable semantics (in this case, as lazy as possible),
and desirable efficency, and we don't know yet how to make lazy arrays
a la LML a
Did I reach the whole list?
My question concerns this:
>
> Furthermore, it makes perfect sense to declare a new type isomorphic to
> an existing function type. So whereas it is *not* ok to write
>
> data New a b = MkNew !(a->b)-- ! means strict
>
> (because of previous disc
>
> Thomas Johnsson says:
>
> >If I recall correctly, the := to be used in array comprehensions was a
> >consession to the FORTRAN/Id/Sisal community, so that array comprehensions
> >would look more like they were used to.
>
> Both Arvind and I think this is notation is awful, and
> >Let me just remind people what the LML arrays does:
> >
> >example:
> >lmlarray 1 3 f list =
> >array [ 1:= f [ x | (1,x) <- list],
> >2:= f [ x | (2,x) <- list],
> >3:= f [ x | (3,x) <- list]
> > ]
> Although Warren's suggestion is logical, it's not in any way standard.
> (Most of the places where we have two ways of doing something, they are
> both standard.)
The Clean people use this notation rather than the more common
arrow notation.
Kevin
Mark Jones gives the following alternative definitions for Lists:
> type List a b = b -> (a -> b -> b) -> b
> nil :: List a b
> nil f g= f
> cons :: a -> List a b -> List a b
> cons x xs f g = g x (xs f g)
> fold :: b -> (a -> b ->
>But just because they call it `lazy' doesn't mean that it really is
>the essence of laziness. I prefer to use the more neutral name `lifted
>lambda calculus' for their calculus.
I disagree. In the simplest case (just lambdas, variables and applications,
i.e. no explicit constructors), it is *
