Allison Randal schrieb:
I'm in the midst of adding the feature for loading HLL bytecode. We
have a few options here, so I'll list them out for HLL developers (we
talked about it on IRC last week, but not all the language devs were
there). I give full system paths here as an example, but the actual
path is determined by where Parrot finds the main compiler file for
the language.
Is there already support for: "Give me the location from which a
particular bytecode file was loaded"?
1) Calling the opcode:
load_language 'foo'
adds
/usr/lib/parrot/1.0.0/languages/foo/include
/usr/lib/parrot/1.0.0/languages/foo/dynext
/usr/lib/parrot/1.0.0/languages/foo/library
to Parrot's standard search paths.
Can that work, if a want to override search pathes from the command line
params or via environment variables?
2) Same as (1), but instead of adding the library/ path to the
standard search path for libraries, it's added to a language-specific
search path. Code from this location is then loaded with:
For interpreters that support multiple languages I would vote up support
for language specific search pathes.
For example, Pipp has a run-nqp and a run-pir option.
load_hll_bytecode 'foo', 'mylib.pbc'
or, for the currently selected HLL, just:
load_hll_bytecode 'mylib.pbc'
3) Same as (2), but also add support for compiling the file from HLL
source (not just from bytecode/PIR/PASM):
load_hll_bytecode 'mylib.foo'
This would follow a set of fallback rules, probably HLL source -> PIR
-> bytecode (though I could see making bytecode or PIR the default
for speed).
For cases where the file extension doesn't match the language name,
we'd add a variant of load_language that takes a second argument
specifying the file extension:
load_language 'foo', '.fo'
Thoughts, concerns, more ideas?
Allison
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
