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
>
> 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]
> > ]
> >But I think we can have the cake and eat it too, if we get rid of the
> >restriction (which I never liked) that operators beginning with : must be a
> >constructor: just define
> >a := b = (a,b)
>
> Unfortunately that won't work if := had been used in patterns. I think
> backward compatibil
> >But I think we can have the cake and eat it too, if we get rid of the
> >restriction (which I never liked) that operators beginning with : must be a
> >constructor: just define
> >a := b = (a,b)
>
> Unfortunately that won't work if := had been used in patterns.
Nonsense. Of course construc
>But I think we can have the cake and eat it too, if we get rid of the
>restriction (which I never liked) that operators beginning with : must be a
>constructor: just define
>a := b = (a,b)
Unfortunately that won't work if := had been used in patterns. I think
backward compatibility is an issu
John Launchbury says:
> 1. We should get rid of Assoc.
>
> When explaining my programs to other people I find this is a point of
> confusion. Imagine exaplaining array construction, "When I define an array,
> the comprehension produces a list of index/value pairs, only they are not
> written as
> 1. We should get rid of Assoc.
I agree wholeheartedly! Do we have tp consider backwards
compat?
> 2. Arrays should be lazier.
I agree again. But I think both kinds should be provided.
> 3. AccumArray should mimic foldr, not foldl.
Right!
-- Lennart
John Launchbury says,
| Here are three comments directed particularly at Haskell 1.3 people, but
| obviously open to general feedback.
|
| 1. We should get rid of Assoc.
|
| When explaining my programs to other people I find this is a point of
| confusion. Imagine exaplaining array construction,
Nikhil says,
| 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 aw
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 I don't recall
e
Two of John Launchbury's suggestions for Haskell 1.3 would mesh well
with the pH (parallel Haskell) effort:
>1. We should get rid of Assoc.
>
>When explaining my programs to other people I find this is a point of
>confusion. Imagine exaplaining array construction, "When I define
13 matches
Mail list logo
