[Glass] [GLASS] Compiling methods dinamically in

[James Foster via Glass]

On Dec 7, 2014, at 9:21 AM, AleDanos via Glass <glass at lists.gemtalksystems.com> wrote:
> 
> Hi, we're having some problems importing our *Pharo 3.0* code into GemStone.
> More specifically, meta-programing code.

Meta-programming is certainly an area where cross-dialect portability will be problematic. 

> In Pharo 3.0, given a class you can ask for its compiler and compile methods
> for it easily. These methods can then be run dynamically for a recipient
> object and the arguments the method requires.
> 
> In GemStone, we couldn't find this functionality of just asking a class for
> its compiler.

Right. In GemStone, the compiler is in C and always adds the compiled method to the class.

> Instead we found out that there's a message #compile found in
> the class methods for class Behaviour. We tried this message out and it
> compiles code (strings) but it automatically assigns the resulting method to
> the method dictionary of the class of the recipient object of the message.
> 
> Examples:
> In Gemstone, 
> 
>    C compile: 'hello', String cr, '^4'
> 
> ... running that collaboration would add a new method for message #hello in
> class C with the corresponding code. Instances of C now can answer to the
> message #hello
> 
> On the other hand, in Pharo 3.0
>    code := 'hello', String cr, '^4'.
>    aCompiler :=C compiler 
> 		source: code;
> 		requestor: nil;
> 		category: '';
> 		failBlock:  [ ^nil ].
> 	aCompiledMethod := aCompiler translate generateWithSource.
> 
> ...aCompiledMethod would be a compiled method "cooked" for instances of
> class C but it wouldn't be added to the method dictioary of Class C:
> instances of Class C don't know how to answer the message #hello. So, if we
> wanted to send the message "hello" to an instance X of class C then we would
> run that method with X as the recipient object and no arguments:
>    aCompiledMethod valueWithReceiver: X arguments: #()
> 
> ¿Is there a way to do something of the sort in GemStone? That is, compile
> methods dynamically without them auto-adding-themselves on the methods of a
> Class. In other words, to have standalone methods.

I don’t think GemStone has any direct facility to do this. You can create stand-alone methods as long as they don’t take any arguments (see String>>#’_compileInContext:symbolList:’), but not that take an argument. You could implement the #’valueWithReceiver:arguments:’ method to add the method to a subclass, use #’become:’ to switch ‘X’ to the subclass, and send the message, but this is pretty complicated. 

> Everything we did on Pharo 3.0 is coupled to the way we compile methods. We
> would like it if we could import our code into GemStone without having to
> rewrite everything.

You will probably need a compatibility layer in each dialect that implements common methods.

> The best solution would be to be able to move *all of the pre-existant*
> classes that we are using in Pharo 3.0 to GemStone. That way, our developing
> enviroment (Pharo 3.0) would be independent of our persisting environment
> (GemStone). ¿Is there a way to do it? More generally, ¿Is there a way to
> move all of *Pharo 3.0* to GemStone? I'm aware that Pharo has classes that
> wouldn't make any sense in GemStone, like the ones responsible for the GUI,
> but that shouldn't be a problem. They wouldn't make sense but they wouldn't
> hurt either.

Actually, I’ve been interested in this idea for some time. As part of the Maglev/Ruby project, GemStone added method environments to the system so that Ruby code could be executed without any direct interference from the Smalltalk code. While it would be a substantial effort, it should be possible to put most of the Pharo methods in GemStone's environment 2 (environment 1 is reserved for Ruby) and then just run as if it were a Pharo image (with appropriate bridge methods to call VM primitives).

I think this would be too much effort to make it worthwhile for any one project (such as yours), but if it were done it would be useful to all. Of course, there are a lot of things in life for which that statement is true.

James