[e-lang] [ANN] E-on-Common-Lisp now available
kpreid at attglobal.net
Sun Apr 17 20:35:03 EDT 2005
On Apr 17, 2005, at 15:37, Mark Miller wrote:
> Kevin Reid wrote:
>> The complete source of E-on-Common-Lisp, or 'CL-E', is now public.
> Congratulations! This is wonderful news!
> (A minor issue: by our naming convention, this should be "E-on-CL". We
> should reserve "CL-E" for a cap-secure Common Lisp like language
> incorporating ideas from E. This follows "E-on-Java", "Joe-E",
> "E-on-Squeak", "Squeak-E", "Oz-E", etc.)
I have no good justification for this. I just find "E-on-CL" ugly and
awkward to type. It's also a purely descriptive name. If I were to
choose another name for the project, it would be something else.
("cl-e" also matches a common naming scheme for CL libraries.)
Also, "Common Lisp" is a particular Lisp dialect, and a
capability-secure Lisp would be necessarily very different. My
immediate reaction is that it might be "Lisp-E", but definitely not
I'd be interested in suggestions, but "E-on-CL" is not a name I like.
>> Currently, the only access method is via a Subversion repository.
> Why subversion? (Once opencm is ready, which it isn't yet, would you
> consider switching?)
I have no strong opinions about version control systems. I chose
Subversion because it looked understandable, popular and reasonably
I don't know anything about OpenCM other than that it's supposed to be
a capability-structured version control system. I'll certainly be
interested in trying it.
>> To get the source:
>> $ svn checkout svn://slimy.com/cl-e/cl-e/trunk/ cl-e
> Got it!
Just checking the obvious: Don't forget to update occasionally. Even
just since the announcement I've made some changes (mostly cleanup).
>> * Few IO capabilities. It can read files and argv, and write to
>> stdout and stderr.
>> * Large chunks of the E libraries are missing, such as CapTP,
>> serialization, and term trees.
> Data-E serialization is written mostly in E. How close is that to
The last time I tried to use a surgeon it tried to use term-trees via
deASTKit (if I remember correctly). So I could implement term trees, or
just hook up a deSubgraphKit to a deBytecodeKit or deSrcKit.
>> * Requires Java E to do some of its work.
> Anything besides parsing and expansion to Kernel-E?
It also calls "isIdentifier" for printing E source and source-ish
things; otherwise, no. All of this goes through the parse cache, so
once you have a populated cache file you can load previously-loaded
code without invoking Java.
> Regarding low level IO, does Common Lisp have a set of standard
> non-blocking IO primitives, so that we can do event-driven IO without
> spawning threads (i.e., such as Java's NIO library)?
There are no standard non-blocking IO operations, except for
READ-CHAR-NO-HANG, which polls a single stream.
There are nonstandardized features, of course. For example, the
CMUCL/SBCL family offers SERVE-EVENT, which waits on IO events and
calls handlers for them.
I haven't investigated this area thoroughly yet.
>> Runtime requirements:
>> * A Common Lisp implementation, preferably a recent version of SBCL.
> SBCL isn't yet ready for MSWindows, though they say they're working on
> it. In the meantime, do you happen to know what a good and compatible
> Common Lisp choice for MSWindows would be? Anyone?
I know of no implementation which runs on Windows and that I have
successfully run CL-E under recently.
CLISP is the most likely to work, except that the Java process pipe
failed inexplicably the last time I tried that. However, the Java
process is not necessary if you have a populated parse cache file.
LispWorks and Allegro CL are also possibilities, but some tweaking may
be required. They are both commercial implementations with free trials.
CLiki lists ECL as running on Windows, but I haven't yet tried it and
CL-E would require tweaking to define the appropriate interfaces for
ABCL (which is CL-on-Java) runs on Windows but ran CL-E very slowly the
last time I tried, and the parser interface doesn't exist (but if it
did, would be much simpler).
Many of these should be *possible* to port CL-E to; I just haven't
attempted to do so yet. It might be worth trying them anyway and
telling me how they fail.
Do you have no access to any Linux/Unix/OS X systems? I *might* be able
to arrange something.
>> CL-E is intended to run on many implementations but may not work
>> completely - if you have access to an adequate but unsupported
>> implementation I'd like to hear about it.
>> * The Java implementation of E, and its source in the same location.
>> It will be automatically located via `which rune`.
> I'm not sure I understand from this description what directory layout
> you have in mind. Could you give a concrete example layout?
Well, I usually install E as:
The src/esrc part is what clrune expects. This can be easily changed:
edit QUOTED_JLIB=... in the clrune script.
Is there a different, more standard, location to find un-jarred
emakers, in relation to EHOME or otherwise?
> I haven't looked at Common Lisp in a very long time. Should I
> understand from the above that, unlike Java, the Common Lisp spec
> never specified a standard set of command line arguments?
Yes. The Common Lisp standard says nothing about command lines.
> The existing "rune" based on E-on-Java enters a repl if no filename is
> given. Since you did implement a repl (below), did you decide not to
> make this the default behavior in the absence of a filename?
No; I just haven't made this work yet. There is not yet sufficient IO
to implement a repl in E, and the decision to enter simpleRune is made
before the command line arguments are interpreted.
See lisp/rune.lisp and lib/org/cubik/cle/makeIOScope.emaker .
The standard runeAuthor, when I've tried it, executes the script it's
given and then enters an infinite send loop (with some counter
incrementing, according to my send traces).
> Btw, any idea how close you are to being able to run the existing
> E-implemented updoc?
I haven't tried recently.
>> Parse the sole argument as E source and print the Common Lisp
>> it is compiled into.
Warning: It's ugly. The compiler is currently at an "it preserves the
semantics" level and makes no attempt to generate sane code.
>> Enter the Lisp-implemented E REPL.
> Any idea how close you are to being able to run the existing
> E-implemented repl?
At a minimum, it will need the ability to read from stdin.
>> Running the tests:
>> $ ./clrune -p parse-cache.sexp --updoc tests/
> When I run these on E-on-Java on my MSWindows box, I get a 288 or so
> differences, but I haven't looked to see how many of these are more
> than cosmetic.
Many are simply different prints of primitive objects and exceptions.
> From a brief skim, the differences seem to be improvements you made,
> that E-on-Java should be updated to track. Besides the non-cosmetic
> differences already discussed (name-free auditors, expanding
> escape/ejectors to exceptions),
I am *not* intending to replace ejectors as a primitive mechanism. It's
*exceptions* that are broken.
> are there other non-cosmetic differences we should be aware of?
I believe there are, but I don't have a list handy. I hope to
eventually define a "portable" subset of the tests that should pass on
all E implementations.
Many of the test differences, however, reflect behaviors which I would
like to see adopted in standard E (or an E standard).
> I note that several files seem to import from a path that seems not to
> be included in the source tree. For example, makeTextWriter.emaker
> consists of the text:
> but the directory org/cubik/cle in the source tree doesn't have a prim
> subdirectory. Does that mean it's implemented as a primitive in lisp?
Yes. Everything with a package of org.cubik.cle.prim is implemented in
Lisp. See make-primitive-loader in lisp/knot.lisp.
Kevin Reid <http://homepage.mac.com/kpreid/>
More information about the e-lang