Beefy Boxes and Bandwidth Generously Provided by pair Networks
Come for the quick hacks, stay for the epiphanies.
 
PerlMonks  

comment on

( [id://3333] : superdoc . print w/replies, xml ) Need Help??
For lisp, the BNF is small enough not to worry about that

Well, yeah, lisp barely even *has* syntax. That's the opposite end of the spectrum.

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.

Yes, in principle. Perl can be parsed, obviously, because perl does parse it, QED. But the question is, what is required to make that happen? Perl has both left-associative and right-associative operators, for instance (although Perl5 is less whole-hog in this regard than Perl6 will be). Perhaps the larger issue, though, is that there are various things that can change the rules for how to parse other things, and they don't all come right before the thing whose interpretation they change. Just for one little example, consider the /x modifier, which changes the interpretation of whitespace and number signs that occur in the middle of the regex, before it. For a Turing-complete parser, this is not a problem, because you just scan ahead and see what's coming. I'm not a BNF guru, but if it has a concept of lookahead, I'm not aware of it.

Another problem is that the way BNF likes to handle things is to lump cases together and treat them as the same, but this presents serious problems when parsing Perl code, especially as regards the various quoting constructs, *especially* the quoting constructs related to pattern matching, because of the number of special cases. In the example above, a typical BNF approach would be to lump the allowed regular expression modifiers together (by defining a rule that can match any of them and then using that rule at given points in various larger rules), but as the example above illustrates, you can't do that, because a regular expression modifier can change the rules for parsing the regular expression that precedes it. It also can change the interpretation of what is parsed; /s and /m do that. BNF is not troubled by that wrinkle, since it is not concerned as much with semantics as it is with syntax -- but that is BNF's whole problem when it comes to Perl, because the syntax and the semantics are not fully separable: the parser needs (some) knowledge of the semantics in order to sort out the syntax.


"In adjectives, with the addition of inflectional endings, a changeable long vowel (Qamets or Tsere) in an open, propretonic syllable will reduce to Vocal Shewa. This type of change occurs when the open, pretonic syllable of the masculine singular adjective becomes propretonic with the addition of inflectional endings."  — Pratico & Van Pelt, BBHG, p68

In reply to Re: Perl not BNF-able?? by jonadab
in thread Perl not BNF-able?? by anonymized user 468275

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post; it's "PerlMonks-approved HTML":



  • Are you posting in the right place? Check out Where do I post X? to know for sure.
  • Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
    <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>
  • Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
  • Want more info? How to link or How to display code and escape characters are good places to start.