non destructive references

[Sjaak Smetsers]

>Hi,
>
>If I want to select two elements from a unique array, whose
>elements are not unique, I use something like:
>
>readArray :: *{a} -> (*{a},a,a)
>readArray arr = (arr``,element1,element2)
>where   (element1,arr`) = uselect arr 3
>        (element2,arr``)= uselect arr` 5
>
>(Actually, I use # notation, but the above illustrates my point better).
>
>This readArray-function contains an overspecification.
>It says that first element1 is extracted, then element2,
>while actually, the order does not matter.
>
>I know that the Nijmegen boys have been working on making it
>easier to work with non-desctructive references, but the function
>below is still not acceptable.
>
>readArray :: *{a} -> (*{a},a,a)
>readArray arr = (arr,element1,element2)
>where   element1 = select arr 3
>        element2 = select arr 5
>
>Will it ever?
>
>I think it should. Because I think the compiler should be able
>to deduce which references are destructive and which are not,
>if only this information were present for the built in functions,
>such as 'select' above.

The problem is NOT that the selection is non-desctructive. But, due to
laziness, the selection is not performed BEFORE the resulting array is used
destructively (which is possible since you deliver a unique result array).
By forcing the evaluation of both selections, e.g. by writing

readArray arr
	#! element1 = select arr 3
           element2 = select arr 5
	= (arr,element1,element2)

the function will be correct.
>
>If a function contains a number of non-destructive references to a
>unique object, and at most one destructive one, then the function
>should be allowed by the compiler.
>
>Evaluating such a function could be done as follows.
>First evaluate all non-destructive references, in any order
>that suits the compiler.

Lazy evaluation makes is very hard to reason abot or to change the
reduction order without violating the semantics.

>
>Then evaluate the destructive reference (if there is one).
>
>Such a situation would have the following advantages:
>-The programmer would not need to be overspecific.
> This is a nice theoretical property, but if you have programmed
> with unique arrays and records for a while, you know that
> imposing an order where there should not be one, is a real pain.
>-The code generator might be able to generate faster code,
> because it does not have to stick to the specified order
> (because there is no specified order anymore)
>
regards,

Sjaak Smetsers