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.
| [reply] [Watch: Dir/Any] |
BNF is by definition for context free grammars. Perl's grammar is not context free.
| [reply] [Watch: Dir/Any] |
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;
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] [Watch: Dir/Any] [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).
| [reply] [Watch: Dir/Any] |