Hi Hendrik, juxtaposition (of grammar non-terminals aexp) is function application in Haskell. Why does an explicit infix operator make such a big difference for you? (if c then f else g) $ if d then a else b (if c then f else g) if d then a else b The keyword "if" starts a new expression. Nobody would wrongly parse this as "(...(if c then f else g) if)...)", because also nobody parses "... then a else b" wrongly as "... ((then a) else) b)". Actually, I see less rather than more non-terminals (no lexp) in the grammar and no additional ambiguity. Cheers Christian Am 09.07.2016 um 11:46 schrieb Henrik Nilsson:
Hi all,
On 07/09/2016 08:09 AM, C Maeder wrote:
The asymmetry that you mention is already apparent for (Haskell98) infix expressions, i.e. when "composing" lambda- or if-expression:
(if c then f else g) . \ x -> h x
Parentheses around the last argument of "." do not matter, but parentheses around the first argument make a real difference
But that has to do with how grammatical ambiguity related to in this case "if" and "lambda" are resolved by letting the constructs extend as far as possible to the right.
This the standard way of resolving that kind of ambiguity across a very wide range of programming languages and parsing tools (e.g. preferring shift over reduce in an LR parser). (And also in principle how lexical ambiguities are typically resolved, sometimes referred to as the "maximal munch rule".)
In contrast, the present proposal suggests treating different argument positions in grammatically different ways (different non-terminals). As far as I know, that is unprecedented. And in any case, it manifestly complicates the grammar (more non-terminals) and as a consequence adds another grammatical hurdle to learning the language.
I think we often tend to forget just how exotic Haskell syntax can be to the uninitiated. Which is the vast majority of the rest of the programmer world as well as beginners. Only the other week I gave a presentation to a group of highly skilled developers at a tech-savvy London-based company. The emphasis of the talk was not at all on Haskell as such, but small Haskell fragments did feature here and there, which I (naively) thought would be mostly self explanatory. Well, let's just say I was wrong.
Now, we can't make Haskell syntax less exotic (not that I'd advocate that: I think basic Haskell syntax for the most part strikes a pretty good balance on a number of counts), but we can certainly avoid making it even more complicated and exotic. Which the present proposal would, in my opinion.
Best,
/Henrik