[mercury-users] Structure reuse

[Nancy Mazur]

>>If the user is interested, the compiler can produce interesting feedback 
>>as to why reuse at some place wasn't possible (example: some alias with 
>>some live structure that the programmer overlooked)...
> 
> 
> It will be extremely difficult to produce useful messages for the
> programmer, especially if the unexpected aliasing is not near the
> expected reuse.  I'd be very surprised if you can do this without
> drowning the programmer in analyser-produced gibberish.

It's a challenge I agree... but I'm convinced that some programmer 
understandable output can in a lot of cases be produced.

> 
> Also, in some cases the programmer will expect that only some calls
> to a predicate will be able to perform reuse (for the other calls
> an aliased value is passed which can't be reused).  How will the
> analyser work out which calls to produce warnings for, without
> producing lots of spurious warnings?

... see below ...

>>Yes and no. The unique modes are too strict as such. If you want to use 
>>unique modes, you need to have the discipline to write these modes for 
>>each predicate or function that manipulates the data structure you're 
>>interested in reusing...
>>It would be more user-friendly to use the unique modes only for those 
>>predicates where the programmer thinks reuse may be possible, and let 
>>the compiler figure out the rest of the predicates...
> 
> 
> This assumes that the only use for unique modes is to allow reuse.
> In most cases where you want reuse, you also want to ensure that
> the structure is used in a single-threaded manner.  Using unique
> modes allows the compiler to report errors if it is not.

Perhaps there is a need in such cases of a different annotation... if 
the programmer is interested in seeing whether some predicate of his can 
be optimised wrt memory usage, then he might try to declare that using 
some other (new?) declaration?
Using these 'hints for reuse', the compiler could try to focus on the 
optimisation of these locations, and then only give feedback to the 
programmer about these program points? In that case, the problem you 
mention above of producing output for non-interesting places is also 
solved....

Possible extension, like the pure, impure things:

p(X::in,...) :-
	...
	perhaps_unique X = f(... ),
	...

indicating that that deconstruction might, according to the programmer, 
be the last use of the structure X is pointing to...

Nancy

--------------------------------------------------------------------------
mercury-users mailing list
post:  mercury-users at cs.mu.oz.au
administrative address: owner-mercury-users at cs.mu.oz.au
unsubscribe: Address: mercury-users-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-users-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------