[prev in list] [next in list] [prev in thread] [next in thread] 

List:       e-lang
Subject:    Re: [E-Lang] New in 0.8.9k: Locally Untrusted Code &
From:       "Mark S. Miller" <markm () caplet ! com>
Date:       2000-11-30 0:47:19
[Download RAW message or body]

At 03:56 PM 11/29/00, Dan Bornstein wrote:
>[...] In
>this context, you might want to consider the ability to create a mutable
>location a form of authority. A died-in-the-wool pure function would not
>have this capability intrinsically, although there would be nothing wrong
>with passing it in to an invocation (echoes of the concept of "space bank"
>are ringing in my head).
>
>So, by this reckoning, a confined maker is perhaps a pure function which,
>in practice, is always (implicitly) passed the capability to create mutable
>state. [...]
>
>Is this progress? Or is it just a tangent?

The following paragraph has a bogus conclusion but is interesting on other 
grounds.  The antidote follows.

It's progress, in that it clarifies one of the key shortcuts that E and 
Joule take, compared to KeyKOS and EROS.  At object granularity, space & 
time allocation are implicit.  If something is always implicitly passed, 
then it is outside capability discipline.  E and Joule both expect to manage 
resource consumption at Vat granularity by explicit capabilities to rights 
to consume.  For most security purposes, E & Joule objects are like 
KeyKOS/EROS domains.  For resources, E/Joule Vats/Tanks are like KeyKOS/EROS 
domains.  Within a Vat, resources are a commons and denial of service by 
resource consumption is a pervasive possibility.  Between Vats, things will 
get more agoric.  This compromise is driven by the finer grain at which 
languages deal with computation, as compared with OSes.  Within this 
compromise, one cannot meaningfully deny an object the ability to make a 
stateful object.

After I wrote this, I realized that my conclusion is trivially wrong.  To 
constrain untrusted code to define only pure objects in your sense, one 
could simply define a scope in which the only SlotGuards 
http://www.erights.org/javadoc/org/erights/e/elib/slot/SlotGuard.html 
available are those that make immutable slots, like the ":final" guard
http://www.erights.org/javadoc/org/erights/e/elib/slot/FinalSlotMaker.html . 
Expressions evaluated in that scope would be prevented even from creating 
objects that could create mutable objects.  Put another way, the ability to 
make an impure function is the ability to escape from pure lambda calculus. 
Unlike Scheme's locations, E's slots are fully reified, as is the primitive 
that enables the creation of mutable slots.  I'm not planning to define or 
support such a scope, but I just learned something about E, lambda 
abstraction, capabilities, and side effects.  Cool.


        Cheers,
        --MarkM

_______________________________________________
e-lang mailing list
e-lang@mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/e-lang

[prev in list] [next in list] [prev in thread] [next in thread]