Proposal: ArgumentDo

Carter Schonwald carter.schonwald at gmail.com
Sat Jul 9 12:45:21 UTC 2016


On Saturday, July 9, 2016, Henrik Nilsson <Henrik.Nilsson at 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
> nhn at 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 at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20160709/dacdb04a/attachment.html>


More information about the Glasgow-haskell-users mailing list