[cap-talk] C-like Capability language

[Jonathan S. Shapiro]

On Sat, 2008-08-02 at 09:47 +0100, William Pearson wrote:
> 2008/8/1 Jonathan S. Shapiro <shap at eros-os.com>:
> > What do you anticipate will be true about capabilities in your language
> > that is not true of object references more generally?
> >
> 
> The capabilities themselves, nothing. I'm interested in the
> compiler/interpreter life cycle (and other programs that deal with
> programs e.g. apt-get)...


Let me say first that I think your interest is terrific. I have some
suggestions, but I'm still a little confused here.

My confusion stems from the fact that you haven't really answered my
question about capabilities. Broadly speaking, you seem to be talking
about type-safe and memory-safe runtimes. These don't require any
special support for capabilities, because object references are already
capabilities. You could place various *restrictions* on the VM layer,
but these restrictions can equally well be enforced in a bytecode
verifier, and you probably want to keep the VM per se as general as
possible. Still, my main point is that your goal of "a lowish level
bytecode VM that enforced capabilities and was high level language
agnostic" is satisfied by any type-safe runtime.

My suggestion is that you shouldn't try to do this completely on your
own. There are existing language projects that could really benefit from
a new low-level VM. Rather than try to do the whole stack at once, I
suggest that it may make more sense to target your efforts at supporting
one or more of those languages. Two candidates that come to mind are E
(which you mentioned) and BitC.

> Implementing E vX+1 on EvX would be weird. You would be stuck with any
> flaws of E v X  and would always have to write new E interpreters in
> it, unless you wanted to have two levels of indirection.

I think this is not the case. There are *lots* of examples of people
implementing VMs in higher-level languages, some going all the way back
to SmallTalk. The usual technique is to implement the bytecode engine in
a highly constrained, GC-independent subset of the high-level language,
said subset being chose for direct compilability to C. The most cited
example of this is probably Scheme48, but see also the work on VLISP
PreScheme and the Squeak VM. One major advantage to this is that you
don't lose the advantages of the high-level language w.r.t. analyzing
and maintaining your code.

One result of this approach is that E vX+1 is not constrained by E vX.

In the specific case of E, however, I think this is not likely to work
well. Efficiency at the VM layer really wants static typing. That can be
achieved by type inference, but it needs to be achieved somehow.
Unfortunately E's first-class messages offer a fundamental research
challenge in static type inference. I suggest that you don't bite into
that, but instead focus on one problem at a time.

> So a lowish level bytecode VM that enforced capabilities and was high
> level language agnostic, that you wouldn't want to change very often,
> is the way I am going. Then you would compile your each version of
> your compiler/interpreter down to this language, and you would have
> control over what it did.

Yes. But on the other hand you would kind of like that VM to itself be
implemented in your language, if only for maintainability.

shap