[e-lang] Announcing E-on-Common-Lisp (was Re: Is send DeepFrozen?)
kpreid at attglobal.net
Sun Dec 12 20:02:11 EST 2004
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?
> 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/>
More information about the e-lang