|XP is just a number|
Re^4: YAP6: A p5 approach to p6by ruoso (Curate)
|on Dec 25, 2007 at 22:15 UTC ( #658985=note: print w/replies, xml )||Need Help??|
The point about the language interoperability is that you have no use for a Java library that doesn't use the Java API. This is actually one of the points I tried to stress during YAPC::EU::2007. The fact is, you will still have to map the Java object system to the Perl 6 object system. And that makes a language, not only the fact that Perl 6 can compile other grammars into its own Abstract Syntax Tree.
You can have all of them mapped to the same low-level type system (using PMCs in parrot's case), but this won't avoid the fact that, in java, for instance, a low level array is a completely and unmappable thing to all the Lists and Collections that are present in the java core api. The point is that you have no way to interoperate between java and perl without doing a typemapping between the java api and the Perl type and object system.
The thing is that we don't actually need it to be done enterely in the high level. We can use extension mechanisms like XS to do the trick, and it will work just fine. Of course that I can compile C code to the Perl 6 object system, but, does it make sense? Wouldn't I want to use the C code as a binary optimized object instead? Of course I can compile the entire Java API to the Perl 6 object system, but, why would I want that, considering that I can benefit from the Java optimizations that were enabled because of its limitations?
This, on the other hand, is a completely different story than language modifications, or even to have some libraries that can actually interoperate. Perl 6 is built on top of the grammar engine, and I'm not denying that, on the contrary, what I'm talking about is about working on top of what KP6 does, which, in fact, includes a grammar engine in itself, an engine that had already successfully bootstrapped the grammar already (even if the bootstrap doesn't work right now).
But this is to replace what we use today as source filters, it is to enable the creation of another languages, or even the embed of foreign code syntax. But that doesn't mean the code from the other language will be available for free. You can implement a java compiler to parrot, but you won't be able to use it naturally. You will need a typemapping layer for using the swing toolkit from a Perl program. On the other hand, nothing stops you from writing a compiler in a way that you can integrate some java code, considering this java code is written for your environment. I mean, the fact that Perl 6 can change its own compiler behaviour doesn't change the way the other languages work. Let's take the Java::Import module, it brings the Java objects to the Perl space, but this doesn't change the fact that you need to create a java.lang.String object when you want to pass a string to a method of some of this classes. (a typemapping would avoid that)
As a summary, when I talk "sub-languages" and "DSLs", I include a compiler for an already existing language, but that means that this existing language will *not* be the original language when running in your environment. It may implement the same syntax, and that's all. And, yes, KP6 already supports that, you could compile other languages to KP6 so-called "object system" and the code would be able to interoperate, but it would never be the original language.
In Section Meditations