[E-Lang] Re: E questions

[Mark Seaborn]

"Mark S. Miller" <markm@caplet.com> writes:

> Of course, I can only do data-level debugging of A.  Unlike KeyKOS,
> I can't do control flow debugging for the reasons previously
> explained.

Which were:

> I ended up in the current (unpleasant but tenable) position by realizing 
> that, in order to preserve E's concurrency control guarantees (the executing 
> turn/even has mutually exclusive access to everything it has synchronous 
> access to -- all of which are therefore in this vat), a conventional 
> control-flow debugger would have to seize control of the vat as a whole.  
> Why?  Because while the current computation is suspended, eg, at a 
> breakpoint, nothing else may proceed in that vat.  Therefore the debugger, 
> and the person operating the debugger, are all parts of that vat's TCB.

Surely A can already suspend the vat by looping indefinitely?  If the
person debugging A also wrote A, there is not much to be gained by
preventing them from halting them the vat if they could have done that
anyway.


[snip]
> We have not yet designed what the protocol is of the can opener, the
> means of building an object to be openable by one, nor the synergy
> protocol by which a can opener opens (or fails to open) a candidate
> object.  Suggestions appreciated!

I have been thinking about something related in OCaml.  I wanted to be
able to brand closures so that anyone who holds the brand can extract
hidden values from closures they branded.  It should be possible to do
this branding at a low level by copying the physical closure and
adding a couple of words to the end.  The closure's function should
not care about the extra words, and if one of those words is for a
secret held by the brand, no closure could capture those values and be
mistaken for a branded closure.  (I have not implemented this yet.  I
decided to just put closures in wrappers that could have hidden values
extracted using brands -- something more like using sealer/unsealer
pairs with an unhidden part.)

The relevance of this to E is that it would be simple and efficient
and would not require changing the representation of closures.  It
only requires two trusted operations on closures.  Objects do not need
to be born branded, but can be created and then branded.  This means
that the branded object would not be equal to its unbranded
counterpart, and that makes this approach subtly different from one in
which the brand keeps a weak hash table of all the objects it
considers branded.

For debugging you could do a source-to-source transformation to brand
each closure/object as it is created, avoiding the need to put this
into the language implementation.  (Though the language could spot
that the hidden values being associated with a branded closure are the
same as the values of the closure's free variables and share the data
between the two.)

As for control flow debugging, there is (or was) a debugger for SML
that works by annotating every interesting step of evaluation of a
program (eg. it would place an annotation at the beginning of every
branch of a pattern match).  (The OCaml debugger seems to do the same
thing.)  It lets you step through a program interactively and time
travel.  I noticed that when I was doing printf-style debugging my
method of annotating was much the same as what one of the ML debuggers
would have done (except that I kept having to add annotations and
re-run the program!).  Even without time travel and interactivity
(which I tend to find too tedious to use), it could be useful to
automatically annotate an E program to generate events at each source
location.  Then full traces of execution could be included in
exceptions (which might include the value of variables at each point),
except that to examine them you would need to hold the capabilities
corresponding to the source locations involved.  This would mean you
could trace your code even as control passes through objects that are
opaque to you, and perhaps do tracing across vats.  If traces could be
set to record only a small amount of information (or maybe discard
information as it ages), this could be enabled as a matter of course.

-- 
         Mark Seaborn
   - mseaborn@bigfoot.com - http://www.srcf.ucam.org/~mrs35/ -

  A few months in the laboratory often saves several hours at the library.