non destructive references

Zuurbier, E. - AMSXE Erik.Zuurbier@KLM.NL
Mon, 26 Apr 1999 16:09:34 +0200


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.

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.

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)
 
Does this make sense? Or is there a theoretical objection to all this?

Regards Erik Zuurbier
 
	
	


Erik Zuurbier
Application Architect, 
KLM, Information Services - SPLXE
phone: (+ 31) 20 64 96 255 
e-mail: erik.zuurbier@klm.nl