[e-lang] E on Squeak (was: E sealer revisited)
Thu, 08 May 2003 19:23:26 -0700
> > As a side project, I am working on a Squeak-based runtime for
>I'm _extremely_ interested in this project.
I thought you might be. I sent you (and separately, Rob Withers) a message
recently asking about the status of Squeak E for possible synergies with
>Can you say a little more about
>what you're planning to do in this area and where you're currently at?
My goal is to have a fast enough E runtime that E tools (like the compiler)
can be usably built in E. My basic plan is to compile E to Smalltalk parse
trees (because then I can use arbitrary literals, selectors, etc.) that
implement the behavior that I want, and compile them in Squeak. The model
will be fairly direct, but because Smalltalk has a much better impedance
match with E, I expect a speed-up of something like a factor of 200 with no
special attention to performance (which says something about how slow E on
Java is :-). The E code will run the same speed as corresponding Smalltalk
code, but without primitive support, other language features/properties
will slow things down some (e.g., promises, equality semantics, guards). I
am not contemplating doing anythign to the underlying Squeak VM at this
time (among other things, I don't want to learn how just yet :-).
To support that above goal, I'm going to build the minimum possible in
Squeak itself, and use the current E transformer to generate the Smalltalk
code. That will obviously be somewhat inconvenient until the E tools are
ported to E.
BTW originally I was going to hand Kernel E to Smalltalk and compile that,
but rather than reproducing the E parse nodes etc in Squeak, I will build
most of the compiler in Java (and then eventually perhaps in E). Also,
Intellij with Java stills kicks *ss over even developing in Smalltalk
(though not in debugging yet).
- hand code MintMaker in Smalltalk (Done)
- define an intermediate form (which I will call ESlang) that is easier to
generate than Smalltalk for transferring compiled E to the E runtime in
Squeak. I've hand coded a subset, and am considering the
implementation. Suggestions for alternatives to ESlang are welcome! Note
that ESlang is related to the needed Smalltalk code, and does not look like
E! Since I wnat a simple parser, I'm defining it as an E Term Tree (we
will see how that goes! :-).
- define Visitors in Java to generate ESlang.
- write an ESlang parser and Smalltalk code generator in Squeak
- implement the minimal E system primitives in Squeak
- run simple E programs
- think some more
Note that I am not concerned at this point with smooth interface to Squeak,
security in Squeak, etc. I want fast enough that we can afford to write
all that stuff in E!!! Thus, ESlang will launch with many powerful but
closely held capabilities, and the correct E libraries will need to be
written in E itself. For example, I expect that the authority to invoke
hash will be a primitive capability, and the collection classes should be
written in E.
I do intend to make my various compilation and environment enhancements
generally available to other Squeakers for their own language hacks
:-) I'm not planning on spending a lot of effort to test them for the
>reason why I'm asking is that for some time now I've been thinking about a
>secure "front end" scripting architecture within the context of the Croquet
>project (http://www.opencroquet.org) I'm working on. Since it is a
>Squeak-based project there is "lots of power behind the curtain" and we
>obviously need a way of dealing with it.
Great. I've been occasionally looking at the site to see whether there was
code to download yet :-)
As an aside: The density of code in E is impressive compared to
Smalltalk. Some things about syntax have improved in the last 30
years. MintMaker is 26 lines in E and 96 in Smalltalk, and the comparison
is only slightly invidious :-)
>As one of the steps towards this goal (as we can't change it all at once) I
>wanted to experiment with "secure scripting" as a first step (with the
>implicit idea that we're not as much hindered by the real-time constraints
>of the 3D architecture, be able to expose only limited functionality as we
So you may be interested in the interface from the E code to Smalltalk
objects. When I get that far, I'll let you know :-)
>If Squeak can be a runtime target for E, I'd really love to see how well
>this works in the scripting domain of Croquet.