4 ms·

>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 it

>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.

shakna 9y ago
> 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.
nokcha 9y ago
> 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.
- swift 9y ago
  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.

shakna 9y ago

> 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.

nokcha 9y ago

> 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.

swift 9y ago
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.