Strongtalk VM?

[Mark Haniford]

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?  Are the semantics of Slate to foreign for a Smalltalk VM?   I noticed that a couple people wanted the Lisp interpreter for Slate.  Does anybody have any specific plans for working on Slate?

[Jecel Assumpcao Jr]

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?  Are
> the semantics of Slate to foreign for a Smalltalk VM?   I noticed that a couple
> people wanted the Lisp interpreter for Slate.  Does anybody have any
> specific plans for working on Slate?

The most visible feature of Slate, the multiple dispatch, can be
reasonably emulated on a Smalltalk VM either by generating extra methods
without any changes to the VM (a bit like Squeak now implements Traits)
or more efficiently by a reasonably simple change to the VM. It took a
while for me to convince myself that this was the case since I didn't
know about some restrictions on Slate's dispatch. Then I posted the
extra method solution here, but I can go into it and the other one again
if there is interest.

Other things like optional arguments and multiple viewpoints are much
more complicated.

--Jecel

[Brian Rice]

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

[Mark Haniford]

On 10/16/06, Brian Rice <water@...> wrote:

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.

    These days, x86 only (as an initial cut) is not as problematic as Windows only.
 

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.

   Not enough time, and not enough technical chops (me included).   At the time they probably didn't know or care if it was going to go open source, but I think that C++ tends to obfuscate something like a VM and raise the barrier to entry.  Straight C probably would have been better for something like that.  But of course the big hurdle are people that have willing time and strong VM experience to actually work on it.

>   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.

That's what I figured.  You not only would have to have strong knowledge of the Strongtalk VM, but also of how to adapt it to Slate

 

>    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 agree.  It would be great if someday someone would just drop a note saying they have a fast performing Slate compiler/VM.  I think open source in general tends to have a over-hyping effect.

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

[Brian Rice]

On Oct 16, 2006, at 4:03 AM, Brian Rice wrote:

> 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.

This has been fixed now. The Strongtalk VM SVN sources now build and  
run from VS 8 as indicated here:
http://groups.google.com/group/strongtalk-general/msg/f9be4c11fae7536c

They still require large vcproj/solution files due to the use of  
precompiled headers, so those are attached to Dave Griswold's message  
and not in SVN yet. Perhaps that will be rectified soon.

--
-Brian
http://briantrice.com

[John Leuner-2]

On Thu, 2006-10-12 at 19:35 -0500, 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?  Are the semantics of Slate to foreign for a Smalltalk VM?
> I noticed that a couple people wanted the Lisp interpreter for Slate.
> Does anybody have any specific plans for working on Slate?

I was interested in the Lisp interpreter because I remember being
impressed that such a fairly complete language could be implemented in
only a few thousand lines of lisp code.

Since then I've become proficient in Common Lisp and wanted to look at
it again.

Are there any other 'model' implementations of interpreters for 'more
than a toy' languages?

John Leuner

[Slava Pestov]

Here is a compiler written in CL which targets CL:

http://homepage.mac.com/kpreid/elang/e-on-cl/

Slava

On 25-Oct-06, at 8:02 AM, John Leuner wrote:

> Are there any other 'model' implementations of interpreters for 'more
> than a toy' languages?
>
> John Leuner
>
>

[John Leuner-2]

On Thu, 2006-10-26 at 01:23 -0400, Slava Pestov wrote:
> Here is a compiler written in CL which targets CL:
>
> http://homepage.mac.com/kpreid/elang/e-on-cl/
>

Thanks Slava, it might also be interesting to compare it to his Haskell
implementation
http://www.eros-os.org/pipermail/e-lang/2006-June/011352.html

John

> On 25-Oct-06, at 8:02 AM, John Leuner wrote:
>
> > Are there any other 'model' implementations of interpreters for 'more
> > than a toy' languages?
> >
> > John Leuner
> >
> >
>