[m-dev.] Uniqueness again

Ralph Becket rafe at cs.mu.OZ.AU
Fri Feb 7 15:14:24 AEDT 2003

Talking to Fergus, it seems my previous note wasn't as clear as it might
have been.

Clarification: I propose that we extend the current mode analysis
framework to handle nested uniqueness in the following way:

- record possible use information and possible sharing information from
  constructions, deconstructions and aliasing as the existing analysis

	[We can do this at negligible cost by incrementally consing this
	information - a shared(X) or a poss_uses(X, Y) record in each
	instance - into a list.]

- use this information to do necessary uniqueness testing when (and only
  when) we need to verify that a procedure argument is necessarily

  	[We only pay for the cost of necessarily uniqueness analysis
	if either
	- the code explicitly uses uniqueness or
	- we have structure reuse optimization turned on, in which case
	  we also need to perform this analysis at each construction.]

I think we should also go with the following:

- ditch consideration of partially instantiated terms;

  	[We can lift this constraint at some later date if and when
	it is deemed necessary and the analysis is cheap enough.]

- change the meaning of "unique" from "the top-level functor is unique
  and each of its arguments is also unique" to just "the top-level
  functor is unique."

To do: write down a formal description of the analysis including how it
should deal with 

mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au

More information about the developers mailing list