Beefy Boxes and Bandwidth Generously Provided by pair Networks
more useful options

Re: Perl Cannot Be Parsed: A Formal Proof

by sundialsvc4 (Abbot)
on Jan 21, 2008 at 21:30 UTC ( #663435=note: print w/replies, xml ) Need Help??

in reply to Perl Cannot Be Parsed: A Formal Proof

More to the point here... what should be done about your findings? Perl-5 obviously is “in production,” thousands of times over, and so cannot be changed. The only thing that can be influenced is therefore Perl-6 ... if that.

We have had “unresolvable ambiguities” over the years in a great many languages that have nonetheless proved to be practically successful.

Ergo... what?

  • Comment on Re: Perl Cannot Be Parsed: A Formal Proof

Replies are listed 'Best First'.
Re^2: Perl Cannot Be Parsed: A Formal Proof
by Jeffrey Kegler (Hermit) on Jan 21, 2008 at 22:48 UTC
    In the sense I think you might mean, nothing should be done. I use Perl 5, I like Perl 5. I don't see a need to regard static unparsability as a problem and "solve" it. Larry apparently is going to static parsability in Perl 6. I don't have a firm opinion about whether that is bad or good. I do think that it's proved wise in the past to listen to Larry in these matters.

    The reason for a proof is there had been considerable question about whether Perl 5 was statically unparsable just for practical purposes, or just given present parsing techniques. Adam Kennedy's PPI man page says that the module name Parse::Perl had been reserved in case someone invented a way to statically parse Perl. Opinion shifted to the point where the most people felt certain that no static parser for Perl existed. But I think it's nice to get the issue completely nailed down.

    Lack of static parsability is an obstacle for many utilities that deal with Perl 5 code. That's definitely a downside. But it's not the whole equation, and the ability to do Turing-equivalent fiddling at BEGIN time is an upside.

      Larry apparently is going to static parsability in Perl 6.
      You seem to be missing a "not" in that sentence.

      The last time I brought this up with Larry, which was admittedly a year ago, he wasn't going to budge on either of the dual-nature of "/" or the ability to prototype a subroutine to influence the number of parameters.

      Indeed, part of the difficulty in having implemented Perl 6 so far is not being able to have a clean lexical phase, thanks to this wonderful "perfect storm" of desirable features. You must execute Perl code at compile time, even in Perl 6, in order to even tokenize the remainder of the file.

      The only concession I heard from him is that the results of that executed code would not be promised to be carried forward into the result of the compilation, which seems a bit odd, as it would break things like:

      my $x; BEGIN { $x = time }
      Unless the BEGIN block is executed both at compile time and once at pre-run time.

      Of course, I might be a few months out of date. I got bored following all the Perl 6 stuff, so I'm working on Smalltalk for a while until Perl6 gets a bit closer to a release.

        Larry apparently is going to static parsability in Perl 6.

        You seem to be missing a "not" in that sentence.

        I personally believe a verb is missing as well, BTW.

        If you can't understand the incipit, then please check the IPB Campaign.
      Actually Perl 6 is even harder to (statically) parse than Perl 5, because it is much easier to change the syntax.

      You can, for example, introduce new operators very easily:

      multi sub prefix:<foo> (Str $a) { return $a eq "foo" ?? "bar" !! "foo"; }

      This will define an unary prefix operator that takes one string as an argument. When somebody writes

      foo "foo";

      You can't know if that's a method call or a call to an operator. You'd think it makes no difference - but wait until precedence comes into the play:

      BEGIN { eval " multi * prefix:<foo> (Str $a) is tighter(&infix:<~>) { return $a eq 'foo' ?? 'bar' !! 'foo'; "; } # and later in the code: foo "fo" ~ "o";

      If that foo parsed as a sub call the precedence is lower than that of the concatenation ~, and the other way round if it's parsed as an operator.

      This is quite a complicated example, but there are much easier ones with "real" macros. (But since no implemenation really implements macros by now, I don't really know much about them).

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://663435]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others taking refuge in the Monastery: (3)
As of 2021-05-09 02:50 GMT
Find Nodes?
    Voting Booth?
    Perl 7 will be out ...

    Results (100 votes). Check out past polls.