2009/2/9 Allison Randal <[email protected]>: > 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 > > _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
