Proposal: ArgumentDo

[C Maeder]

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 at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>