[mercury-users] Exceptions and unique modes

[Fergus Henderson]

On 22-Feb-2001, Peter Ross <peter.ross at miscrit.be> wrote:
> On Thu, Feb 22, 2001 at 10:56:50PM +1100, Peter Schachte wrote:
> > 
> > I think a more interesting case would be something like this:
> > 
> > 	:- pred swap_stuff(type1::di, type1::uo, type2::di, type2::uo).
> > 
> > 	swap_stuff(f(A,B,C), f(D,E,C), g(D,E,F), g(A,B,F)).
> > 
> > It's natural to want the compiler to cleverly reuse the term passed as the
> > first and third arguments, and pass them back as the second and fourth,
> > respectively, just swapping the first two arguments of each term.  But a
> > good structure reuse optimization would instead pass the firstand third
> > arguments back as the fourth and second respectively, swapping just the
> > third arguments.
>
> Yes that would be nice, and it is one of the things Nancy and I are
> looking at for structure reuse.  However I think that compared to the
> massive gain you get from not having extra garbage the relative payoff
> of this extra optimization will not be hugely significant, and I would
> be willing to pay it for the ability to use one name to refer to unique
> objects.

You also lose the ability to do compile-time garbage collection.

Currently the semantics of `di' are that the called procedure is
allowed to totally destroy the incoming argument; it can do whatever
it wants with the storage, including explicitly deallocating it,
or reusing it to hold a value of another type.

To make what you want work, the semantics of `di' would have to be
changed to say that the called procedure is allowed to modify the
value, but must ensure that the storage always holds a valid value of
the original type; the called procedure is not allowed to explicitly
deallocate the storage, reuse it to hold something of a different
type, or to temporarily break any invariants of the type (at least not
if an exception can be thrown while the invariants remain unsatisfied).

There would also be problems with interfacing with other languages.
Currently you can use `di' to model C procedures that deallocate
the storage pointed to by their arguments.  But your suggestion
would require changing the semantics of `di' in a way that would
break that. 

So I don't think that it is a good idea.

I suppose another alternative would be to introduce new insts and modes
for the new concept, and to use those instead of `di'... but that would
complicate things quite a lot -- I'd much rather not go there...

P.S.  Changing the semantics of `di' or adding a new inst and mode is
just a minimum requirement; I'm not sure what else would be required
to make what you want work.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
                                    |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------