Hi Henrik apologize my "d" in your name below.
Am 10.07.2016 um 11:28 schrieb C Maeder: > 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 > _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
