Q: Is there a compiler/language/magic registry?
Timothy S. Nelson
wayland at wayland.id.au
Fri Jul 3 05:16:56 UTC 2009
I'm completely unqualified to comment, but I'll throw some ideas
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:
Larry's idea is that we'd just be able to say:
...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.
> 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
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
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.
| Name: Tim Nelson | Because the Creator is, |
| E-mail: wayland at wayland.id.au | I am |
----BEGIN GEEK CODE BLOCK----
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-----
More information about the parrot-dev