Dan Sugalski <[EMAIL PROTECTED]> wrote: > Well... not necessarily. The original scheme was for the opcode > loading code to specify what numbers the loaded opcodes would get for > the compilation unit in question.
Opcode numbers only aren't sufficient. The compiler checks argument count and types too. It needs additionally the PARROT_ARGDIR_* flags for life analysis and PARROT_JUMP_* for generating basic blocks. The whole information is in the C<struct op_info_t>, which is loaded in at compile time. Having a totally different scheme for loadable ops isn't really a good thing. *If* we allow a different order for loaded ops at compile vs run time, we need additional information in the metadata, to be able to relocate the range of dynamic ops. It's a matter of taste, if we allow that or if we just state: <loadlib> opcodes for dynamic oplibs have to be seen by the compiler in runtime order. I'd for now go with option three which was: don't load dynamic libs which aren't constant strings. BTW: is it really needed to specify a dynamic extension by variable name? leo
