[e-lang] [ANN] E-on-Common-Lisp now available
kpreid at attglobal.net
Tue Apr 19 16:26:26 EDT 2005
On Apr 19, 2005, at 11:18, Mark Miller wrote:
> Kevin Reid wrote:
>> 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.
> Does CL do Unicode? Would it be straightforward to write isIdentifier
> in CL?
The CL standard defines characters such that an implementation *can*
support Unicode. CL-E uses the implementation's character type.
isIdentifier would be straightforward to duplicate, but I specifically
did not as the relevant Java source is under the Mozilla license - and
I wanted to make sure that the definition did not get out of sync with
the E parser being used.
>> 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.
> How do you install CLISP on Windows? I couldn't figure that out.
I don't know; I don't use Windows. The CLISP page
<http://clisp.cons.org/> links to
<http://www.cygwin.com/packages/clisp/>. A quick glance suggests that
installing Cygwin provides a package manager which CLISP can be
> From your layout, and your earlier comment about 'which rune', should
> I infer that you put 'rune' in 'e/', and put 'e/' on your PATH?
No. clrune parses rune to find its definition of EHOME, then looks
> On Linux, my convention has been to install E to /usr/local/e, to put
> rune into /usr/local/bin/e, and to put /usr/local/e/scripts on my
> PATH. But I'm open to suggestions.
This part does not matter - as long as rune is findable and contains
EHOME=, clrune will use it to derive the emaker path.
All that CL-E needs, currently, is a known path at which standard
emakers may be found outside of a jar file. If there is no standard
location for an E source distribution, relative to EHOME or otherwise,
then this is impossible.
jar files are just renamed zip, right? It might be possible to get CL-E
to read directly from e.jar, and remove this dependency.
>>> 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.
> Bletch. Ok, let's do better with rune/clrune.
> Does Common Lisp specify a standard native interface (or foreign
> function interface) for linking in C libraries?
> Does SBCL?
>> 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).
> Hmmm. Any idea what's going on?
I haven't attempted to understand the interp/cmdLoop stuff yet so I
don't know what it should be doing that it isn't.
>> Many of the test differences, however, reflect behaviors which I
>> would like to see adopted in standard E (or an E standard).
> Yes; I am eager for this as well! Let's start with the changes to
> Kernel-E itself.
I cannot significantly change Kernel-E without also altering the parser
and expander, which I do not implement. The only change I've made is
that throw() throws SealedBoxes.
As for the other changes, the best reference would be the tests
themselves. I don't have a list.
Kevin Reid <http://homepage.mac.com/kpreid/>
More information about the e-lang