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: [email protected] | 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-----
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
