Storing Classes in Bytecode

[Jonathan Worthington]

On 02/08/2010 08:05, Peter Lobsinger wrote:
> On Fri, Jul 30, 2010 at 8:08 PM, Jonathan Worthington
> <jonathan at jnthn.net>  wrote:
>    
>> Here's one critical thing, however. This is _not_ about a constant segment.
>> I could have a module...
>>
>> class Lolspeak {
>>    method lol() { say "oh lol" }
>> }
>>
>> That I pre-compile to a PBC. I then do in a script:
>>
>> use Lolspeak;
>> augment class Lolspeak {
>>    method wtf() { say "omg you forgot a wtf method?" }
>> }
>>
>> Which would call .add_method on the meta-class which would then have to
>> change its internal state to know about the new method. Thus these things
>> aren't constants once they're loaded into memory (they *may* be, but not by
>> default). Same for subs, which we may end up calling .wrap on. Really,
>> they're just objects we've serialized, and want to deserialize at startup.
>>      
> "Constant" is a bit of misnomer. The objects contained in a PBC
> constant segment are not immutable simply by originating there. It is
> simply a collection of strings and PMCs associated with a segment of
> bytecode. This may be useful for implementing constants, but it is not
> limited to that.
>
> .sub 'consty' :anon :immediate
>      $P0 = new ['String']
>      $P0 = "Hi"
>      .return ($P0)
> .end
>
> .sub 'main' :main
>     .const 'Sub' $P0 = 'consty'
>     say $P0
>     $P0 = "Lo"
>
>     .const 'Sub' $P1 = 'consty'
>     say $P1
> .end
>
>    
OK - does the GC actually walk through the things referenced from this 
segment too? If so, then yes, we probably could get away with using the 
"constant" segment (and maybe rename it :-)).


>> A tricky issue that will need some thought is if I then wrote:
>>
>> use Lolspeak;
>> class MoreLolspeak is Lolspeak {
>>    method omg() { say "OMG you accidentally the WHOLE MOP!" }
>> }
>>
>> Then the meta-object for MoreLolspeak is going to reference the one from
>> Lolspeak. Somehow, there will need to be some "bounding" on what we freeze
>> and a cross-PBC way to do referencing. That's going to be tricky, but
>> important. Alas, I've probably introduced enough things to ponder in this
>> email so far, and it'd be good to get some reactions. :-)
>>      
> On the surface it is tricky, but there is a simple answer: let the
> class implementation take care of it.
No, that answers nothing. I think you missed the point of what I was 
saying. There will be no class implementation that isn't itself just an 
object. Put another way, everything is going to be an object, it's just 
that one of them will happen to implement the MOP in a way that 
specifies the semantics of something that we consider class-y.

> If it is desired that classes not recurse indefinitely up the chain of ancestors, the class freeze/thaw vtable implementation should serialize only the names of
> the resources it requires,
Even if there was something we could identify as a "class" and choose to 
give it different serialization semantics, this still doesn't help us if 
we want to serialize an object whose type object/meta-objects live in 
another PBC.

>   looking them up symbolically upon deserialization.
>    
Won't work with anonymous classes.

> Alternate solutions exist such as configuring or overriding (eg:
> through hll_mapping) the serializer to do similar things, but these
> are likely not as clean or as simple.
>    
No, the clean solution is to make the general mechanism I originally 
proposed. I know it's not _simple_ - but I suspect something simpler 
than it falls short of requirements.

>> I imagine that however other HLLs choose to represent their classes, they'll
>> all benefit from being able to get them into the PBC. This is something we
>> could integrate some support for into HLL::Compiler, perhaps. Not to mention
>> it's a solution for other constant objects too.
>>      
> A better API for getting at this and other PBC functionality would be
> very useful.
Aye though I'd like to keep the API for this mostly apart from PBC.

> This will probably come about quite naturally from
> efforts to cut PIR out of the PCT compilation sequence. A better API
> within PIR is also possible by making the current PIR compiler
> accessible as an object in :immediate subs.
>
>    
I wasn't expecting to use intermediate subs at all. We'd just create the 
objects from action methods and add them to the serialization context. I 
shouldn't have to compile code to make the objects I want, I should just 
be able to Foo.new 'em.

Thanks,

Jonathan