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 > _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
