<div dir="ltr"><br><br><div class="gmail_quote">On Tue, Jul 29, 2008 at 2:51 PM, tim Rowledge <span dir="ltr"><<a href="mailto:tim@rowledge.org">tim@rowledge.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="Ih2E3d"><br>
On 29-Jul-08, at 1:24 PM, Eliot Miranda wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
</blockquote></div>
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.</blockquote>
<div><br></div><div>The code generator I started with complains if the subclass redefines a method. Arguably this is a useful error check. So I modified the code generator to allow a subclass to explicitly remove superclass methods before adding its own. Trivial but effective.</div>
<div><br></div><div>Super is a different thing. I don't think there's any conceptual difficulty. Its simply another invocation of inlining. But the code generator's dictionaries of selector to method would have to be elaborated and its something I can do without for now.</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">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.</blockquote>
<div><br></div><div>Yep. Makes sense.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
<br>
<br>
tim<br><font color="#888888">
--<br>
tim Rowledge; <a href="mailto:tim@rowledge.org" target="_blank">tim@rowledge.org</a>; <a href="http://www.rowledge.org/tim" target="_blank">http://www.rowledge.org/tim</a><br>
Oxymorons: Soft rock<br>
<br>
<br>
<br>
</font></blockquote></div><br></div>