Re: Strongtalk VM?
Brian Rice <water <at> tunes.org>
2006-10-16 11:03:36 GMT
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
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.