question on loading HLL bytecode

[François Perrad]

2009/2/9 Allison Randal <allison at parrot.org>:
> In a step toward the milestone task on building external languages, I've
> added a new opcode 'load_language'. I takes a single argument, the name of
> an HLL, and locates the main language compiler file in one of 3 standard
> locations and loads it. Either:
>
> languages/abc/abc.pir
> (for languages in the repository in the standard directory)
>
> or
>
> runtime/parrot/languages/nqp/nqp.pir
> (install location in a working copy for languages in the repository but not
> in the 'languages/' directory, or for languages outside the repository)
>
> or
>
> /usr/lib/parrot/languages/perl6/perl6.pir
> (real install location, also configurable by --prefix)
>
>
> The 'load_language' opcode also adds the include and dynext paths relative
> to that main compiler file to the standard search. Either:
>
> languages/abc/include
> languages/abc/dynext
> or
> runtime/parrot/languages/nqp/include
> runtime/parrot/languages/nqp/dynext
> or
> /usr/lib/parrot/languages/perl6/include
> /usr/lib/parrot/languages/perl6/dynext
>
> It doesn't add the language library path to the standard library path,
> because that would collapse all the namespaces for all the HLLs. The
> language search paths will also be relative to the main compiler file:
>
> languages/abc/library
> or
> runtime/parrot/languages/nqp/library
> or
> /usr/lib/parrot/languages/perl6/library
>
> So, here's the question: Is it better to add a two-argument form of
> 'load_bytecode' so you can specify:
>
>  load_bytecode "hllname", "path/to/MyLib.pir"
>

Currently in install tree, Lua cannot load extension libraries.
So, I want use this two-argument form : load_bytecode 'lua',
'library/complex.pbc'
in order to find :
   languages/lua/library/complex.pbc (build tree)
or
   lib/parrot/0.9.1-devel/languages/lua/library/complex.pbc (install tree)


In luap.pir, I could replace :
  load_bytecode 'languages/lua/lua.pbc'
by
  load_bytecode 'lua', 'lua.pbc'
or
  load_language 'lua'

With load_language 'lua', lua_group.[dll|so] could stay in languages/lua/dynext.

François.

> Or, to treat any path passed to 'load_bytecode' that starts with
> 'languages/hllname/' as a "virtual path"?
>
>  load_bytecode "languages/hllname/path/to/MyLib.pir"
>
> I prefer the first, as it's a cleaner interface, and better separation of
> code that does very different things. Also, it could be extended so that
> passing in an HLL source file automatically compiles it to PIR/bytecode if
> the PIR/bytecode doesn't exist already:
>
>  load_bytecode "nqp", "path/to/MyLib.nqp"
>
> Does the two argument form potentially cause problems for compiler writers?
> I'm especially thinking of generated code.
>
> Allison
> _______________________________________________
> http://lists.parrot.org/mailman/listinfo/parrot-dev
>
>