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

[Timothy S. Nelson]

 	I'm completely unqualified to comment, but I'll throw some ideas 
around anyway.

On Wed, 1 Jul 2009, Stephen Weeks wrote:

> 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.

 	I know you've seen pmichaud's message by now, but let me quote it:

: Currently this is what Rakudo does -- it has a :load sub that
: loads the Rakudo runtime environment into the interpreter if not
: already present.

 	If everyone were to do it this way, that would solve at least part of 
the problem; then the only problem would be getting the library into the path 
:).  I know Larry Wall said somewhere that, for Perl 6, he wants to have the 
path-interpreting code be more intelligent, so that shorter paths could be 
specified.  For example, my PERLLIB currently says:

..../usr/lib/perl5/site_perl/5.005:/usr/lib/perl5/site_perl/5.005/i386-linux/

 	Larry's idea is that we'd just be able to say:

PERLLIB=/usr/lib/perl6

 	...and the Perl 6 specification would say how to go about finding the 
appropriate library from there.

 	I know that Parrot isn't Perl 6, but I'm wondering if the general idea 
can't be used.  If the code for each library was marked somehow (maybe by 
putting it in a subdirectory) that said what language it was, then the 
library-finding code could know the language from this marking.

> 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.

 	Am I correct in guessing that this is answered somewhat above?

> 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.

 	Softlinks/Windows Shortcuts?

> 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?

 	Different paths for different implementations.  eg. Rakudo would use 
the Rakudo search path, which would put all Rakudo stuff ahead of anything in 
other implementations, but fall back on other things (eg. Cardinal).  If your 
Perl 6 program calls a Ruby library, and the Ruby program calls a library 
called "IO" which exists with different APIs for both Perl 6 and Ruby, then 
the Perl 6 program would find the Ruby library only after searching through 
the Rakudo ones, but the Ruby code would find the Ruby IO library because it 
would search the Cardinal path before the Rakudo path.

 	I'd happily agree that file extension is a bad way to figure out the 
language something is in.

> 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?

 	I hope these are covered by the multiple paths idea I mentioned above.

> 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?

 	I don't know the answer to that, but I think it's solveable, although 
possibly at a standard + implementation level rather than a parrot code level.

> 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.

 	That one that I didn't know the answer to, I could throw some ideas 
around, but mostly I'd just be displaying my ignorance.  If this is the only 
problem standing in the way, though, I'd be happy to throw the ideas.

> 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.)

 	Hmm.  Can I suggest that, unless we can figure out a better idea, that 
the way to do it might be to have a "Parrot Interlanguage Communication 
Standard", which defines how these things work together?  Possibly it could 
even be optional; I'm unsure whether that's the best way to go, and will leave 
that question to others :).

> 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."

 	Hmm.  Well, the problems I didn't solve were:
-	Calling conventions (named parameters, etc)
-	Data types auto-conversion

 	I think these are solveable, but as above, I don't think I have the 
requisite knowledge of Parrot to be able to suggest sensible solutions other 
than the Parrot Interlanguage Communication Standard that I suggested above.

 	HTH,


---------------------------------------------------------------------
| Name: Tim Nelson                 | Because the Creator is,        |
| E-mail: wayland at wayland.id.au    | I am                           |
---------------------------------------------------------------------

----BEGIN GEEK CODE BLOCK----
Version 3.12
GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- 
PE(+) Y+>++ PGP->+++ R(+) !tv b++ DI++++ D G+ e++>++++ h! y-
-----END GEEK CODE BLOCK-----