[mercury-users] Exceptions and unique modes

Peter Schachte schachte at cs.mu.OZ.AU
Wed Mar 7 17:57:27 AEDT 2001


On Tue, Mar 06, 2001 at 02:08:13AM -0800, Ralph Becket wrote:
> Later on in that e-mail I suggested that the problem of recovering unique
> objects could be handled by periodically checkpointing the state of such
> an object and keeping a log of all the transformations applied to it
> thereafter.
> Then, if you get an exception where you would otherwise lose the state of
> the 
> unique object, you can recreate its state from the checkpoint and the log.

That's not the problem I'm talking about.  I mean how do you *find* the
right object?  Say there are a dozen different unique objects being
manipulated in various places in a computation that then throws an
exception.  Even if you somehow have some structure that holds all of them,
how do you determine which of them is the current version of which incoming
object?

> While this is somewhat heavyweight, exceptions should be exceptional hence
> one 
> should not expect handling them to be cheap in all situations.  Keeping the
> log 
> etc. should not be particularly expensive.

The cost of maintaining a redo log is too high for lightweight operations.

For example, suppose I'm building up a unique list of unique things that I
want to keep whether an exception happens or not.  Every time I create a new
list cell, you'll have to keep a record of the head and tail of the cell so
you can create it again.  That boils down to making another whole copy of
the list, and at least doubles the time and space cost of creating the list.

It also raises the problem that the existence of the log itself makes the
things it contains not unique; you'd have to introduce the concept of weak
references.

It seems much easier to hang a hash map off of the io__state which
associates a unique term with a name.  This solves the problem of finding
the latest state of a particular unique object, too.  When you want to
update one of these unique things, you look it up by name in the map, create
the new value, and put it back.  Of course, this can be made more efficient
by not actually storing the map in the io__state.  And we can optimize it
further by analyzing the program to determine what names are used to store
values in the hash map and allocating space for them statically.  This is
what dynamically scoped variables are.

-- 
Peter Schachte <schachte at cs.mu.OZ.AU>  A successful [software] tool is one
http://www.cs.mu.oz.au/~schachte/      that was used to do something
Phone:  +61 3 8344 9166                undreamed of by its author.
Fax:    +61 3 9348 1184                    -- S. C. Johnson 
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------



More information about the users mailing list