Will Coleda wrote:
At the moment I'm planning for language pbcs to go into
.../parrot/library/ so they can be easily accessed via
load_bytecode. I've found that in a dynamic environment like
Parrot there's very little difference between a language and
a library [1]. :-)
That's probably the best, but we can also think of not installing that at all,
and only install executables. But then the new pddxx_language_interop.pod
at http://nopaste.snit.ch/13890 will have problems. exe cannot loaded
from other languages, only pbc's.
Right. We have to (eventually) install the pbcs, no matter if we also
install the exes for convenience.
Yes. And the exes (or aliases to the parrot exe) should go in the same
bin directory as parrot.
So each language will need its root namespace reserved for it's <lang>.pbc.
While it would help, there's no guarantee that namespace in PBC
matches path on filesystem.
The fundamental principle is that language implementations are like CPAN
modules. You can install them as a separate package, and they add
functionality. Just like a CPAN module, there's a default search path
where the module name matches the filesystem path, possibly with some
prefix path, and with the HLL namespace treated as part of the full name
of the module (/usr/lib/parrot/lang/python/my/module.pbc or whatever).
There also need be ways to change the default path when compiling
Parrot, and to change the searched paths at runtime.
We could thing of symlinking it to runtime/parrot/library
at make languages, so language_interop can be tested.
Are symlinks usable wherever we might install?
No. And not necessary as long as search paths are configurable, which
they have to be anyway.
I had always thought that the compiler/compreg opcode would eventually
be extended to load the library we needed for language interop; If
not, I'm not sure there's much point in keeping the ability to
register compilers, is there? If someone wants to use the tcl
compiler, they need to know to load the bytecode first anyway.
That's backwards. Loading the language module is what registers the
compiler. The user never needs to access the compiler object for a
particular language directly unless they're compiling code from a string.
Allison
