Proposal: ArgumentDo

[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
>