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
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, "When I define an array,
the compr
John Launchbury makes the suggestion, inter alia, that Haskell 1.3
`should get rid of Assoc.'
Reading some of the followup messages, I see that there is some
division on this point. Those closer to the scientific applications
community, such as Nikhil and Joe Fasel's acquaintances, seem to be
w
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
15 matches
Mail list logo
