[mercury-users] Exceptions and unique modes

[Ralph Becket]

>From Peter Ross on 14/02/2001 16:23:43
> 
> Currently the only unique object which can be used with exceptions is an
> io__state, and it makes the assumption that the io__state you get back
> when an exception is thrown is the one that existed at the time of the
> exception.

I think that's an oversight: I don't see why try_io has to be io__state
specific: surely it could be generalised to any unique type.

> This would suggest that to be consistent with the way io__state is
handled,
> we guarantee that after an exception that the state of a unique object
> is that at the point where the exception is thrown.
> 
> Thoughts?

The exception mechanism should certainly not change the state of unique
objects.

If we had try_unique/3 rather than try_io/3 *and* had nested unique modes
then we could ensure that we package up all the necessary unique objects
and include them in any exception we threw.

> The next point to discuss is how do we get a handle back on the unique
> object after an exception.

I wonder if we could arrange things so that old pointers to unique objects
were still valid in the operational sense that they continue to point to
those
objects; then we could have something like

	rescue_unique_object(OldState, SanityCheckPred)

which would have the same sort of force as `unsafe_promise_unique'.  [I'm
aware that the above would also play havoc with modes: some extra machinery
would be required, methinks.]

--
Ralph Becket      |      MSR Cambridge      |      rbeck at microsoft.com 

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