« JavaScript as the new object code. | Main | Perl 6 Summary: 2006-02-13 through 2006-02-28 »

2006.07.07

Comments

Feed You can follow this conversation by subscribing to the comment feed for this post.

I'd like to emphasize that I'm willing and ready to help with whatever needs to make the P5 core ready for use as the basis of this stack. P5P waits for your desires and contributions!

Is Pugs::Compiler and Pugs::Runtime pure perl?

I'm confused because I thought those involved some haskell, and you have them in this diagram above the XS layer -- which means that they are actually pure perl...

Ian: As CPAN modules, they are now pure perl; what we are doing is synchronizing Haskell-side modules with Perl5-side modules, make them implement a common API and a common Perl 6 AST, so you can switch between two "Pugs" runtimes and get the same semantics.

So indeed, you do not need GHC installed to use any of it.

Audrey: so as I know it means: Pugs now have more than one backends (runtimes). The planned was Parrot, the first was Haskell and now, as I know, there are Parrot, Haskell, JavaScript and Perl 5. But that's all my knowledge - what are the state of these backends? Are they fast? Which is the best in speed, in knowledge? As I see, it would be a great idea to create a matrix about speed and knowledge for the non-lambda-camels :). As I just read your blog and sometimes looking around, I have no information about these questions, and I think somebody++ should clarify it.

What are the main obstacles remaining in Parrot to have it supported as a first class Perl6 back end as is Haskell? Would Neko be a better target for Perl6?

Confused: It needs a sane exception handling mechanism, distinction between container and value objects, a method dispatch system that allows inspection over the dispatch chain, a multi dispatch system that works with preferential resolution instead of Manhattan resolution, reflection API for the class system, to name a few.

It'll eventually get there (and I'm doing what I can to help), but currently the churn is still very, very high...

Requiring the VM to have working exceptions and support reflection is understandable, but why burden the VM with dispatch chain inspection and multi-dispatch? Perl5 lacks these features, after all, and they must be emulated at the library level with appropriate data structures. Where do you draw the line as to what functionality is in the compiler/generated code/supporting library and the VM? Shouldn't the VM requirements be as modest as possible so that Perl6 can be easily retargetted?

Confused: Yes, but the thing is the multi dispatcher, although it's possible to be written out in pure Perl6, would still require dispatch chain inspection to work in any efficient manner.

In the simplest case it's just a "super;" call, which is present in Ruby/Python but _not_ Perl5 (though we emulate it there in Moose). However, even that call is missing in Parrot. :)

The comments to this entry are closed.

June 2014

Sun Mon Tue Wed Thu Fri Sat
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30          

Audrey

My Photo

License