Dan Sugalski <[EMAIL PROTECTED]> wrote:
The interpreter stuff's simple enough--we teach the ops preprocessor to handle them the same way that it does string constants, and index into the PMC constant table. We'll want to put them in a separate part of the bytecode file,
Why I second table? This just adds duplicate code paths and complexity. One constant table ought to be enough.
Mainly because I was assuming that we were going to separate the float, pmc, and string constants into separate tables for locality-of-reference reasons and ease of doing reflective access. (Or something line that...)
> so we can fully expose bytecode files to running code. And we need tofinish that fight over freeze/thaw methodologies, as constant PMCs would end up being frozen in the bytecode.
The freeze/thaw internals can change. We only have to invalidate existing PBCs, if the frozen image format differs.
Yep. I thought there was still some outstanding stuff, but it might just be dodgy memory on my part.
> As for the actual declaration of the constants... That's going to besomewhat interesting. I can see one of two ways of doing it:
1) we execute the initialization code at compiletime and freeze the result 2) We compile the initialization code and execute it at runtime to create the PMC
It probably depends on the PMC. *If* there are any side effects, initialization has to be done at run time.
Yeah, but we have to pick one. :( -- Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
