[E-Lang] New in 0.8.9k: Locally Untrusted Code & Confinement! (Part 1)

[Dan Bornstein]

>>The term I learned to use for the concept I believe you're describing is
>>"pure function." [...] Additionally, if the
>>arguments to a pure function are all pure constants (that is, transitively
>>immutable values that are incapable of granting authority), then the result
>>of calling that function is also guaranteed to be pure, [...]
>
>An intriguing starting point for generating a name.  However, your 
>"Additionally" observation above is explicitly violated by my 
>transitively-immutable/checkably-confined  objects.

I conflated a couple of ideas and mis-spoke, or at least mis-implied. 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. (Given that this capability is not a pure constant, the
"additionally" observation holds trivially for such an invocation.)
Naturally, it can in turn pass this capability to the objects which it
thereby makes, along with whatever other capabilities it is (explicitly)
passed.

Is this progress? Or is it just a tangent?

-dan