[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