[e-lang] E on Squeak (was: E sealer revisited)

[Dean Tribble]

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

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

In detail:

- 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 
community, however.

>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
>see fit).

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.

Me too!