[m-dev.] Uniqueness again

[Ralph Becket]

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
  proceeds;

	[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
  unique.

  	[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 

	 Ralph
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------