I was asked via email about Squeak's compatibility with the Erlang approach 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 might 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 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
gsctranslates into C. Then
gcctranslates into machine code. Ah, that's why you also want something like
gsiaround for the source language.
That would be a fun and useful project to work on.