Leopold Toetsch wrote:
This means, we'd have:
.include "file.pasm/.pir" ... load macros or constants (no code)
>
load_bytecode "file.pbc" ... load a "module"
$P0 = loadlib "file" ... load a shared lib (pmc or ops)
.loadlib "file" ... same during compilation
The 5 parameters are runtime vs. compile-time, C library vs.
.pasm/.pir/.pbc, and "inline a file".
The .include directive doesn't actually load a library, it just inlines
a file. (The reason it respects .HLL directives and such is not because
it's incredibly smart, but because it's incredibly stupid. If you have
.namespace directive in the inlined file, it will apply that namespace
to any code in the original file that follows the .include directive.) I
like .inline better than .include for this, but I also don't see any
urgent need to change the name of the directive.
I like .loadlib (for C libraries) as long as it's both compile and run
time. That's the most common case of all, and so deserves the best
syntax. And, the loadlib opcode is a clear parallel for the runtime
variant. For the extremely rare case when you want to load a C library
at compile-time but not at runtime, you can still use the loadlib opcode
inside a :immediate sub.
load_bytecode is good for runtime loading of PASM/PIR/PBC. A logical but
unexplored option is compile-time loading of PASM/PIR/PBC. Some things
that are currently being done with .include could be better expressed by
a compile-and-run-time .load_bytecode directive.
Allison
