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 pairs--these's this special type called Assoc. Oh, and don't be
> confused by :=. That's not assignment. It is an infix pairing operator."
> All of this is entirely unnecessary. Pairs have been used in maths for
> decades to represent exactly this sort of thing. I simply do not believe
> that [Assoc a b] provides me with any better information than [(a,b)].
> Worse, I often find myself having to redefine standard pair functions on
> elements of Assoc.
I agree.
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.
But := is a bit unintuitive if you're thinking e.g. FORTRAN:
a = array[1 := 2, 2 := 4]
does *not* mean 1 is assigned to 2, etc!
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)
[ While I'm at it: we should also get rid of the lower/uppercase
restrictions on constructor/nonconstructor names.
]
> 2. Arrays should be lazier.
>
> I'm expecting Lennart to agree with me here as LML has the Right Thing. I
> am convinced that there is no semantic problem with this, and I think that
> even Simon isn't horrified at the implementation implications. The ability
> to define arrays by self reference is just as important as it is for lists.
I'm not exactly sure what you mean here. It is allready possible to define
arrays by self-reference in Haskell.
> I am assuming that the fact that lazy indexes provide a better match with
> laziness elsewhere is clear, but I am willing to expand on this point if
> someone wants.
>
> 3. AccumArray should mimic foldr, not foldl.
>
> This is tied up with the last point. The only advantage I can see with the
> present scheme would be if the array element could be used as the
> accumulator while the array was under construction. However, as arrays are
> non-strict in their *elements* this seems to be of no benefit. It seems to
> me highly sensible that the structure of the computation at each point
> should reflect the structure of the input sequence (i.e. the elements are
> in the same order). Furthermore, if a lazy operation is used (such as (:))
> then the result becomes available early (assuming point 2. above).
>
Again I wholeheartedly agree.
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]
]
where array is like the ordinary Haskell array constructor function.
In the implementation, the filtering needs to be done only once
and not n times, where n is the size of the array.
[ If anyone wants to know how this is done, I could expand on this. ]
It seems to me that it is a bit more general to apply f to the entire
list accumulated at each index, rather than as an operator for foldr.
-- Thomas
