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.

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?

Here are some ideas for Java<-->Smalltalk interoperability. Not necessarily
stuff you might want to do with Athena (for memory reasons), but I put it
here for future reference (including a possible future reply to Dan). This
is just a sketch, and assumes an ideal of ignoring memory use for ease of
implementation, debugging, and minimizing complexity.

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.

Have a Java class "SmalltalkProxy" which supports one method like
"processMessage". That function takes an argument of a
"SmalltalkMessageAndStackFrame" which essentially stores the information in
a message and then, if the message is processed, some stack information.
This SmalltalkProxy class has only two fields -- the proxied Java/JVM
"Object" and a boolean "became" flag.

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

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)
* dictionary of locally overridden methods (for prototype support)
* array of Java/JVM objects
* array of binary data

Obviously, that expanded structure might be what is tried at first, and then
optimizations of all that might be made later.

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.

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

One can also merge the Smalltalk and the SmalltalkInstance class, but
swapping then becomes a matter of exchanging the embedded Java objects.
However, then directly proxied Java objects can no longer easily have their
identities swapped (it would require directly replacing all references in
all Smalltalk instance objects). But that might be OK -- you'd just get an
exception that Java objects cannot support "become".

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.

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 might even throw Jython into the mix too. :-) Here is a Smalltalk-like
parser in Jython:
http://patapata.svn.sourceforge.net/viewvc/patapata/tags/PataPata_v204/Pointrel/smalltalkToPython.py?revision=315&view=markup
that could be elaborated on for bootstrapping into a pure
Smalltalk-in-Smalltalk-on-the-JVM compiler.

One could then build tools within this Squeak-like environment which support
Smalltalk, Scala, Java, and Jython in an Eclipse-like way (maybe even
pulling in Eclipse components entirely -- it's just Java right?), but using
an RDF-like (or Pointrel-ish) approach for storing content instead of files.
And the image would be written out by the proxies as Smalltalk source
code,making for a slower loading and writing process, but an understandable
image. SO it's a polyglot system. :-) I wrote on that in 1996 (was that
really twelve years ago?
   "Squeak and the Babel of programming languages"
to Squeak list. Would be nice to finally see it happen on a free platform.

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

--Paul Fernhout

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