[E-Lang] E FAQ

[David Wagner]

[Forwarded with permission.  --MarkM]

> Good point.  This indeed may often follow activation frame lifetimes, in 
> much the same way that much dynamically allocated storage actually only 
> needs to live as long as some activation frame, whether this can be 
> statically determined or not.  Interesting.  I think this is worth exploring.

Right.  It's not clear how to do a good job of this.  One could imagine
trying to "garbage-collect" capabilities (indeed, this already happens
in any garbage-collected language where references are capabilities),
but I suspect garbage collection would be pretty sub-optimal.  One could
imagine handing out single-use capabilities, with a clone() method to
explicitly make copies, which may nudge the programmer into declaring
lifetimes, but I'm not sure this is a good approach.  Seems like an
interesting research question...

> In the interests of promoting E, you can't imagine how tempting it is to say 
> yes.  But it just wouldn't be right.

Ahh, I understand.  Yes, I see why it would be nice to have a name that
doesn't slight all the previous work.  I find "lambda-capability" a little
counter-intuitive, since the notion that a references convey authority
seems (to me) to be orthogonal to whether the language is based on the
lambda calculus.  It seems that capabilities are meaningful whether or
not your language has higher-order functions.  But it's better than any
suggestion I have so far, so I'm willing to go with it.

-- David

P.S. I double-checked on Hydra, and my memory was faulty.  It seems that
Hydra was a hybrid.  Methods contain both ambient authority (hard-coded
into the static source) as well as authority derived from parameters
passed in by the caller.  Also, I think (but am not sure) that Hydra had
a rather coarse granularity: not all objects were protected objects,
and not all pointers were capabilities (i.e., references to protected
objects).  I presume this was because it relied on the VM's page
protection mechanisms, and thus performance and granularity are issues.

P.P.S.  By the way, are you familiar with "security-passing style",
from Dan Wallach's analysis of stack introspection?  Since you
mentioned interest in building a small language for study, you might
find it an interesting point.  The idea is that you can transform
any stack-introspection-based program into an equivalent program
where authority is passed explicitly from caller to callee using extra
parameters, rather than living in an activation record.  This separates
authority from references, and I'm not sure I'd want to program directly
in security-passing style, but maybe it is worth knowing about.