[e-lang] [ANN] E-on-Common-Lisp now available

Kevin Reid 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.

<http://www.cliki.net/Unicode%20support>

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 
installed via.

> 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 
there.

> 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.

http://www.cliki.net/ZIP

>>> 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?

No.

<http://www.cliki.net/FFI>
<http://www.cliki.net/UFFI>

> Does SBCL?

<http://www.sbcl.org/manual/Foreign-Function-Interface.html>

>> 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 mailing list