loading HLL bytecode

[Allison Randal]

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