4 ms·

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 n

• theOnliest 13y ago
  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.
• chubot 13y ago
  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.
  • kanatohodets 13y ago
    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.
    • rurban 13y ago
      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.
• groovy2shoes 13y ago
  It's the name of a general project in the Perl community to try to decouple Perl 5 the language from perl the runtime... This is literally impossible: http://www.perlmonks.org/?node_id=663393 http://www.perlmonks.org/?node_id=663393
  • chromatic 13y ago
    Every few months this comes up: http://www.modernperlbooks.com/mt/2009/08/on-parsing-perl-5.html http://www.modernperlbooks.com/mt/2009/08/on-parsing-perl-5....
    • groovy2shoes 13y ago
      I posted the link mostly in jest. 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.
      • rurban 13y ago
        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. The author