Hacker News Reader

Comment by gizmo686 | Hacker News Reader

>Most parsing frameworks make it difficult for you to tell the user simple things like misspelled variables, something does exist, but it isn't in-scope when its being called, and basically helpful messages like that.

I agree that generated parsers make error reporting difficult, but do not think these examples are relevent. If the problem is a misspelled or out of scope identifier, the parser should should still be able to parse the program, which would be syntactically valid.

View on HN

> If the problem is a misspelled or out of scope identifier, the parser should should still be able to parse the program

That's not necessarily true for all languages. For example, in C, "(e1)&e2" is parsed differently depending on how e1 is declared. If e1 is declared as

    typedef int* e1;

then the "&" in "(e1)&e2" is parsed as the address-of operator, but if e1 is declared as

    int e1;

then "(e1)&e2" is parsed as a bitwise AND.

This is a problem for a lot of languages, unfortunately, and it breaks the clean separation between syntax and semantics that we're hoping for when we write a formal grammar.

I've had some success in the past with using GLR or another algorithm that can handle ambiguity, and then choosing among the possible parse trees in another pass that takes semantic information into account. How applicable that is really depends on the language, though; if things are so ambiguous that you're getting an exponential growth in possible parse trees, you may not want to use this approach.

> which would be syntactically valid.

Not necessarily.

Usually, we're used to seeing something like:

    print("Something")

But there are statement based languages where instead you have:

    print "Something"

Still simple enough to parse.

However, what about user function calls?

    something 1 2
    3 4

If a newline doesn't break a call, and you don't depend on indenting, but actually the arity of the original function definition, accidentally writing:

    someting 1, 2
    3 4

Can be impossible to parse correctly, especially if said language also supports first-class functions.

    func apply with func:caller array:values
      do
        ...code...
      done

    aply + list
      do
        10 10 10 10
      done

The syntax in the above example is still correct, but because the arity of 'aply' can't be determined, the parser can't actually continue.

The grammar might be a little insane, but I've had to work with similar grammars in several financial languages. And the parser does poop out, and when it does, you really want a nice error to result.

Reply on news.ycombinator.com