Re: Strongtalk VM?

On Oct 12, 2006, at 5:35 PM, Mark Haniford wrote:

> I've seen Brian on the Strongtalk mailinglist, but I thought I  
> would bring up the Strongtalk VM here.  My question is if it could  
> be used for Slate?

Strongtalk has several issues. I'll try to give a quick overview:
1) It is not portable at all, designed only for mid-to-late-90s  
Windows on x86 processors. It needs work just to compile with a  
modern MS Visual C++ compiler. The compilation code only deals with  
x86, not just in the dirty details, but in the protocols as well.
2) The compiler is built into the VM instead of above it.
3) Not enough people understand the VM mechanics yet that make all of  
this work.

Strongtalk does have the benefit that it was designed with proper  
block-closure semantics in mind. It does not have excellent floating- 
point infrastructure or thought given to FFI beyond the very basics  
that their in-development prototype needed.

>   Are the semantics of Slate to foreign for a Smalltalk VM?

Yes, to a reasonable extent. Smalltalk-80 hackers do enjoy pointing  
out how multi-dispatch and prototypes/delegation can be implemented  
atop their VM's. This is a bit glib, because the overheads are real,  
just as real as if we were to blithely assert that everything that  
Haskell compiles well could certainly be compiled for the Slate VM,  
that PMD gets most of pattern-matching done easily enough. It's true,  
but disingenuous - by using primitives that suit a certain level of  
abstraction, it frees the programmer from the economic burden of  
having to count the cost of that abstraction.

That said, the hotspot-style inlining benefit would be much greater,  
I'm guessing; for the same reasons, since Slate was *created* with  
the economic goal in mind that the Strongtalk developers gave the  
Smalltalk community a glimpsed vision of.

>    I noticed that a couple people wanted the Lisp interpreter for  
> Slate.  Does anybody have any specific plans for working on Slate?

Don't expect people to commit to such things publicly in an open- 
source community - it engenders a sense of owing and expectation  
which is discouraging.

I would still like to encourage new approaches, ones that might give  
us a lot simpler road forward than what we had. I think the threaded- 
code interpreter idea has merit, but the Strongtalk idea is much  
better when discussing conceptual merges rather than concrete ones.  
If you doubt me, try reading and grokking the Strongtalk VM code and  
present evidence (or working code) that supports your ideas.

--
-Brian
http://tunes.org/~water/brice.vcf