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

Andreas Raab e-lang@mail.eros-os.org
Sat, 10 May 2003 01:19:38 +0200

Hi Dean,

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

Shoot! I completely forgot about it as Rob would be the guy to tell you
about it and I thought he would and when he didn't I forgot (stupid me). The
short of it is that I believe the version up at SqueakMap is still the
latest you can get. I don't think that Rob's made any major changes after
that (I remember vaguely that he said he wouldn't have too much time right

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

Sounds good to me.

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

Err ... you gotta be kidding me right? Are there any benchmarks for E in
this regard?

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

Heh, heh. Well I might be able to give you a hand at some of the things in
the performance area. If that's really needed. Let's see and measure.

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

Can you say anything about the things you need from Rob's work to get this
going? I'm curious about how much one needs to get a "reasonable" E working
in Squeak without having to support too many libraries (e.g., for Croquet
scripting we really don't care too much about a UI framework etc).

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

Just FYI: If you're doing this because Squeak's compiler is so ugly and
because Squeak has no builtin parser generator or somesuch, there are some
really good alternatives. Check out SmaCC for example - by far the best
parser generator for Squeak and it's rocksolid. In addition to this there's
a _really_ nice "byte code assembler" for Squeak (done by Anthony Hanan). I
would think that unless the E parsenodes are much more complex than I'd
expect (no idea to be honest) it might actually be worthwhile building the
compiler in Squeak itself.

> In detail:
> - 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! :-).

See above. If you're using ESlang merely because you think it's too much
work to get a Kernel-E compiler going in Squeak I'd check out the above as
alternatives. If you've got any other reasons (like that you got it working
already for example ;-) using ESlang might be the right thing to do at this

> - implement the minimal E system primitives in Squeak

I think we should hook up with Rob to get a common understanding of what
that "minimal" set of support might need to be and how to implement it. I'd
hate to find out that we're redoing work Rob has already done.

> Great.  I've been occasionally looking at the site to see 
> whether there was code to download yet :-)

We took the download (90MB) away after we got slashdotted and haven't put it
up since we're trying to get a new version going. It'll be properly
announced (hopefully Very Soon).

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

I'm not suprised. And hopeful that this might get us a real step forward

  - Andreas