In fact, that is one of the requirements for Perl 6 that I started neglecting some time ago. As I explain in the README file, I still can't see how the interoperability between different languages will work without a typemapping layer. This typemapping layer will be something very similar to what XS is today, except that in a higher-level language.
This means that the usual way for language interoperability in YAP6 will be the same as p5. But it doesn't mean, however, that yap6 won't be able to handle grammars. YAP6 is a port to C of the concepts created and tested by KP6. And it's in the plans the use of YAP6 as a backend to KP6, which means that it should support anything KP6 does, which includes the KP6 grammar engine.
In summary, I don't expect high-level languages like Perl 6 and Perl 5 interoperating in the high level directly, I do expect each code to be running in each interpreter interfaced by a typemapping layer. But this doesn't means that Perl 6 based sub-languages and DSLs (domain specific languages) won't be able to run inside yap6 (as long as no typemapping is needed).
| [reply] |
You're still missing the point. Perl6 isn't a language - it's a grammar engine. Which means that it will be parsing N languages to the same parse trees to be interpreted on the same VM. Without a typemapping layer. There are no Perl6-based sublanguages. Everything you can express in the grammar engine that runs Perl6 will be a Perl6 language. Even the default language.
My criteria for good software:
- Does it work?
- Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
| [reply] |
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.
| [reply] |
It's interesting to me that there seems to be this "holy trinity" of major Perl 6 features (that may even interest different parties):
- The new language syntax (I'm looking forward to this)
- The buttons and knobs that will allow you to remake the language into whatever you want it to be (language connoiseurs, or others looking to guide the evolution of Perl 6)
- having a generic vm that can run multiple languages (I think this may include being able to access libraries written in language A from your program written in language B) (would be nice for many, if it were possible, but Perl 5 seems to have done fine without this ability).
Is Perl 6 only "Perl 6" if you get all three of those?
| [reply] |
Will YAP6 be able to handle that?
Nothing precludes it, technically speaking. However, it is the source of a fair bit of complexity within Parrot and PGE, and I think a lot of that complexity is necessary to the problem.
| [reply] |
As I said in the reply to dragonchild, YAP6 should inherit the grammar engine from KP6, and this way, support all this features.
| [reply] |