[e-lang] Fixing exceptions, try #3 (was Re: TextWriter/__printOn ...)

[Kevin Reid]

On May 30, 2005, at 18:11, Mark Miller wrote:
> Kevin Reid wrote:
>> That solution is described at:
>>     
>> <http://www.eros-os.org/pipermail/e-lang/2005-January/ 
>> 010416.html&e=9888>
>> which I found via:
>>   http://www.google.com/search?q=site:eros-os.org+kevin+reid+ejectoid
>
> What's the "&e=9888" about? When I include it, I get a 404. When I  
> strip it off, I get the email you intended.

Uncautious URL editing. www.eros-os.org wasn't responding at the time,  
so I used the Google cache, then attempted to edit the URL to the  
regular one, but didn't check it carefully enough.

>
>> Here's a short and sloppy implementation of it for the same example   
>> usage as below:
>>   ? def thisProblemBox
...
>>   ? def MyMissingKey {
>>   >   to coerce(specimen, optEjector) :any {
>>   >     if (Ref.isResolved(thisProblem)) {
>>   >       return thisProblem[0]
>
> Should this be "return thisProblemBox[0]"?

Yes.

(I should have, but didn't, test this code before sending the message,  
since it doesn't require anything Java E doesn't support except for the  
PassByConstruction auditor.)

> This seems like a job for the olde CryptoBrandMaker.
> ...
> Assuming we want the ejectoid to encapsulate this public key from its  
> clients, for the same reason we have a SturdyRef encapsulate the captp  
> uri bits from its clients, then an ejectoid would indeed have to be  
> the same kind of magic as a SturdyRef, as you suggest. Or we could  
> push the magic around a bit, and have a cryptoSealer be this kind of  
> magic. I think I prefer that the cryptoSealer remain open and the  
> ejectoid be the magic one.

I think we do want the ejectoid to be magic in one way, even if we  
didn't care about revealing its bits (which we should, for  
determinism): the ejectoid should be non-PassByCopy and non-DeepFrozen.  
Otherwise, an object can have an extra communication path despite being  
DeepFrozen, whereas we want DeepFrozen objects to be confined.

> Once CapTP is switched over to use Data-E as its serialization system,  
> such magic could be provided unmagically by making SturdyRef &  
> ejectoids PassByConstruction, and having them provide their portrayal  
> only as sealed by their CapTP's sealer.
>
> Can all of above indeed be provided purely by unprivileged E code, so  
> that no changes to Kernel-E or the primitives are needed? If so, this  
> would be good. How much of the work would this allow us to postpone?

The ejectoid's magic will, even in a 'pure E' system, need to be  
authorized, I expect. The primitive exception/ejection mechanisms  
should be essentially the same mostly-trivial changes for adding  
sealing that I already have in E-on-CL, except that 'throw.free()' is  
renamed and gets an argument guard such that it accepts only magic  
ejectoid-boxes.

The guard would be implemented like the DeepFrozen and Selfless in  
E-on-CL: the primitive system provides a stamp and checks it, and the  
authorized objects get rubberstamped.

I haven't thought about this for very long.

-- 
Kevin Reid                            <http://homepage.mac.com/kpreid/>