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