On Wed, Jul 12, 2006 at 12:18:51PM -0700, Allison Randal wrote: > Leopold Toetsch wrote: > > > >Well, there was already one very legitimate usage of compile time > >loadlib, which is now using C<.loadlib> for that: > > We certainly need both compile-time and runtime loading of libraries. > So, it's just a question of which syntax to use for which case. > > chromatic suggests .include for "load this library at compile and run > time". The .include directive is currently being used to mean "inline > the entire source code for this file here". But, I've always thought of > that as a hack we put in before we had library loading working. Any > thoughts?
I think I'm confused by or totally misunderstanding the proposal. I think we have two very different sorts of "library" at play here: dynamic libraries (with a .so extension on my system), and libraries of parrot code (with .pir, .pbc, and .pasm extensions). IIUC, the loadlib opcode (and the new .loadlib directive) are used strictly for dynamic libraries -- on my system those are files with .so extensions. loadlib and .loadlib aren't used for .pbc files... that's the domain of the load_bytecode opcode. load_bytecode can be used for loading .pbc/.pir files at runtime, at load-time via :load, or at compile-time with :immediate. .include is currently compile-time only, and only works with .pir/.pasm files (i.e., one cannot "include" a .pbc). In addition, any .included source honors the current .HLL and .namespace settings, which isn't true for files (.pir/.pbc) that are obtained via load_bytecode opcode. So, if the proposal is that ".include" means load a .pbc/.pir library whenever the including file is compiled or loaded in a manner analogous to load_bytecode, then I'm still wanting a way to get source files that are compile-only and honor any .namespace directives. But as I said, I think I must be misunderstanding what is being said, so feel free to re-explain or correct my misunderstanding. Pm
