> Wow, Athena looks cool! I'd tried to leverage SmallWorld but not  
> got past
> the image being binary. I had wanted completely to build from source.

Source code of classes in SmallWorld may be easily extracted. Would  
be easier to do it with Athena however, mainly because I fixed few bugs.

> If Athena and Spoon and Dan's project and a few other projects and  
> people
> could get together somehow, then we might have something even  
> greater, and
> not several people working mostly on their own. But coming up with  
> a shared
> vision might be hard?

In my opinion, the key of success for JRuby, Rhino, JScheme, Jython  
is to enable interaction with Java. When Dan will release its source,  
I might port Athena on his VM. But again, interaction with Java is  
crucial.

> Here is an idea for using native Java/JVM objects for Smalltalk  
> objects
> instead of implementing them on top of the JVM as bytes. Smalltalk  
> method
> dispatching would be handled specially (above Java) but the instances
> themselves would be Java objects and use the Java garbage collector.

This is pretty much the same way Jython, JRuby and Rhino have.

> The "processMessage" function is essentially an elaboration of the  
> code I
> posted at the beginning of this thread. It knows how to look at the  
> proxy
> and decide how to send the message to it. There are at least three
> dispatching cases for a message. If the proxied object is a plain Java
> object, a function gets called if one matches the message pattern.  
> If the
> Java object has a "processMessage" method, it gets called. If the  
> object is
> a Java/JVM class "SmalltalkInstance" class instance, then Smalltalk- 
> ish
> dispatching happens, and the message can also be used as a stack  
> frame item.
> (This merging messages and stack frames is a departure from typical
> implementations and implies a big performance hit.)

This strategy makes sense. This is what is employed in most  
dynamically typed languages for JVM.


> For design simplicity and run-time extensibility, that  
> "SmalltalkInstance"
> class might have a few fields even if they were not usually all  
> used. They
> might be:
> * class (usually a reference to another "SmalltalkInstance")
> * dictionary of instance variables (not an array since I don't want to
> bother for recompiles in keeping things up to date, and for  
> debugging we can
> have symbols as selectors not indexes)

Are you sure that this dictionary is compatible with an efficient  
lookup ?

> * dictionary of locally overridden methods (for prototype support)

Why?

> * array of Java/JVM objects
> * array of binary data

What those arrays are for?


> Swapping object identities is handled at the proxy level -- the two  
> proxied
> objects are just exchanged. So you can see the Proxy level is  
> acting a bit
> like an object table.

Is the swapping related to implement "become:"?
Why would you need this? Since you relying on the Java memory model,  
only Java object that have been "proxyied" may be involved in a  
become operation right? Any motivation for this?

> "Becomes" might be handled by changing the became field to true and  
> then
> changing the proxy to the new object. After that, the dispatching  
> will work
> differently and just be passed onto the new object without further  
> processing.

As far as I can tell, most other languages do not provide become. In  
Smalltalk, become is mainly used to do some update in case of changes  
in class definition. Why do you want to keep it if this Smalltal on  
JVM will be file-based ?

> Calling into Smalltalk from Java I haven't thought through. I know  
> Jython
> does it but I have not looked at that. I suspect you could  
> intercept an
> exception and do something. I'm assuming exceptions could go up the  
> message
> stack, but I admit that throwing them across intervening Java  
> function calls
> within the method stack could be problematical -- the message stack  
> might
> need to be annotated somehow in those cases before calling the  
> function,
> another performance hit.

You're right. An exception thrown in a different world may be  
problematic.

> Now, this approach has a higher memory cost. And it also has a loss of
> runtime performance for Smalltalk code. But I think if you merged  
> in support
> for Scala (a JVM language which is typed and fast) to compile  
> bottleneck
> code from Smalltalk->Scala->JVM, the hybrid mix might be pretty fast.
> Equivalent to the successful CPython/C mix. Or that would be my  
> hope at least.

I feel that to tackle the performance issue, having a bytecode  
translator Smalltalk -> Java would be an acceptable approach.

> Anyway, just outlining some ideas. Not sure if they will work out in
> practice. :-)

Thanks for your intervention Paul,

Regards,
Alexandre

>
> Bergel, Alexandre wrote:
>>> Does it have nay hope to be supported by a community? Does it take
>>> advantage
>>> of the Java/JVM platform, including threading and multi-processor
>>> support?
>>> Or interoperate easily back and forth with Java libraries like  
>>> Jython
>>> can?
>>
>> I haven't looked at deeply, but I strongly suspect that no  
>> interaction
>> is actually possible with Java.
>>
>> I am currently working on this.
>> http://bergel.eu/athena for more info
>
>

-- 
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.