Q: Is there a compiler/language/magic registry?

[Stephen Weeks]

On Wed, 2009-07-01 at 11:19 -0400, Austin Hastings wrote:
> Should there be one? Tene's foreign-code-loader assumes that the 
> developer knows the language of origin for each foreign module:
> 
>   use Foo::Bar:from<Tcl>;
> 
> But that's a non-starter in the long term, since knowing the language of 
> implementation totally violates encapsulation.

I'm only indirectly addressing your main point, but I'm pretty sure I
disagree with this.  The language of implementation is just part of the
name of the library, and the language implementation is just a
dependency of the library.  If you want that to be encapsulated, write a
native library named the same and have it try loading whichever other
versions you'd like to try, like Perl 5's YAML::Any on CPAN.  I expect
you'll often want to do that anyway, to provide language-native idioms
that aren't present in the other language.

Restating, as far as I'm able to see (admittedly, I have far too little
experience with this), the only solution that makes any sense at all is
to just ask the foreign compiler to load the library for you and give it
to you.  Other solutions get into N×M complexity, exclude languages with
slightly different paradigms, require languages to bend too much to
Parrot's way of doing things, etc.

You can't have a central repository, afaict, because different existing
languages already store their libraries in different places, and
requiring the Parrot version to store them in a parrot-specific location
will greatly cripple the Parrot version.  Having languages add to the
search path introduces the problems of requiring you to explicitly load
all languages you want to have considered (and what if some module you
use adds an additional language?), as well as search path ordering, and
what if multiple languages register the same file extension?

Also, you discuss encapsulation.  Are you going to dictate that all
libraries must have identical APIs in all languages?  What about
existing identically-named libraries in different languages?  What about
differences between languages?  Are you going to say that no libraries
in any language can use named parameters in exported functions, because
some languages can't use named parameters?  It's an impossible mess to
work out, as far as I can tell.  I would really love someone else to
help work out these issues, though.

Again, I'll restate my position that the language a library was
implemented from *really* should count as part of the name of the
library.  Functions in that language will return objects of types from
that language, will use the calling conventions of that language, etc.
(Unless you want to get into the horrible mess of trying to map core
classes from one language to another automatically... which I really
really think you don't.  I'm willing to be persuaded, but I'm pretty
sure it's not the right thing at all for Parrot to be trying to do in
general.)

I really don't mean this as an attack.  If you can work out solutions to
these problems (and others), I'd love to implement them.  My main answer
to your initial question is "Nobody so far can think of any good way to
do what you're asking for, and it looks like it invites far more
problems than it would solve, but we're open to being convinced."