[e-lang] Annealing Kernel-E (was: Announcing development snapshot E 0.8.36i)

[Mark S. Miller]

Chip Morningstar wrote:
> [...] as the design gradually anneals. [...] the inevitable
> two-steps-forward-one-step-back process needed to converge on a complete and
> consistent language design.
 > [...]
> It would be useful to see a similar exposition for the non-kernel language,
> since that has also undergone a fair bit of flux over the past couple of years.
> Moreover, it is the non-kernel form that most programmers who encounter the
> language will be learning and working with, so that is the place where concerns
> about linguistic complexity would probably most usefully be invested.

I agree that it would be useful, and I admit I'm much less optimistic about 
the outcome. Part of the point of having a small kernel language is so that 
pressures to admit conveniences can be addressed by syntactic sugar, where 
it's less costly. However, it's still costly, and so there are many issues 
here that remain to be argued about. On a more positive note, I believe E's 
recent evolution has preserved much more upwards compatibility over time than 
most people appreciate. All of CapDesk, including CapEdit, the DarpaBrowser, 
and the Capsicomm web server have continued to operate for years on successive 
versions of E with hardly any modification.

But I'd like to postpone any historical examination of non-kernel E for now. I 
feel like we're *very close* to converging on a final definition of the 
Kernel-E special forms.  Kevin and Dean have identified a set of remaining 
semantic issues in the definition of Kernel-E. The largest outstanding issue 
is how to support auditors. Zooko has made a proposal having many of the 
virtues and few of the flaws of previous proposals. Now that I'm through with 
school, I can focus my energies as well on resolving these issues. Once the 
Kernel-E special forms are nailed down, development can more fruitfully 
proceed in parallel on multiple Kernel-E execution engines.

Off the top of my head, the remaining Kernel-E issues are:

* Zooko's auditor proposal, and *all* its implications on the rest of Kernel-E.

* Resolving bugs and ambiguities in the definition of the
MatchBindExpr, 'e =~ p'. As my next email will explain, the semantics of this 
are surprisingly tricky.

* The current syntax of the trinary-define expression, 'def p := (e1, e2)', 
was always a placeholder. Dean has proposed a new arrangement which would 
allow us to remove a semantic restriction. Kevin has proposed an expansion of 
MatchBindExpr to Dean's proposed trinary-define which would remove 
MatchBindExpr's weirdness from the kernel language.

* The design of E's reflection primitives, such as 'meta.context()' and 
'meta.getState()', need to be revisited. Kevin has suggested some other ways 
of providing the reflective information that's actually needed, but in a way 
that places easier demands on a Kernel-E execution engine.


What other outstanding issues are there in pinning down the definition of the 
Kernel-E special forms?

-- 
Text by me above is hereby placed in the public domain

     Cheers,
     --MarkM