[e-lang] Introducing Emily, a High Performance Language For SecureCooperation

Kevin Reid kpreid at attglobal.net
Sat Feb 18 10:44:50 EST 2006


On Feb 17, 2006, at 11:22, marcs wrote:

> 3) While I can't say I understood the sebyla page on exceptions  
> very well,
> it looks from here like it shares with Emily the defect that data  
> can still
> be passed from one object to another object with which it shares no  
> visible
> communication path (the exception propagation path being pretty  
> invisible).
> To get a full-power solution, one must do something like what Kevin  
> is doing
> for E on CL, which is, sealing the exception and only allowing the  
> stuff
> inside the exception to be read by a catch clause that has its  
> hands on the
> unsealer.

Some notes:

It has been my intent that this system should be used in E, not only  
E-on-CL (once I've gotten the details worked out and some experience  
with it).

The majority of actual existing E code is not affected by this change.

In this system it is highly unusual to hold the unsealer, as it  
allows reading 'leaks' from all objects in a vat. The holders of the  
unsealer are such things as REPLs, the privileged layers of GUI  
frameworks, and debuggers. Ordinary code which wishes to dispatch on  
exceptions passes them via ejectors.

I do not yet have actual implementation for solving the problem of  
non-opaque failures for *eventual* programming, mainly because E-on- 
CL has no inter-vat references yet. The most recent discussion on  
this subject that I remember is the thread starting at:
   <http://www.eros-os.org/pipermail/e-lang/2005-May/010674.html>

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




More information about the e-lang mailing list