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.
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.
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:
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
