On 29-Jul-08, at 1:24 PM, Eliot Miranda wrote:
>  What I'd like to do is modify Slang so that one can mix and match  
> components to produce the VM you want.  In the StackVM I'm working  
> on I already have the ability to add a subclass that overrides  
> methods in the superclass so NewObjectMemory organizes the young  
> generation differently to ObjectMemory overriding a few methods.  It  
> should be easy to extend this to allow e.g. ImmutabilityInterpreter  
> to override Interpreter and add immutability without having to  
> rewrite the entire Interpreter class.
I'm fairly sure that should have worked without any extra work since  
it is essentially how the codegen works anyway. What *doesn't* work is  
adding  subclass and being able to use 'super' to only slightly modify  
the superclass code. I tried to get it working some years ago in an  
attempt to make it easy to implement OS specific plugin classes more  
easily but it drove me too close to the edge of insanity for my  
liking. If you've got *that* working I'd be very pleased.

Another aspect of pick'n'mix I'd like to see working is having all the  
parts of the vm in plugin (or plugin-like) modules. Why insist on  
having the GC irrevocably bound into the core (just for one example)?  
Why not have a system that can startup with no GC code; let the  
image's policy decide which GC plugin to load dependant upon need. An  
ephemeral app invoked to do a tiny job and quit may need no GC  
functionality at all so why waste space and setup time? A server app  
might want to use a much more sophisticated GC than our typical  
desktop system. Or perhaps the system should start up and run as a  
simple interpreter for a while until a policy has decided that Eliot's  
translator plugin should be loaded. And so on.


tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Oxymorons: Soft rock