On Fri, Mar 27, 2009 at 12:06:27AM -0500, Allison Randal wrote:
> 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.
...none of these match exactly the way I would envision things.
I think that loading HLL libraries (especially those involving HLL
source) ought to be handled by the HLL's compiler object and not
brought down to a parrot opcode. In particular, a sequence more
like:
load_language 'foo'
$P0 = compreg 'Foo'
$P0.'load_library'('mylib')
While PCT's HLLCompiler object can provide a standard to be
shared by Parrot languages, placing the logic in the
HLLCompiler (instead of an opcode) enables HLLs to
override the 'load_library' semantics for the cases
where they need additional or specialized handling.
For example, they can select a different fallback, select a
library to be loaded based on criteria beyond just a (file)name,
provide additional options to be used as part of the compilation,
check additional search paths beyond Parrot's defaults (e.g.,
based on environment variable settings), etc.
In short, I think language and library loading can be better
handled via objects and methods than with opcodes. Indeed,
what I'm currently planning for PCT is more along the lines of:
## grab the generic "Parrot" HLLCompiler
$P0 = compreg 'Parrot'
## tell Parrot to load a language 'foo' and return its compiler
$P1 = $P0.'load_language'('foo')
## tell Foo's compiler to load its library
$P2 = $P1.'load_library'('mylib')
As far as dynpmcs and dynops go, I think the loading of those
should probably be tied more directly to the HLL namespace
than to try to set them via load_language. For example, given:
.HLL 'perl6'
.loadlib 'perl6_group'
the fact that the .loadlib is taking place from the 'perl6' HLL
namespace is what causes it to look for the dynpmcs/dynops in
languages/foo. Indeed, as I write this I think it's likely
that loadlib and .include should generally use the current
HLL namespace as one of the components of the search path.
Pm
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
