2009/2/22 François Perrad <[email protected]>: > 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. >
Allison, Have you make some progress on this point ? In which version, these new opcodes will be available ? 1.0 or after 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
