etoys implementation

[Yoshiki Ohshima]

  John,

  I separated the real Etoys implementation part from your email.
Hopefully it helps to focus on different aspects of discussion.

> It took some searching, but I found a paper on the design of the guts
> of Squeak:
> 
>   ftp://st.cs.uiuc.edu/Smalltalk/Squeak/docs/OOPSLA.Squeak.html
> 
> I don't know if it is still good documentation for the current
> implementation, but it gives some idea of how Squeak was originally
> built.

  At the basic part on how it works, the paper is still valid and
good.  The performace increased since then quite a bit, and there are
other semi-major improvements, but that is ok.  Probably you can find
a copy of the proceedings (OOPSLA '97) somewhere if you like the paper
version.

> The interpreter was written and maintained in a subset of high-level
> Squeak (smalltalk) but there's also a translator that translates
> that interpreter into C, which is then compiled to produce a binary
> interpreter.  Whether it does this dynamically or statically I have
> no idea.

  Because it is into C, it is statically done.  In the later versions
and platform that support loading shared libraries (called "plugins")
onto the VM, you could write some code for plugin in Squeak, generate
C, compile the C code to make a shared library and load it onto the
running Squeak session.  But that is besides the point.
  
> Then there's a separate Compiler that turns
> Squeak/Smalltalk source code into bytecode objects that the
> interpreter can run?

  Yes.  The Compiler is written in Squeak and the compiled result of
the Compiler itself is in the image.

> There's another page that purports to talk about how a Squeak image is
> built, but after explaining how most people "never quite feel at home
> in a Squeak .changes file", it degenerates into details that make no
> sense to an outsider.

  The paper definitely serves its intended audience (programming
language designers and implementors.)  The paper is cited quite often
by papers from other language communities.

> I haven't yet found similar documentation for eToys, which is
> apparently something "built on" squeak rather than "built in"?

  Where did you find built on vs. built in discussion?  It doesn't
sound like an important distinction.

  The Etoys system is a bunch of additional code written in Squeak.
There are some deep changes in the base classes of Squeak to support
Etoys so it just happen to be distributed as a separated packaged
version called Etoys.

  There is no good documentation (as far as I know) on how Etoys is
implemented other than the source.  But again, the code is nicely
hyperlinked and the live system is there, learning it is possible if
you know Squeak.  (Etoys is like an application.  How many
applications you use have good documentation how they are implemented,
though?)

> There's also a warning at http://wiki.squeak.org/squeak that if you
> want to run eToys, you need to run a different version of Squeak than
> everybody else.

  *That* is Etoys.  What is wrong with it?

-- Yoshiki