My take on the issue:
-> it is easy to take Smalltalk and make it “less Smalltalk” and then compile
that to JVM (no become, no thisContext, with all consequences).
-> What the Smalltalk community should be doing (should have been doing): Make
Smalltalk "more Smalltalk”.
Marcus
On 28 Dec 2013, at 11:40, Clément Bera <[email protected]> wrote:
> Main problems to compile Smalltalk to java bytecode:
> - there's no context in java. This means our implementation of continuations
> and exceptions is not valid anymore. This also means we cannot have a
> debugger with edit-and-continue as we have now.
> - there's no become:, which is used to keep the system live
>
> Basically you can find tricks to still have become: and a live
> environment/debugger but in this case the Smalltalk created would be super
> slow.
>
> So compiling smalltalk to java is not an easy problem.
>
> Now compiling Pharo to the gemstone VM should be possible and not as hard.
> The complexity depends mostly on how well the gemstome contexts are
> implemented.
>
>
> 2013/12/27 Stéphane Ducasse <[email protected]>
>
> On 27 Dec 2013, at 18:21, Andy Burnett <[email protected]>
> wrote:
>
>>
>> <<<From: St?phane Ducasse <[email protected]>
>>
>> The fun is important.
>> What we want is well designed and powerful libraries that enabled people.
>> For the JVM question: it is a question of resources + the fact that jvm do
>> not really support well some key smalltalk operations.
>> Now I do not understand why people develop their own vm instead of joining
>> forces.
>> Doing in the long term something and finishing a task are the most difficult
>> things.
>> Stef
>> ᐧ
>> >>>
>>
>> Thank you to everyone for your comments. I am replying to Stephane's email,
>> just as a catch all.
>>
>> I am curious to know more about the limitations in the JVM. My thinking was
>> sparked - in part - by Mark Roos's work on RTalk.
>
> I was not aware of that one :)
> So this means that we have gravel, redline and Rtalk.
>
> http://i.cmpnet.com/ddj/images/mediacenter/jvmlanguagesummit/2011_Roos_Rtalk.pdf
> I understand the motivation behind Rtalk and this is cool that they succeeded.
>
> Now what people often forget is that behind the technical challenges you have
> the libraries and the boring but important work
> of building greta frameworks.
>
>> I realised, after my post, that he had actually worked the other way around,
>> i.e. I think he built a Digitalk bytecode layer on top of the JVM, rather
>> than compiling to JVM bytecodes.
>>
>> Either way, what I was vaguely wondering about was how difficult it would be
>> to have a 'compile to JVM' option in Pharo. I could probably live - quite
>> happily - developing in 'real' Pharo, and then deploying an app to e.g.
>> Google App Engine, as a compiled Jar. Obviously, it would be much better to
>> retain all the dynamism of a true Smalltalk environment even when the app
>> has been deployed, but it it gave simple hosting, and scaling, it might be a
>> reasonable trade off.
>
> I do not know because the problem is that on such topics the devil are in the
> details.
> Now what is important is having a bootstrap and clean test covered code base
> because we could also see how to deploy
> a gemstone vm or other platform in the future.
>
>> I agree with Stephane, it would be great for people to join forces around a
>> vm. Would make like so much easier.
>>
>> Cheers
>> Andy
>>
>>
>
>
