Judging by the ample supply of version number rimshots, some clarification might be helpful: this isn't a Perl release, nor is it a new Perl version. It's the name of a general project in the Perl community to try to decouple Perl 5 the language from perl the runtime, and hopefully achieve interoperability between Perl 5 and Perl 6 code in the process. Perl 5 and 6 are distinct languages in the same family, much like (for example) Common Lisp vs Racket Scheme, which is why interop is an interesting and worthwhile goal.
There are some really cool things happening in the specific projects on the linked page, if you're into compilers and VMs.
It would be nice if it actually said this on the page. I had to poke around for several minutes to figure out what this project actually was, and I'm a Perl person myself.
I'm not sure I get the motivation. Isn't Perl a Unix-y language? You can get "interop" by using pipes or other IPC.
This seems like a heavy, Java-esque solution. 50 lines of Perl does a lot, let alone 1000. Not sure I want to see 20,000 lines of mixed Perl 5 and Perl 6.
Well, the goal is to make sure that the plentiful modules on the CPAN (all in Perl 5) are usable for everybody involved. You're right, directly mixing Perl 5 and Perl 6 isn't likely to be a common usage - at least, doesn't seem that way to me.
The p2 goal is to use as much non-conflicting p6 syntax within p5, and mark conflicting parts in special lexically scoped syntax blocks.
But data and methods should be shared, the ast, compiler, vm, threads and event model ditto.
Syntax blocks also allow easier ffi and sql interaction,
{ use syntax "C"; c declarations ... } being a nice FFI language,
compared to "extern { c decls; ... }", which is also nice.
We want to use efficient signatures, methods, classes, tasks, coros, promises,
hyper operators, types, lazy lists and so in perl, regardless if you call it p5,
p6 or p2.
That being said, I still contend that a Perl 5 parser is still inextricably separable from the runtime. Any parser that wants to be fully compatible with Perl 5 will need to be able to also run Perl 5 code. That is, the parser will need to be coupled with the runtime.
A consequence of the parser needing to be able to execute arbitrary code is that the parser is undecidable. This follows from the halting problem, which is the point of the article I posted and is also pointed out in the one you posted.
As a sidenote, I find the distinction between "static" and "dynamic" parsing to be rather silly. The only people I've ever heard make that distinction are Perl apologetics. No need to be so defensive: parsing is allowed to be ambiguous, and it is allowed to be undecidable -- but it's not considered ideal.
Dynamic and static parsing is different to just calling eval within the parser.
"Dynamic parsing problems" such as solving the halting problem, by e.g. changing the prototypes or eval'ing code in BEGIN blocks are just small practical problems. In practice the parser only has to be GC-safe, which needs a few days work.
| BEGIN b:block { p2_eval(P, b) }
On the other hand the "dynamic vs static parsing" on perl11.org talks about compiling and extending parser rules at run-time, which needs a fast vm to do this. To be able to support macros.
Not perl5, perl6 or nqp. Efficiency should be near the C level, but you shouldn't be forced to go the rakudo way with its insane bootstrapping and serialization overhead just to support BEGIN blocks in its stdlib and support run-time parsing.
The JVM or .NET could do that, but I don't buy the overhead, esp. when you look at fast parser combinators in lua, lisp or look at maru, which is basically a jitting parser, bootstrapping itself.
Of the two types of macros I'm familiar with, neither demands a "dynamic" parser. C-style macros (conceptually) work as a text pre-processor prior to the compiler's lexing phase. Lisp-style macros work on the syntax tree after the parse phase has finished.
In some Lisps, such as Common Lisp, macros are simply functions from syntax tree to syntax tree. Since these execute at compile time, you can still run into the same types of problems you get with Perl's BEGIN. Scheme's syntax-rules macros are more limited: they cannot execute arbitrary code, but they can do pattern matching and substitution on syntax trees. Despite this limitation, syntax-rules covers the vast majority of macro use cases. The term rewriting systems in Haskell and Cat are reasonably similar.
My point to all of this is that macros are no justification for "dynamic" parsing. The only distinction I can find of the two kinds of parsing is that a "dynamic" parser sometimes needs to execute bits of the program before it is able to progress. This is not necessary for macros!
As far as parser combinators go, I conjecture that they will not be powerful enough to deal completely with Perl's grammar. In general, they're limited to LL(k) grammars. Still, you may be able to jump through some hoops to get what you want out of them.
Cool, I look forward to the next version (17) and the one after that too (28). This is the first Fibonacci version number scheme I've seen, maybe in the spirit of how TeX keeps adding digits of pi.
Not really a Fibonacci
version number system since v(n + 1) = v(n) + n + 5, v(-1) = 0. It doesn't depend on v(n - 1), so while it's a recurrence relation it isn't a Fibonacci-type sequence.
The next version should be 5 + 6 + 7 = 18, not 17.
Ah, I see. Unfortunately, this seems to imply that after the present version the project will stop incorporating new mainline releases of Perl (Perl 7 and on) and will instead focus on recombining the previous releases of itself.
I think Perl 6, especially Rakudo is aiming for a production release couple of years from now.
Having said that it would be pointless to go simply rewrite existing Perl 5 code to Perl 6. A good deal of Perl 5 libraries will be ported to Perl 6. And then Perl 6 will be well suited for a lot of big projects.
Perl 6 has a very nice type system, packed with all the goodies of a enterprise object oriented language,it has powerful functional programming features, and with all that it stays true to its scripting roots.
The right way to look at it is, Perl 5 and 6 will co exist for much of their individual lifetimes.
Anyone else in Perl 5 land, having tried Perl 6, just not that interested?
Seems like a lot of trendy changes that weren't needed to the language. There are some great changes (especially in the OO realm), but also a lot of weak ones.
Its like a trade off. While OO interests you a lot, there are a good deal of people who like functional stuff. Some people like both(See scala popularity these days). Some people want all of that with strong scripting support.
The design of Perl 6 is to ensure you can incrementally evolve the language to be whatever the trends are at that time.
Oh, I like the functional stuff too, but the regex changes and grammars and some of the operator overloading - I feel like I'm getting to a point with the functionality where Perl's syntax will start to get in the way, which is not the point of the language.
What happens in other parts of the code doesn't have the same impact on your code it does in Perl 5, though. In Perl 5 it's very easy to globally change the behaviour of code, while in Perl 6 it's a lot since harder since almost everything is lexically scoped.
Well a lot of the normal stuff is still normal. But that's no fun to show off, so instead lots of Perl6 examples are full of edge cases. When I translated small examples from Perl5 to Perl6 I found them to be pretty similar, though with more obvious OO and cleaning some of the array/hashref sigils visuals.
Do I understand correctly, the point here being to allow perl5 and perl6 code to interoperate? The page is bit low on details how this will affect endusers.
It's a list of projects all loosely oriented around untying Perl 5 the language from perl the runtime. Perl 6 has already done this, with several (Parrot, JVM, Mono/.NET) VMs currently working fairly successfully, if a tad slowly still.
Personally I'm most excited about perlito (which features perl 5 compiled to javascript, among other things) and p2, which promises to be a super-speedy rendition of Perl 5 based on why the lucky stiff's last public project, the Potion language/VM.
The idea, as I understand it, is that if both Perl 5 and Perl 6 are running on the same VM, they can share library code on the level of that VM's bytecode.
All of that said, perl the runtime remains actively maintained and improved. End Perl users are just going to have some choices, much as Ruby users have had for a while (JRuby vs MRI, for example).
What modules? Your idea is probably the wrong way to approach the problem. You could look at execnet if you just need to run hopelessly old unmaintained stuff that you can't push to get ported.
Google Protocol Buffers. I want to use those for exporting scene information from Blender.
Blender uses Python 3 for scripting and the protobuf code generator and libraries only support Python 2.x. The same for Apache Thrift. Both are very well maintained, they are just not planning to move to Py3 any time soon.
There are mountains of Python 2.x code (particularly inside companies) that are well-maintained and have no plans to port to Python 3 at the moment. My approach has generally been to make the code compatible across 2 and 3, though it requires great vigilance.
Yeah this is the approach I try to take, too. Is there a good write up on the intersection of 2 and 3? I mean more than "Here's some things to look out for when you are writing for both." I mean more along the lines of the Python standard documentation, but excluding all of the incompatibilities.
This is sort of the opposite of what you asked for: it's the list of all "fixers" that the 2to3 program will attempt to automatically fix when converting from 2 to 3. http://docs.python.org/2/library/2to3.html#to3-fixers If you avoid any issues not on the list, you'll have a higher chance of 2to3 being successful.
It's analogous to Python 2/3 except Perl 6 has lacked the progress to allow Perl to live in a two branch world.
It kinda sucks from a PR standpoint since Perl 5 has been under active development the entire time and had been importing a lot of the good ideas from Perl 6.
The parent post meant: “The Perl5 language can never increment its major version to 6, as the Perl6 name is already taken” – which is silly, as Perl5 is currently at version 18.
And 2 as the next perl, because it should solve the p5 problem, being not extendable and improvable.
And the p6 vm problem being not fast enough, and being tied to inadequate vm's and mops.
I did get all that, I was just commenting on the crazy numbering scheme. It's just as silly as the third XBox being called the XBox One.
Even though it's a perl project and not perl itself, making it sound like version numbers can only serve to confuse things further, when Perl is already suffering problems from version numbers.
Yes, the crazy numbering numbering scheme is an inside joke.
First we had the endless perl7 discussion just skipping over 6 and show some artifical progress in 5.
Next came the moe folks (p5-mop in a new vm) who registered perl8.org as domain pointing to scala.
Then came Ingy with the 5+6=11 idea.
There are some really cool things happening in the specific projects on the linked page, if you're into compilers and VMs.