>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 issue. The standard technique of supporting
Assoc but with compiler warnings will probably have to be used.
-----------
>I'm not exactly sure what you mean here. It is allready possible to define
>arrays by self-reference in Haskell.
Haskell arrays are strict in the indices. That is, the whole of the
defining list is consumed and the indices examined before the array becomes
available. Thus, a recursive array definition in which the *index
calculation* depends on the earlier part of the array gives bottom. The
current definition allows for a recursive definition so long as it is only
the values of the array elements which depend on the array. This is not
always sufficient.
-----------
>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.
> ...
>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.
If you want the list you can supply (:) and []. If not, you supply the
operations, and the intermediate list never gets built.
John.
