in reply to Perl not BNF-able??

Some parts of the Perl grammar are inherently ambiguous, and the lexer resolves them by using dodgy look-ahead heuristics (which don't always work), eg indirect object syntax: 
print $f +$g
print $f+$g

[download]
is that writing the positive value $g to the filehandle $f, or printing ($f+$g) to STDOUT? 

sub newhashref {  { a => 1, b => 3 } }
sub innerblock {  { local $a => 1; ... } print "old a=$a" }

[download]
is an opening brace the start of a block or the start of an anonymous hash generator?

Dave.

Replies are listed 'Best First'.
Re^2: Perl not BNF-able??
by anonymized user 468275 (Curate) on Jul 01, 2005 at 09:52 UTC
    True, but although such ambiguities become apparent to the programmer, they do not stop us from expressing whichever of the choices perl actually makes in BNF.

    One world, one people

[reply]
      BNF is by definition for context free grammars. Perl's grammar is not context free.
[reply]
      such ambiguities ... do not stop us from expressing whichever of the choices perl actually makes in BNF.

      Yeah? Try it.

      The problem is that in order to resolve the ambiguity (i.e., in order to select the choice perl actually makes, as you put it) you have to have access to information about the surrounding context, information that gets lost when reducing the surrounding syntax to BNF. 

         s ;; split / , / ;; s ,$, ; , ; print eval;

      [download]

      Don't make me turn this into a self-modifying quine.

      Incidentally, a lot of Lisp or Scheme programmers recoil in horror when they find out that Perl's grammar is not context-free. "If it's not possible to determine what a given syntactic construct means independent of context, how could anyone ever keep track of what a piece of a program is doing?" Well, that's the problem BNF has. In practice, this is not generally a problem for programmers who know the language, but it gives overly simple parsers fits.

[reply]
[d/l]
        The problem with 'Try it' is that it's an all or nothing proposition. For lisp, the BNF is small enough not to worry about that. I can see that you can't wrap up a piece of non-context-free syntax in isolation. However, what I expected was that it might be possible to describe different syntax-elements for each type of contextual variation.

        I had a bad feeling about eval from the start, but I will still need to see where the process breaks down when worked through from first principles before I understand exactly what will go wrong (assuming the context-free issue is insurmountable, that is).

        One world, one people

[reply]

In Section Seekers of Perl Wisdom