[PRL] Patrick Logan: I still think Kelsey was right all along

[Mitchell Wand]

Anybody interested in doing something like this to compete in the Erlang
space?

---------------------

    *Making it stick.* <http://patricklogan.blogspot.com>
Patrick Logan's weblog.       I still think Kelsey was right all
along<http://patricklogan.blogspot.com/2006/06/i-still-think-kelsey-was-right-all.html>By
Patrick Logan

 This Kelsey<http://portal.acm.org/citation.cfm?id=75302&dl=ACM&coll=portal>.


I was asked via email about Squeak's compatibility with the Erlang
approach<http://erlang.org>to concurrency.

I'd thought a little about this for Smalltalk when I worked at Gemstone. I
don't know enough about the Squeak VM to talk about it. Like Erlang's and
Gambit Scheme's VMs, it would require the ability to create many 1000's of
non-OS threads very quickly and run them all fairly. I think Cincom's
commercial Smalltalk VM can approach these numbers.

Other approaches might be to implement Squeak's VM in Gambit Scheme or use
the Squeak compiler's front end to generate Gambit Scheme code, i.e. give
Squeak a new back end. Maybe one way to do this is to replace Squeak's C
code generation with Scheme. If I recall, there is no C code in Squeak, but
there is a Smalltalk subset used for the core of the VM implementation and
that subset is translated fairly simply into C. If that could be retargeted
into Gambit Scheme then you might be off to the races. The Process class,
etc. would have some finagling to get them more directly mapped to Gambit's
thread procedures.

One thing about Erlang, and Termite processes (if you don't cheat and go
down to the Gambit level) is they are "shared nothing", while Scheme threads
and Smalltalk processes are "shared everything". You may want to keep the
current Smalltalk definition of Process the way it is, and come up with some
new class, e.g. "SharedNothingProcess" that provides the new approach. Then
you can run "legacy" code but try to enforce a better concurrency model.

Gambit has per-thread mailboxes and thread-local
storage<http://www.iro.umontreal.ca/%7Egambit/doc/gambit-c_12.html#SEC53>which
can be used for this. Smalltalk globals would be considered "bad
legacy" and you could try to give thread-local variables a decent syntax.

Implementing a new Smalltalk, moving Gnu Smalltalk, or moving Ruby to Gambit
Scheme would be much easier than doing anything with Squeak. *And guess
what? Scheme *has* continuations. 8^P* (I bow to the noble porters of Ruby
to really bad VMs. "Continuations" shows up on each of their web pages ---
on the "to-do" list.)

But Squeak has a lot of cool stuff. Croquet would figure in there somewhere
when it comes to distributed VMs.

What did Kelsey get right?

* Using concepts from denotational semantics, we have produced a very simple
compiler that can be used to compile standard programming languages and
produces object code as efficient as that of production compilers. The
compiler is based entirely on source-to-source transformations performed on
programs that have been translated into an intermediate language resembling
the lambda calculus. The output of the compiler, while still in the
intermediate language, can be trivially translated into machine code for the
target machine. *

In this case the "trivially translated into machine code" means Gambit is
the intermediate language. Then gsc translates into C. Then gcc translates
into machine code. Ah, that's why you also want something like gsi around
for the source language<http://www.dehora.net/journal/2005/02/programmers_block.html>.


That would be a fun and useful project to work
on<http://patricklogan.blogspot.com/2006/06/portland-programming-language-capital.html>.
-------------- next part --------------
HTML attachment scrubbed and removed