[mercury-users] Exceptions and unique modes

[Ralph Becket]

>From Peter Schachte on 22/02/2001 11:57:15
> That is, I'm suggesting we use dynamically scoped hidden variables, aka
> "global variables."  They solve the problem because the variable name
gives
> continuity to the unique value.  To answer your question, a term won't be
> deallocated until the variable holding it is reassigned, at which point we
> don't mind what happens to it, exception or not.

Global variables bad.  We might as well write in ML if we're going to have
such things.

I think I have a solution that avoids the need for such things (see below).

> One thing I've just realized I'm not sure how to handle, though, is the
> scoping, and that's pretty important.  If we have a unique list being
> handled recursively, inside the recursion we'll keep assigning each tail
of
> the list to a nested scope of the same variable name.  We certainly don't
> want an exception happening deep in the recursion to propagate up to the
top
> of the recursion with this variable bound to some inner tail of the list!
> 
> I should also confess that my argument-threading implementation of global
> variables wouldn't handle this very easily.  You really want an
> implementation that places each global variable in a fixed memory address.

Here's my suggestion; it handles scope naturally.  For now, let's just 
consider the case of closing open files and releasing locks etc.

I attach a `recovery stack' to the io__state (or store or ...) that works
as follows.

Whenever I open a file, I push a record onto the recovery stack saying which
file it was that I opened.  Similarly for locks etc.

When I close a file/release a lock, I pop the corresponding record from the 
recovery stack.

[For simplicity, I have a version of the io library that handles all this 
transparently for me.]

Now, when I enter a try block I push a `checkpoint' onto the recovery stack.
(Each checkpoint is distinct from all other checkpoints.)

If the try block succeeds then I simply pop the checkpoint and continue.
If the exception handler is invoked then I simply pop items from the
recovery stack, freeing up the various resources that have been claimed
(e.g. closing files and releasing locks), but not freed, between the
checkpoint being created and the exception being thrown.  Dead easy.

[If I want IO operations with overlapping scope then all I have to do is 
allow the close/release/whatever operations to remove items further up the 
recovery stack.]

Now, if I have a unique structure that I need to keep in some sane state
then I treat it much as I would a database with transactions: I have to
(a) have a checkpointed version of it somewhere and (b) maintain a log of
what transactions have successfully completed since the checkpoint.

If this latter scheme is too heavyweight for a particular application then
I just have to fall back on atomic updates to store objects.



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