On Saturday, July 9, 2016, Henrik Nilsson <henrik.nils...@nottingham.ac.uk> wrote:
> 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. > > Well said, I think this articulates exactly what I'm reacting to. Thanks for taking the time to articulate this. I agree. > 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 > > -- > Henrik Nilsson > School of Computer Science > The University of Nottingham > n...@cs.nott.ac.uk > > > > > This message and any attachment are intended solely for the addressee > and may contain confidential information. If you have received this > message in error, please send it back to me, and immediately delete it. > Please do not use, copy or disclose the information contained in this > message or in any attachment. Any views or opinions expressed by the > author of this email do not necessarily reflect the views of the > University of Nottingham. > > This message has been checked for viruses but the contents of an > attachment may still contain software viruses which could damage your > computer system, you are advised to perform your own checks. Email > communications with the University of Nottingham may be monitored as > permitted by UK legislation. > > _______________________________________________ > 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
