[mercury-users] Exceptions and unique modes

[Peter Ross]

On Thu, Feb 22, 2001 at 05:01:28PM +1100, Fergus Henderson wrote:
> On 22-Feb-2001, Peter Schachte <schachte at cs.mu.OZ.AU> wrote:
> 
> > If I understand correctly, the problem is that we need an operational
> > semantics that admits di/uo pairs being implemented either as a single data
> > structure which is destructively modified or as one which is copied.  Of
> > course, in the former case when an exception is raised, the data structure
> > has already been modified, so we can't get back the original value, and in
> > the latter case we'll naturally have the original value, and no easy access
> > to the latest value before the exception.
> > 
> > So we're looking for a model that will work in both cases.  I expect we're
> > agreed that we want the value after the exception to be the last value
> > before it, because making it be the original value would essentially render
> > the destructive update optimization useless.
> > 
> > One straightforward way to specify it is for any predicate with a di/uo mode
> > to notionally transform any throws it contains to parcel up the last value
> > of the di/uo thread(s) in the exception term it throws.  Similarly, it
> > should notionally wrap every goal in a catch wrapper that pastes the latest
> > value of the thread into the exception term and reraises the exception.  I
> > did say "notionally"; of course you wouldn't implement it that way.
> 
> So how would you implement it?
> 
> In particular, what would you do about code which tries to reuse the
> storage for something with a `di' mode, e.g. by explicitly deallocating
> it so that the allocator can reuse it to hold something that has a
> different type?
> 
You would think that the best canditate for reuse of that memory is the
next state.  Unfortunately it is not quite that easy as the following
type indicates.

:- type t
    --->    f(int)
    ;       g(int, int).

No matter what you initialise this type to you need to make sure that
you allocate 2 words so that you can possibly hold the g constructor at
some later date.

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