[e-lang] Announcing E-on-Common-Lisp (was Re: Is send DeepFrozen?)
markm at cs.jhu.edu
Sat Dec 11 22:55:41 EST 2004
Kevin Reid wrote:
> [...] Rather, I am writing E-on-Common-Lisp from scratch.
WOW! Kevin, this is fantastic news!
> 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
> 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
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
More information about the e-lang