[e-lang] Announcing E-on-Common-Lisp (was Re: Is send DeepFrozen?)

[Mark Miller]

Kevin Reid wrote:
> [...] Rather, I am writing E-on-Common-Lisp from scratch.

WOW! Kevin, this is fantastic news!


> Information:
> 
> So far I have implemented almost the entire Kernel-E language (except 
> for escape-catch and meta.getState()) via translation to CL, and enough 
> of ELib to run interesting code (though no IO as yet).

I'm so glad you did it by translation. That means E-on-CL should run at close 
to CL speeds on comparable problems.

If I remember CL correctly, escape-catch shouldn't be a problem.

meta.getState() should actually be removed from Kernel-E anyway, and defined 
instead by the following expansion from Expanded-E to Kernel-E.

     ... meta.getState() ...

If the variables that are live[*] in this context are, let's say, "x", "y", 
and "z", then this should expand to

     ... ["&x" => &x, "&y" => &y, "&z" => &z] ...

[*] Live here is a subset of the variables in scope. If there is no enclosing 
object definition, then it is exactly the variables in scope. If there are 
enclosing object definitions, then it is all the in-scope variables defined 
within the closest enclosing object definition + all the in-scope variables 
used freely by this closest enclosing object definition. In other words, 
in-scope instance variables + local variables.

This expansion must happen after the expansion from E to Kernel-E, since it 
relies on context information. (The e__quasiParser outputs Expanded-E, since 
the kinds of processing supported by quasiliteral expressions and patterns 
needs to be context free in this sense.)

I should have done this myself ages ago, but it never became the most 
important thing to do next, since the existing meta.getState() mostly works. 
However, there is one case where the current primitive meta.getState() is 
broken, but where an expansion, done right, would be correct:

     def state := meta.getState()

Does state include an association for "&state"? If we expand meta.getState(), then

    def state := [..., "&state" => &state, ...]

This implies that the expansion of cyclic defines, which currently happens 
during the expansion from E to Expanded-E, should instead be moved to occur 
during the expansion from Expanded-E to Kernel-E. This is probably a good idea 
anyway.


> Parsing of E source is handled by a Java-E subprocess.

Googling '"common lisp" lalr' turned up a variety of hits. I don't know which 
ones are interesting.


> I am attempting to write as much of the non-primitive ELib code as I can 
> in E, so that it is not specific to this implementation, and not 'part 
> of the TCB'.

That's wonderful! Some of this may be duplicating some work Dean's doing. You 
guys should coordinate. In any case, as parts of ELib are rewritten in E, I'll 
be happy to try to re-integrate them into the current E distribution.


> I have Updoc and a REPL (interactive interpreter), written in CL.

Why in CL? The current updoc and repl are already written in E.

Does standard CL have weak pointers and post-mortem finalization? E requires 
these.

What is the current status of standard gui toolkits/libraries for CL? Do any 
of these look tame-able?

How does one debug CL computation? Is there a standard debugging API?


> I am testing it on SBCL <http://www.sbcl.org/> and OpenMCL 
> <http://openmcl.clozure.com/>. At one point, I confirmed that it ran on 
> CLISP <http://clisp.cons.org/> except for the Java-E parser connection.
> 
> A question:
> 
> Since the code is significantly derived from Java-E (particularly such 
> parts as the Equalizer, which is a direct translation), how should I 
> phrase the copyright and license information?
> 
> Other than some hardcoded system-specific configuration, and other such 
> details, this is the only reason I haven't yet published the source.

<http://www.erights.org/download/licenses.html> lists all the licenses 
covering any part of the current E implementation. AFAIK, the only one of 
these that imposes significant restrictions is Mozilla. For all the files 
covered by Mozilla, the copyright is held by those who own the assets of 
Electric Communities. I would hope that this degree of from-scratch effort 
would result in E-on-CL being freed from the Mozilla license. But IANAL. The 
Equalizer is covered by MIT X, and so shouldn't cause anyone any problems.

If anyone who can offer advice about this matter, it would be much 
appreciated. Please email either e-lang, or Kevin and I privately, as you 
think is appropriate. Thanks.

Kevin, until we get some advice on this, you may wish to avoid imitating too 
closely any of the Mozilla-covered files.


Again, this is very exciting!! Thanks for doing this!

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

     Cheers,
     --MarkM