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

[Kevin Reid]

On Dec 12, 2004, at 12:18, Dean Tribble wrote:

>> Rather, I am writing E-on-Common-Lisp from scratch.
>
> This is great.
>
>> 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).
>
> In EonSqueak, I'm translating E (or rather Kernal E) to essentially 
> equivalent Squeak code.  Is that what you mean by translating?

Yes.

> I have a translator from Kernel E to and intermediate for eslang which 
> has a lot of the guards compiled away, all the nested scoping 
> collapsed, etc.  Squeak then loads that (through a simple grammar) and 
> generates corresponding Squeak code.  How is your architecture 
> different, and would the intermediate representation and/or compiler 
> be useful?  IT sounds like you already have a similar logic, but I 
> can't quite tell.

I have no intermediate representation (yet). ENodes are translated 
directly to CL forms via depth-first traversal, passing leafward (call) 
lexical scope information and passing rootward (return) variable names 
to create 'let' forms at the outermost scope a given locally (treewise) 
defined variable can be visible.

>> Parsing of E source is handled by a Java-E subprocess.
>
> Cute.  I was planning to do somethign similar, but I just have an E 
> program run in Java the translates all the modules to eslang.  What 
> representation do you hand between E and CL, and is that 
> representation processed by E code or CL code?

I have an emaker which converts the term-tree produced by 
<elang:visitors.makeConvertENode2Term> to a S-expression, which is sent 
over a pipe to the CL process. I then use the CL reader (S-expression 
parser) to load that, and convert the resulting tree into ENodes 
(represented as CLOS objects).

>> 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'.
>
> Good.  That's really the biggest thing from what I can tell.  It's 
> also the place where we can share a lot of code.  Because I compile to 
> eslang, I can potentially write in E parts of the system required to 
> run E at all.  I will write up my boot strategy to allow secure boot, 
> even though low level parts of E are written in E.

I have no plans to make this system self-hosting to any degree, *yet*. 
It is essentially structured the same as E-on-Java, except that more of 
the non-primitive code is written in E rather than Java.

Specifically, so far, the List, Tuple, Union, Intersection, DeepFrozen, 
nullOk, and PassByCopy guards, PackageLoader, BaseGuard, ProtocolDesc, 
TypeLoader, and simple__quasiParser.

(The List guard is nonprimitive since Kernel-E list patterns coerce to 
ConstList primitively. (If this seems a wart, consider that 'if' 
expressions and such-that patterns coerce to boolean primitively.))

> Can you send me a copy of what you have so far?

I plan to publish the source "soon" after cleaning it up. If the 
cleanup isn't done in a reasonable time, I'll send it to you anyway.

-- 
Kevin Reid                            <http://homepage.mac.com/kpreid/>