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

[Mark Miller]

Kevin Reid wrote:
>> [...]  an ejectoid would indeed have
>> to be the same kind of magic as a SturdyRef  [...]
> 
> 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.

Very interesting point. I like it.


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

Makes sense.


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

I don't understand throw.free. For example, the following from your 
exception.updoc:

> An exception may be explicitly thrown unsealed. This is used for mechanisms
> using custom sealers (such as the eventual pseudo-ejectors shown below).
> 
> ? try { throw.free("eek") } catch p { print(p); throw(p) }
> # stdout: eek
> 
> # problem: eek

seems to demonstrate that throw.free leaves open the leakage bug you've been 
working so hard to plug. I must be misunderstanding something.


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

It sounds to me like the right direction. Let's revisit this once I understand 
throw.free.

-- 
Text by me above is hereby placed in the public domain

     Cheers,
     --MarkM