[DGD] happycode in DGD

[bart at wotf.org]

2 comments at first glance:

On Fri, 6 Sep 2013 16:55:49 -0700, Raymond Jennings wrote
> thanks to an enlightening chitchat with aidil, I think I have a basic
> gameplan for implmeenting happycode in DGD
> 
> First off, each happycode snippet is compiled on the spot along with 
> the rest of the source code it is with.
> 
> Second, happycode snippets are split off into their own heavyweight objects
> after being morphed into bytecode for the vm.
> 
> Third, code in the defining object that emits function pointers is tagged
> with a reference to the happycode object in question.
> 
> Fourth, function pointers use that tag to know which happycode 
> object to execute when they are referenced.
> 
> Fifth, happycode objects are garbage collected similiarly to kfuns, and
> automatically nuked when they are proven to be orphaned.
> 
> Sixth, destructing a  source object also nils out any happycode objects
> built from it.
> 
> Seventh, it is an error to recompile an object in such a way that happycode
> objects refering to it lose track of variables.  So if you have happycode
> refering to object scope variables, you can't remove those vars in 
> the new program.

How do you intend to enforce this beyond saying "don't do that" ?

> 
> Eighth, new happycode objects are generated as needed each time a source
> object is recompiled.  I decided to avoid the entire conhjflict between
> closures and recompiling by "freezing" the bytecode inside the happycode
> object when it's compiled.  So happycode never recompiles.  I tjust floats
> until it becomes unreferenced.

How to provide access to inherited code, and ensure the sniplet does get
recompiled (based on the same lpc code it had when it was initially compiled)
when those inherits get recompiled? Not doing so will result in old versions
of this inherited code staying around until all objects referencing it will be
gone.

Bart.

--
http://www.flickr.com/photos/mrobjective/
http://www.om-d.org/