Re: re. 1.3 cleanup: patterns in list comprehensions
Parsing Haskell list comprehensions deterministically ((LA)LR) is currently very hard, since both "pat - exp" (or also "pat gd - exp", as suggested by Thomas) and "exp" are allowed as qualifiers in a list comprehension. Patterns and expressions can look very much alike. Could one possibly expand "exp" to "if exp" in Haskell 1.3 list comprehensions? Only to make deterministic parsing easier... I once had the same problem when writing a Miranda-ish compiler. The simple solution is to use "exp" instead of "pat" in the parsing grammar (in qualifiers), and when it later (e.g. encountering - ) becomes clear that the beast has got to be a pattern, you check it semantically. This works, because patterns are syntactically a subclass of expressions. One should not make the parsing method too much influence the language design, PASCAL is a bad example for this. Stefan Kahrs
Re: re. 1.3 cleanup: patterns in list comprehensions
Stefan Kahrs writes: [About Miranda] This works, because patterns are syntactically a subclass of expressions. But this is not true for Haskell (@ and _ are only in patterns), but the technique still works. You just have to work harder and join pat and exp and then always have a semantic check. But since it's very easy to parse with a backtracking parser I really don't care much. I don't think LR concerns should govern language design. -- Lennart
Re: re. 1.3 cleanup: patterns in list comprehensions
Patterns and expressions can look very much alike. Could one possibly expand "exp" to "if exp" in Haskell 1.3 list comprehensions? Only to make deterministic parsing easier... One should not make the parsing method too much influence the language design, PASCAL is a bad example for this. True. I once had the same problem when writing a Miranda-ish compiler. The simple solution is to use "exp" instead of "pat" in the parsing grammar (in qualifiers), and when it later (e.g. encountering - ) becomes clear that the beast has got to be a pattern, you check it semantically. This works, because patterns are syntactically a subclass of expressions. False. Patterns (in Haskell) also have "_", "~", and "@" which are not allowed in expressions. Using exp instead of pat (and adding "_", "~", and "@" to expressions) is a hack, not a proper solution. I don't like hacks. So, I either have to massage the grammar into deterministic LR parsable form (difficult) or use a nondeterministic LR parser (not readily available). This extra effort in parser hacking is a small, one-time effort, compared to the really hard stuff in the compiler! True. I'm not going to insist on a change. /kent k
