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." _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
