Re: Proposal: ArgumentDo

[C Maeder]

Hi Sven,

a wrongly spelled keyword will soon be detected by the checker in either
cases.

Readability is the responsibility of programmers. It is up to you or a
team to use parentheses for the examples below. (I find a line break and
indentation to be sufficient.)

(I know people - mostly beginners - that insist on using "if b then True
else False" instead of "b" for readability reasons.)

Surely, a grammar could enforce more redundancy, but this is usually
considered as an annoyance (in particular for instance distant closing
tags that are more or less hidden in a pile of other closing tags).

The $-notation was (in the first place) only used (and maybe misused) to
avoid additional parentheses.

Haskell's strong typing is the major safeguard (against spelling errors).

Cheers Christian

Am 11.07.2016 um 08:31 schrieb Sven Panne:
> 2016-07-10 11:28 GMT+02:00 C Maeder  >:
> 
> [...] 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
> [...]
> 
> 
> Because at first glance, this is visually only a tiny fraction away from
>  
>(if c then f else g)  it d them a elsa b
> 
> which would be parsed in a totally different way. (Personally, I think
> that if/then/else is useless in Haskell and just a concession for
> readers from other programming languages. Having a plain old "if"
> function would have done the job in a more consistent way.) Of course
> syntax highlighting improves readability here, but code should be easily
> digestible in black and white, too. Visual clues matter...
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Proposal: ArgumentDo

[Joachim Breitner]

Hi,

Am Montag, den 11.07.2016, 08:31 +0200 schrieb Sven Panne:
> Because at first glance, this is visually only a tiny fraction away
> from
>  
>    (if c then f else g)  it d them a elsa b
> 
> which would be parsed in a totally different way. (Personally, I
> think that if/then/else is useless in Haskell and just a concession
> for readers from other programming languages. Having a plain old "if"
> function would have done the job in a more consistent way.) Of course
> syntax highlighting improves readability here, but code should be
> easily digestible in black and white, too. Visual clues matter...

I believe we can and should expect programmers to know the keywords
(there are not many of them) and should _not_ compromise other goals
for “makes similar sense even if a keyword is mistake or mistyped as a
symbol name”.


Greetings,
Joachim

-- 

Joachim “nomeata” Breitner
  m...@joachim-breitner.de • https://www.joachim-breitner.de/
  XMPP: nome...@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F
  Debian Developer: nome...@debian.org

signature.asc
Description: This is a digitally signed message part
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Proposal: ArgumentDo

[Sven Panne]

2016-07-10 11:28 GMT+02:00 C Maeder :

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

Because at first glance, this is visually only a tiny fraction away from

   (if c then f else g)  it d them a elsa b

which would be parsed in a totally different way. (Personally, I think that
if/then/else is useless in Haskell and just a concession for readers from
other programming languages. Having a plain old "if" function would have
done the job in a more consistent way.) Of course syntax highlighting
improves readability here, but code should be easily digestible in black
and white, too. Visual clues matter...
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Proposal: ArgumentDo

[Ryan Trinkle]

Akio,

Yes, definitely!  I think I was a bit unclear, but what I was trying to say
was that, in the (rare) circumstances in which I'm editing Haskell without
the benefit of syntax highlighting, the difference between keywords and
identifiers is not quite as obvious.  In those cases, requiring an operator
may make things easier to read.

This is a very small point, but I appreciate you taking the time to respond!


Ryan

On Sun, Jul 10, 2016 at 9:53 PM, Akio Takano  wrote:

> Hi Ryan,
>
> On 7 July 2016 at 19:40, Ryan Trinkle  wrote:
> > I'm very on the fence on this topic, but one point i haven't seen
> mentioned
> > is the influence of syntax highlighting on this.  My guess is that I
> would
> > like this extension when I have syntax highlighting available and would
> > dislike it when I do not.
>
> vim and hscolour can highlight code with the new syntax just fine. I
> imagine that most existing syntax highlighter will be able to deal
> with the new syntax without needing to be updated, because they
> usually don't attempt to fully parse expressions: they mostly just
> pattern-match on tokens.
>
> - Akio
>
> >
> > Also, I agree with Carter about the record update syntax - I find it
> harder
> > to parse visually than most other parts of the language, and I expect I'd
> > find curly brace syntax for inline 'do' harder to parse in a similar way.
> > On the other hand, maybe I should get used to both...
> >
> > On Thu, Jul 7, 2016 at 2:50 PM, Joachim Breitner <
> m...@joachim-breitner.de>
> > wrote:
> >>
> >> Hi,
> >>
> >> Am Donnerstag, den 07.07.2016, 13:15 -0400 schrieb Carter Schonwald:
> >> > agreed -1,
> >> > ambiguity is bad for humans, not just parsers.
> >> >
> >> > perhaps most damningly,
> >> > > f do{ x } do { y }
> >> >
> >> > is just reallly really weird/confusing to me,
> >>
> >> It is weird to me, but in no way confusing under the simple new rules,
> >> and I am actually looking forward to using that, and also to reading
> >> code with that.
> >>
> >> In fact, everything I wanted to pass two arguments in do-notation to a
> >> function I felt at a loss. The prospect of itemizing multiple large
> >> arguments to a function by writing
> >>
> >> someFunctionWithManyArguments
> >>   do firstArgument
> >>   do second Argument which may span
> >>several lines
> >>   do third Argument
> >>
> >> is actually making me happy! It feels like going from XML to YAML...
> >>
> >> Greetings,
> >> Joachim
> >>
> >> --
> >>
> >> Joachim “nomeata” Breitner
> >>   m...@joachim-breitner.de • https://www.joachim-breitner.de/
> >>   XMPP: nome...@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F
> >>   Debian Developer: nome...@debian.org
> >> ___
> >> 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
> >
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Proposal: ArgumentDo

[Akio Takano]

Hi Henrik,

On 9 July 2016 at 09:46, Henrik Nilsson  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.

Thank you for pointing this out. I have updated the proposal so that
it doesn't introduce a new non-terminal.

I'm not sure if it should be implemented this way in the GHC parser,
but this is probably a separate question.

- Akio
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Proposal: ArgumentDo

[Akio Takano]

Hi Ryan,

On 7 July 2016 at 19:40, Ryan Trinkle  wrote:
> I'm very on the fence on this topic, but one point i haven't seen mentioned
> is the influence of syntax highlighting on this.  My guess is that I would
> like this extension when I have syntax highlighting available and would
> dislike it when I do not.

vim and hscolour can highlight code with the new syntax just fine. I
imagine that most existing syntax highlighter will be able to deal
with the new syntax without needing to be updated, because they
usually don't attempt to fully parse expressions: they mostly just
pattern-match on tokens.

- Akio

>
> Also, I agree with Carter about the record update syntax - I find it harder
> to parse visually than most other parts of the language, and I expect I'd
> find curly brace syntax for inline 'do' harder to parse in a similar way.
> On the other hand, maybe I should get used to both...
>
> On Thu, Jul 7, 2016 at 2:50 PM, Joachim Breitner 
> wrote:
>>
>> Hi,
>>
>> Am Donnerstag, den 07.07.2016, 13:15 -0400 schrieb Carter Schonwald:
>> > agreed -1,
>> > ambiguity is bad for humans, not just parsers.
>> >
>> > perhaps most damningly,
>> > > f do{ x } do { y }
>> >
>> > is just reallly really weird/confusing to me,
>>
>> It is weird to me, but in no way confusing under the simple new rules,
>> and I am actually looking forward to using that, and also to reading
>> code with that.
>>
>> In fact, everything I wanted to pass two arguments in do-notation to a
>> function I felt at a loss. The prospect of itemizing multiple large
>> arguments to a function by writing
>>
>> someFunctionWithManyArguments
>>   do firstArgument
>>   do second Argument which may span
>>several lines
>>   do third Argument
>>
>> is actually making me happy! It feels like going from XML to YAML...
>>
>> Greetings,
>> Joachim
>>
>> --
>>
>> Joachim “nomeata” Breitner
>>   m...@joachim-breitner.de • https://www.joachim-breitner.de/
>>   XMPP: nome...@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F
>>   Debian Developer: nome...@debian.org
>> ___
>> 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
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Proposal: ArgumentDo

[Akio Takano]

Hi Christian,

On 6 July 2016 at 16:08, C Maeder  wrote:
> Hi,
>
> allowing group A constructs (do, case, ...) and group B constructs (\,
> let, if, ...) as parts of functions application (fexp) without extra
> parentheses looks natural to me. The current state is an artificial and
> unnecessary restriction. Style guides may dictate restrictions, but the
> parser/language should not (without good reasons).
>
> So +1 for the proposal from me.
>
> However, I would not distinguish group A and group B constructs in the
> proposed grammar rules. The report already states (for the group B
> constructs):
> "The grammar is ambiguous regarding the extent of lambda abstractions,
> let expressions, and conditionals. The ambiguity is resolved by the
> meta-rule that each of these constructs extends as far to the right as
> possible."

This is a good point, I have updated the wiki page and simplified the
grammar change.

Thank you,
Akio
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: 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@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

Re: 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
> 

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Proposal: ArgumentDo

[Carter Schonwald]

On Saturday, July 9, 2016, Henrik Nilsson 
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

Re: Proposal: ArgumentDo

[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

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

Re: Proposal: ArgumentDo

[Bardur Arantsson]

On 07/09/2016 09: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 (that the
> type checker will not detect)!
> 

What I'm reading here is essentially

  "Parser already does non-obvious thing"
  ===> "Adding more non-obvious things is fine!"

This is simply bad reasoning, and I'm not sure why a number of people
are saying it. Am I missing something?

Regards,

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Proposal: ArgumentDo

[C Maeder]

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 (that the
type checker will not detect)!

Cheers Christian

Am 08.07.2016 um 14:00 schrieb Henrik Nilsson:
> Hi all,

[...]

> As a final point, the inherent asymmetry of the proposal (the
> last argument position is special as, for certain kinds of
> expressions, parentheses may be omitted there but not elsewhere)
> is also deeply unsettling.
> 
> Best,
> 
> /Henrik
> 

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Proposal: ArgumentDo

[Iavor Diatchki]

Hello,

while  we are voting here, I kind of like this proposal, so +1 for me.

I understand that some of the examples look strange to Haskell old-timers
but, as Joachim points out, the behavior is very consistent.   Besides, the
"Less Obvious Examples" were selected so that they are, well, less obvious.
  The common use cases (as in ticket #10843) seem quite appealing, at least
to me, and not at all confusing.  But, then, I also like the
records-with-no-parens notation :-)

-Iavor



On Fri, Jul 8, 2016 at 5:03 AM, Aloïs Cochard 
wrote:

> -1 for same reasons.
>
> On 8 July 2016 at 14:00, Henrik Nilsson 
> wrote:
>
>> Hi all,
>>
>> Joachim Breitner wrote:
>>
>> > Am Freitag, den 08.07.2016, 13:09 +0200 schrieb Sven Panne:
>> > > I don't think so: https://ghc.haskell.org/trac/ghc
>> > /wiki/ArgumentDo#Bl
>> > [...]
>> > Where is the outer set of parenthesis coming from?
>> >
>> > This is all not related to the ArgumentDo notation. Note that [...]
>>
>> The very fact that that experts can't easily agree on how a small
>> Haskell fragment is parsed to me just confirms that Haskell already
>> is a syntactically very cumbersome language.
>>
>> The present proposal just makes matters worse. For that reason
>> alone, I don't find it compelling at all. (So -1 from me, then.)
>>
>> I will not repeat the many other strong arguments against that has been
>> made. But I must say I don't find the use cases as documented
>> on the associated web page compelling at all. Maybe there is a tacit
>> desire to be able to pretend functions are keywords for various
>> creative uses in supporting EDSLs and such. But for that to be truly
>> useful, one need to support groups of related keywords. Something
>> like Agda's mixfix syntax springs to mind. But this proposal does
>> not come close, so the benefits are minimal and the drawbacks large.
>>
>> As a final point, the inherent asymmetry of the proposal (the
>> last argument position is special as, for certain kinds of
>> expressions, parentheses may be omitted there but not elsewhere)
>> is also deeply unsettling.
>>
>> 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
>>
>
>
>
> --
> *Λ\oïs*
> http://twitter.com/aloiscochard
> http://github.com/aloiscochard
>
> ___
> 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

layout was Re: Proposal: ArgumentDo

[C Maeder]

Hi,

the layout language options are hard to find (at least in the user
guide). Therefore I try to give an overview here. The relevant options
I've found by using ghc-7.10.3 with option --supported-languages are:

NondecreasingIndentation
DoAndIfThenElse

RelaxedLayout
AlternativeLayoutRule
AlternativeLayoutRuleTransitional

I ignore the last 3 options since these seem to be candidates for
removal: https://ghc.haskell.org/trac/ghc/ticket/11359.

The default option is NondecreasingIndentation, that is

  do
  x
  do
  y

is legal and parsed as a single expression "do {x ; do y}". With
-XNoNondecreasingIndentation one gets an "Empty 'do' block" for the
second do (and this error would not change with ArgumentDo!).

DoAndIfThenElse is not switched on by default and requires the keywords
"then" and "else" to be further indented for an "if" within a "do".

So I believe these options do not interfere with ArgumentDo, but maybe
this should be discussed more and maybe mentioned on the wiki page.

Surely a single space (inserted before x or removed before the second
"do") makes a difference between one or two argument expressions in the
example below.

HTH Christian

Am 08.07.2016 um 11:20 schrieb C Maeder:
> Surely layout can bite you:
> 
>   f
>   do
>   x
>   do
>   y
> 
> and I'm having difficulties to find the documentation for the various
> layout options.
> 
> But this is no argument against this proposal!
> 
> Improper use of white spaces can always be used to obfuscate code!
> Style guides are important. Furthermore, a wrong/unintended parse tree
> (due to layout) will - in many cases - result in a typing error.
> 
> Christian

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Proposal: ArgumentDo

[Aloïs Cochard]

-1 for same reasons.

On 8 July 2016 at 14:00, Henrik Nilsson 
wrote:

> Hi all,
>
> Joachim Breitner wrote:
>
> > Am Freitag, den 08.07.2016, 13:09 +0200 schrieb Sven Panne:
> > > I don't think so: https://ghc.haskell.org/trac/ghc
> > /wiki/ArgumentDo#Bl
> > [...]
> > Where is the outer set of parenthesis coming from?
> >
> > This is all not related to the ArgumentDo notation. Note that [...]
>
> The very fact that that experts can't easily agree on how a small
> Haskell fragment is parsed to me just confirms that Haskell already
> is a syntactically very cumbersome language.
>
> The present proposal just makes matters worse. For that reason
> alone, I don't find it compelling at all. (So -1 from me, then.)
>
> I will not repeat the many other strong arguments against that has been
> made. But I must say I don't find the use cases as documented
> on the associated web page compelling at all. Maybe there is a tacit
> desire to be able to pretend functions are keywords for various
> creative uses in supporting EDSLs and such. But for that to be truly
> useful, one need to support groups of related keywords. Something
> like Agda's mixfix syntax springs to mind. But this proposal does
> not come close, so the benefits are minimal and the drawbacks large.
>
> As a final point, the inherent asymmetry of the proposal (the
> last argument position is special as, for certain kinds of
> expressions, parentheses may be omitted there but not elsewhere)
> is also deeply unsettling.
>
> 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
>



-- 
*Λ\oïs*
http://twitter.com/aloiscochard
http://github.com/aloiscochard
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Proposal: ArgumentDo

[Henrik Nilsson]

Hi all,

Joachim Breitner wrote:

> Am Freitag, den 08.07.2016, 13:09 +0200 schrieb Sven Panne:
> > I don't think so: https://ghc.haskell.org/trac/ghc
> /wiki/ArgumentDo#Bl
> [...]
> Where is the outer set of parenthesis coming from?
>
> This is all not related to the ArgumentDo notation. Note that [...]

The very fact that that experts can't easily agree on how a small
Haskell fragment is parsed to me just confirms that Haskell already
is a syntactically very cumbersome language.

The present proposal just makes matters worse. For that reason
alone, I don't find it compelling at all. (So -1 from me, then.)

I will not repeat the many other strong arguments against that has been
made. But I must say I don't find the use cases as documented
on the associated web page compelling at all. Maybe there is a tacit
desire to be able to pretend functions are keywords for various
creative uses in supporting EDSLs and such. But for that to be truly
useful, one need to support groups of related keywords. Something
like Agda's mixfix syntax springs to mind. But this proposal does
not come close, so the benefits are minimal and the drawbacks large.

As a final point, the inherent asymmetry of the proposal (the
last argument position is special as, for certain kinds of
expressions, parentheses may be omitted there but not elsewhere)
is also deeply unsettling.

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

Re: Proposal: ArgumentDo

[Joachim Breitner]

Hi,

Am Freitag, den 08.07.2016, 13:09 +0200 schrieb Sven Panne:
> I don't think so: https://ghc.haskell.org/trac/ghc/wiki/ArgumentDo#Bl
> ockasaLHS explicit states that
> 
>    do f &&& g
>    x
> 
> parses as
> 
>    (f &&& g) x

Correct

> , so
> 
>    foobar
>       do f &&& g
>       x
> 
> parses as
> 
>    foobar ((f &&& g) x)

Where is the outer set of parenthesis coming from?

This is all not related to the ArgumentDo notation. Note that

(f &&& g)
x

parses as

   (f &&& g) x

and still

   foobar
     (f &&& g)
     x

parses as

foobar (f &&& g) x

just as

   foobar
   (f &&& g)
   x

does.

(NB: I consider
  foobar
  arg1
  arg2
bad style and prefer
  foobar
      arg1
      arg2
but the former is allowed now and will be allowed later as well.)


Greetings,
Joachim

-- 

Joachim “nomeata” Breitner
  m...@joachim-breitner.de • https://www.joachim-breitner.de/
  XMPP: nome...@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F
  Debian Developer: nome...@debian.org

signature.asc
Description: This is a digitally signed message part
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Proposal: ArgumentDo

[Sven Panne]

2016-07-08 12:28 GMT+02:00 Joachim Breitner :

> Currenlty,
>
> foobar
>   (do f &&& g)
>   x
>
> calls foobar with two arguments, while
>
> (do f &&& g)
> x
>
> calls (f &&& g) with one argument. The ArgumentDo proposal does not change
> that, only that the parenthesis become redundant.
>

I don't think so:
https://ghc.haskell.org/trac/ghc/wiki/ArgumentDo#BlockasaLHS explicit
states that

   do f &&& g
   x

parses as

   (f &&& g) x

, so

   foobar
  do f &&& g
  x

parses as

   foobar ((f &&& g) x)

under the new proposal, which I find highly confusing. If it doesn't parse
like this under the proposal, the wiki page is wrong and/or the proposal is
not compositional: Why should being below "foobar" change the parse?
"foobar" is not a keyword switching to some different mode.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Proposal: ArgumentDo

[Joachim Breitner]

Hi,

Am Freitag, den 08.07.2016, 11:32 +0200 schrieb Sven Panne:
> 2016-07-08 9:09 GMT+02:00 Joachim Breitner :
> > Am Freitag, den 08.07.2016, 08:35 +0200 schrieb Sven Panne:
> > >    foobar
> > >       do f &&& g
> > >       x
> > [...] Only with the proposed addition, it becomes an argument to foobar. 
> > [...]
> 
> Huh?  Nope! The Wiki page explicitly says that
> 
>    do f &&& g
>    x
> 
> means
> 
>    (f &&& g) x
> 
> Why should this be different here? Simply writing "foobar" above that
> construct won't trigger any special layout rules, I hope...

I believe this follows from the existing layout rules.

Currenlty,

foobar
  (do f &&& g)
  x

calls foobar with two arguments, while
  
(do f &&& g)
x

calls (f &&& g) with one argument. The ArgumentDo proposal does not change 
that, only that the parenthesis become redundant.

Greetings,
Joachim

-- 
-- 

Joachim “nomeata” Breitner
  m...@joachim-breitner.de • https://www.joachim-breitner.de/
  XMPP: nome...@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F
  Debian Developer: nome...@debian.org

signature.asc
Description: This is a digitally signed message part
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Proposal: ArgumentDo

[Sven Panne]

2016-07-08 9:09 GMT+02:00 Joachim Breitner :

> Am Freitag, den 08.07.2016, 08:35 +0200 schrieb Sven Panne:
> >foobar
> >   do f &&& g
> >   x
> [...] Only with the proposed addition, it becomes an argument to foobar.
> [...]
>

Huh?  Nope! The Wiki page explicitly says that

   do f &&& g
   x

means

   (f &&& g) x

Why should this be different here? Simply writing "foobar" above that
construct won't trigger any special layout rules, I hope...
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Proposal: ArgumentDo

[C Maeder]

Surely layout can bite you:

  f
  do
  x
  do
  y

and I'm having difficulties to find the documentation for the various
layout options.

But this is no argument against this proposal!

Improper use of white spaces can always be used to obfuscate code!
Style guides are important. Furthermore, a wrong/unintended parse tree
(due to layout) will - in many cases - result in a typing error.

Christian

Am 08.07.2016 um 09:09 schrieb Joachim Breitner:
> Hi,
> 
> Am Freitag, den 08.07.2016, 08:35 +0200 schrieb Sven Panne:
>>foobar
>>   do f &&& g
>>   x
>>
>> Should the x now be an argument of foobar (as it is currently) or the
>> "do"? If it is not an argument of the "do", suddenly things get very
>> context-dependent. Computers are good at handling context-dependent
>> things, humans are quite bad at it.
> 
> What do you mean by “as it is currently”. Currently, this is a syntax
> error! (“parse error on input ‘do’”).
> 
> Only with the proposed addition, it becomes an argument to foobar.
> 
> And it is not hard to reason about this: "x" is lined up with the "do",
> so it is a sibling, not a child, in the AST. Hence, both are arguments
> to foobar.
> 
> This is another good instance of how the (by me) beloved feature of
> “parenthesless arguments”, which so far is only available for the last
> argument of a function (using the “$” idiom), would now be possible for
> every argument of a function.
> 
> Greetings,
> Joachim
> 
> 
> 
> ___
> 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

Re: Proposal: ArgumentDo

[Joachim Breitner]

Hi,

Am Freitag, den 08.07.2016, 08:35 +0200 schrieb Sven Panne:
>    foobar
>       do f &&& g
>       x
> 
> Should the x now be an argument of foobar (as it is currently) or the
> "do"? If it is not an argument of the "do", suddenly things get very
> context-dependent. Computers are good at handling context-dependent
> things, humans are quite bad at it.

What do you mean by “as it is currently”. Currently, this is a syntax
error! (“parse error on input ‘do’”).

Only with the proposed addition, it becomes an argument to foobar.

And it is not hard to reason about this: "x" is lined up with the "do",
so it is a sibling, not a child, in the AST. Hence, both are arguments
to foobar.

This is another good instance of how the (by me) beloved feature of
“parenthesless arguments”, which so far is only available for the last
argument of a function (using the “$” idiom), would now be possible for
every argument of a function.

Greetings,
Joachim

-- 

Joachim “nomeata” Breitner
  m...@joachim-breitner.de • https://www.joachim-breitner.de/
  XMPP: nome...@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F
  Debian Developer: nome...@debian.org

signature.asc
Description: This is a digitally signed message part
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Proposal: ArgumentDo

[Sven Panne]

[ There is a trend to repeat one's argument about this proposed extension
in various mailing lists/wiki pages/etc., so let's repeat myself, too... :-]

2016-07-07 19:44 GMT+02:00 Carter Schonwald :

> the fact that its perilously close to looking like *1 typo* away from a
> parser error about record syntax makes me
> *-1000* now [...]
>

-1000 for exactly the same reason, and more: If you look at the "Block as a
LHS" section on the wiki, things get insame IMHO:

   do f &&& g
   x

should mean "(f &&& g) x"? It's probably 99% more likely that somebody
didn't get the indentation right for the "do". And what about:

   foobar
  do f &&& g
  x

Should the x now be an argument of foobar (as it is currently) or the "do"?
If it is not an argument of the "do", suddenly things get very
context-dependent. Computers are good at handling context-dependent things,
humans are quite bad at it.

Taking one step back: I think a lot of the discussion is based on the false
assumption that "something can be parsed in an unambiguous way by some more
or less random parsing technology" means "it can easily be parsed by a
human". This is a fundamental misconception, otherwise reading programs in
Brainfuck or Whitespace would be easy, too. In our case at hand, visually
determining what is an argument of a function in a quick way is *supported*
by some (perhaps) redundant syntactic stuff. That's exactly the reason why
the current record syntax is a big mistake: Normally, an argument is
beginning after a whitespace (unless there are other syntactic clues like
'$', '(', etc.), but

   foo bar { baz = blah }

runs against this intuition and one has to mentally backtrack. The proposal
at hand would enshrine this kind of broken syntax in more places. As has
already been said in another thread, the goal of language design is not to
make writing correct programs easier (by allowing more and more syntax),
but to make writing wrong programs harder.

And a note about counting votes: I think normal democrating voting
procedures simply don't apply here. Even if e.g. 80% of the voters find
something OK while the other 20% find it confusing, the majority vote
doesn't make the confusion of a fifth of the people go away. For a change
like this, I would expect near unanimous consent, but I think we are very,
very far away from that...
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Proposal: ArgumentDo

[Carter Schonwald]

Can you walk me through how this simplifies the grammar etc in concrete
compare contrast or what the diffs between the grammar and associated
engineering would be?

I don't see how it simplifies the grammar, but I could be a bit obtuse.

That aside, I'm also a bit fuzzy on the other claim, that this change will
simplify post parsing engineering,
On Jul 7, 2016 4:47 PM, "Jon Purdy"  wrote:

> > ambiguity is bad for humans, not just parsers.
>
> This is not ambiguous. It’s removing the need for a redundant set of
> parentheses, whichever way you slice it. Of course, some redundancy is
> useful for readability (look at natural language), but you should
> really be explicit if you’re arguing from that position.
>
> > perhaps most damningly,
> >>
> >>
> >> f do{ x } do { y }
> >
> >
> > is just reallly really weird/confusing to me
>
> By “weird”, do you mean anything other than “I don’t understand it,
> and I blame it”? Can you give an example of how you might misparse it,
> as a human reader?
>
> >> It's harder to read than the alternative.
> >>
> >> Creating a language extension to get rid of a single character is
> overkill
> >> and unnecessary.
>
> It’s only a language extension for backward compatibility. It’s really
> fixing a bug in the grammar.
>
> > I'm all in favor of doing engineering work to *improve*
> > our parser error messages and suggestions, but not stuff that complicates
> > parsing for humans  as well as machines
>
> This would be a simplification of the parser if the bug hadn’t been
> standardised originally.
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Proposal: ArgumentDo

[Jon Purdy]

> ambiguity is bad for humans, not just parsers.

This is not ambiguous. It’s removing the need for a redundant set of
parentheses, whichever way you slice it. Of course, some redundancy is
useful for readability (look at natural language), but you should
really be explicit if you’re arguing from that position.

> perhaps most damningly,
>>
>>
>> f do{ x } do { y }
>
>
> is just reallly really weird/confusing to me

By “weird”, do you mean anything other than “I don’t understand it,
and I blame it”? Can you give an example of how you might misparse it,
as a human reader?

>> It's harder to read than the alternative.
>>
>> Creating a language extension to get rid of a single character is overkill
>> and unnecessary.

It’s only a language extension for backward compatibility. It’s really
fixing a bug in the grammar.

> I'm all in favor of doing engineering work to *improve*
> our parser error messages and suggestions, but not stuff that complicates
> parsing for humans  as well as machines

This would be a simplification of the parser if the bug hadn’t been
standardised originally.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Proposal: ArgumentDo

[Ryan Trinkle]

I'm very on the fence on this topic, but one point i haven't seen mentioned
is the influence of syntax highlighting on this.  My guess is that I would
like this extension when I have syntax highlighting available and would
dislike it when I do not.

Also, I agree with Carter about the record update syntax - I find it harder
to parse visually than most other parts of the language, and I expect I'd
find curly brace syntax for inline 'do' harder to parse in a similar way.
On the other hand, maybe I should get used to both...

On Thu, Jul 7, 2016 at 2:50 PM, Joachim Breitner 
wrote:

> Hi,
>
> Am Donnerstag, den 07.07.2016, 13:15 -0400 schrieb Carter Schonwald:
> > agreed -1,
> > ambiguity is bad for humans, not just parsers.
> >
> > perhaps most damningly,
> > > f do{ x } do { y }
> >
> > is just reallly really weird/confusing to me,
>
> It is weird to me, but in no way confusing under the simple new rules,
> and I am actually looking forward to using that, and also to reading
> code with that.
>
> In fact, everything I wanted to pass two arguments in do-notation to a
> function I felt at a loss. The prospect of itemizing multiple large
> arguments to a function by writing
>
> someFunctionWithManyArguments
>   do firstArgument
>   do second Argument which may span
>several lines
>   do third Argument
>
> is actually making me happy! It feels like going from XML to YAML...
>
> Greetings,
> Joachim
>
> --
>
> Joachim “nomeata” Breitner
>   m...@joachim-breitner.de • https://www.joachim-breitner.de/
>   XMPP: nome...@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F
>   Debian Developer: nome...@debian.org
> ___
> 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

Re: Proposal: ArgumentDo

[Joachim Breitner]

Hi,

Am Donnerstag, den 07.07.2016, 13:15 -0400 schrieb Carter Schonwald:
> agreed -1,
> ambiguity is bad for humans, not just parsers. 
> 
> perhaps most damningly, 
> > f do{ x } do { y }
> 
> is just reallly really weird/confusing to me,

It is weird to me, but in no way confusing under the simple new rules,
and I am actually looking forward to using that, and also to reading
code with that.

In fact, everything I wanted to pass two arguments in do-notation to a
function I felt at a loss. The prospect of itemizing multiple large
arguments to a function by writing

someFunctionWithManyArguments
  do firstArgument
  do second Argument which may span
       several lines
  do third Argument

is actually making me happy! It feels like going from XML to YAML...

Greetings,
Joachim

-- 

Joachim “nomeata” Breitner
  m...@joachim-breitner.de • https://www.joachim-breitner.de/
  XMPP: nome...@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F
  Debian Developer: nome...@debian.org

signature.asc
Description: This is a digitally signed message part
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Proposal: ArgumentDo

[Carter Schonwald]

the fact that its perilously close to looking like *1 typo* away from a
parser error about record syntax makes me
*-1000* now

thanks for pointing this out!

On Thu, Jul 7, 2016 at 1:32 PM, Brandon Allbery  wrote:

> Didn't they already say they disliked record syntax for exactly that
> reason?
>
> On Thu, Jul 7, 2016 at 1:23 PM, David Feuer  wrote:
>
>> What makes
>>
>> f do{x} do{y}
>>
>> any harder to read than similar record syntax?
>>
>> f Foo{foo=3} Foo{foo=4}
>>
>> On Thu, Jul 7, 2016 at 1:15 PM, Carter Schonwald
>>  wrote:
>> > agreed -1,
>> > ambiguity is bad for humans, not just parsers.
>> >
>> > perhaps most damningly,
>> >>
>> >>
>> >> f do{ x } do { y }
>> >
>> >
>> > is just reallly really weird/confusing to me, and as the proposal itself
>> > says at the end as the cons:
>> >
>> >
>> >> It's harder to read than the alternative.
>> >>
>> >> Creating a language extension to get rid of a single character is
>> overkill
>> >> and unnecessary.
>> >>
>> >> You can already get rid of the $ by just adding parentheses.
>> >
>> > which kinda kills any benefit in my mind. thats a HUGE complexity vs
>> > alternative ratio. I'm all in favor of doing engineering work to
>> *improve*
>> > our parser error messages and suggestions, but not stuff that
>> complicates
>> > parsing for humans  as well as machines
>> >
>> >
>> > On Wed, Jul 6, 2016 at 9:50 PM, Evan Laforge  wrote:
>> >>
>> >> On Wed, Jul 6, 2016 at 10:39 AM, Bardur Arantsson <
>> s...@scientician.net>
>> >> wrote:
>> >> > On 07/04/2016 12:31 PM, Akio Takano wrote:
>> >> >> Hi glasgow-haskell-users,
>> >> >>
>> >> >> I have written a wiki page about a proposed extension called
>> >> >> ArgumentDo. It's a small syntactic extension that allows "do"
>> >> >> expressions, lambdas and a few other kinds of expressions to be used
>> >> >> as function arguments, without parentheses.
>> >> >>
>> >> >> https://ghc.haskell.org/trac/ghc/wiki/ArgumentDo
>> >> >>
>> >> >> Any feedback is appreciated. In particular, since the idea has
>> >> >> received mixed support (see the "Discussion" section on the wiki
>> >> >> page), I'd like to make sure that there is enough support for this
>> >> >> feature to justify an implementation in GHC.
>> >> >>
>> >> >
>> >> > -1
>> >> >
>> >> > Reasons have already been given in previous threads on this. However,
>> >> > I'd point especially to the fact that people don't *agree* that this
>> is
>> >> > more readable as a very strong point against -- regardless of whether
>> >> > any one individual thinks it's more readable or not. The point is the
>> >> > there seems to be a lot of disagreement -- that indicates to me that
>> >> > this cannot by definition be a "clear win"[1]. Disclosure: I
>> personally
>> >> > find it less readable because of the implicitness. Implicitness which
>> >> > has a non-trivial probability of affecting semantics is bad in my
>> book.
>> >> > Frankly, if it came to it, I'd rather just remove $ and deal with the
>> >> > parentheses.
>> >>
>> >> I'm -1 because I think there are already too many styles.  So I don't
>> >> agree with the general sentiment that the parser should accept lots of
>> >> stuff and to rely on style guides to specify something, because in
>> >> practice everyone has their own style guide.
>> >>
>> >> I trained myself to see juxtaposition as highest precedence (which
>> >> newcomers still struggle over) and it's confusing to see juxtaposition
>> >> that has higher precedence because one of them is a keyword.  In the
>> >> same way I'm confused by 'f a { b = c }', but it's too late to change
>> >> that one.  I suppose this is already on the wiki page in the "cons"
>> >> section.
>> >> ___
>> >> 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
>> >
>> ___
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>>
>
>
>
> --
> brandon s allbery kf8nh   sine nomine
> associates
> allber...@gmail.com
> ballb...@sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Proposal: ArgumentDo

[Brandon Allbery]

Didn't they already say they disliked record syntax for exactly that reason?

On Thu, Jul 7, 2016 at 1:23 PM, David Feuer  wrote:

> What makes
>
> f do{x} do{y}
>
> any harder to read than similar record syntax?
>
> f Foo{foo=3} Foo{foo=4}
>
> On Thu, Jul 7, 2016 at 1:15 PM, Carter Schonwald
>  wrote:
> > agreed -1,
> > ambiguity is bad for humans, not just parsers.
> >
> > perhaps most damningly,
> >>
> >>
> >> f do{ x } do { y }
> >
> >
> > is just reallly really weird/confusing to me, and as the proposal itself
> > says at the end as the cons:
> >
> >
> >> It's harder to read than the alternative.
> >>
> >> Creating a language extension to get rid of a single character is
> overkill
> >> and unnecessary.
> >>
> >> You can already get rid of the $ by just adding parentheses.
> >
> > which kinda kills any benefit in my mind. thats a HUGE complexity vs
> > alternative ratio. I'm all in favor of doing engineering work to
> *improve*
> > our parser error messages and suggestions, but not stuff that complicates
> > parsing for humans  as well as machines
> >
> >
> > On Wed, Jul 6, 2016 at 9:50 PM, Evan Laforge  wrote:
> >>
> >> On Wed, Jul 6, 2016 at 10:39 AM, Bardur Arantsson  >
> >> wrote:
> >> > On 07/04/2016 12:31 PM, Akio Takano wrote:
> >> >> Hi glasgow-haskell-users,
> >> >>
> >> >> I have written a wiki page about a proposed extension called
> >> >> ArgumentDo. It's a small syntactic extension that allows "do"
> >> >> expressions, lambdas and a few other kinds of expressions to be used
> >> >> as function arguments, without parentheses.
> >> >>
> >> >> https://ghc.haskell.org/trac/ghc/wiki/ArgumentDo
> >> >>
> >> >> Any feedback is appreciated. In particular, since the idea has
> >> >> received mixed support (see the "Discussion" section on the wiki
> >> >> page), I'd like to make sure that there is enough support for this
> >> >> feature to justify an implementation in GHC.
> >> >>
> >> >
> >> > -1
> >> >
> >> > Reasons have already been given in previous threads on this. However,
> >> > I'd point especially to the fact that people don't *agree* that this
> is
> >> > more readable as a very strong point against -- regardless of whether
> >> > any one individual thinks it's more readable or not. The point is the
> >> > there seems to be a lot of disagreement -- that indicates to me that
> >> > this cannot by definition be a "clear win"[1]. Disclosure: I
> personally
> >> > find it less readable because of the implicitness. Implicitness which
> >> > has a non-trivial probability of affecting semantics is bad in my
> book.
> >> > Frankly, if it came to it, I'd rather just remove $ and deal with the
> >> > parentheses.
> >>
> >> I'm -1 because I think there are already too many styles.  So I don't
> >> agree with the general sentiment that the parser should accept lots of
> >> stuff and to rely on style guides to specify something, because in
> >> practice everyone has their own style guide.
> >>
> >> I trained myself to see juxtaposition as highest precedence (which
> >> newcomers still struggle over) and it's confusing to see juxtaposition
> >> that has higher precedence because one of them is a keyword.  In the
> >> same way I'm confused by 'f a { b = c }', but it's too late to change
> >> that one.  I suppose this is already on the wiki page in the "cons"
> >> section.
> >> ___
> >> 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
> >
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>



-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Proposal: ArgumentDo

[David Feuer]

What makes

f do{x} do{y}

any harder to read than similar record syntax?

f Foo{foo=3} Foo{foo=4}

On Thu, Jul 7, 2016 at 1:15 PM, Carter Schonwald
 wrote:
> agreed -1,
> ambiguity is bad for humans, not just parsers.
>
> perhaps most damningly,
>>
>>
>> f do{ x } do { y }
>
>
> is just reallly really weird/confusing to me, and as the proposal itself
> says at the end as the cons:
>
>
>> It's harder to read than the alternative.
>>
>> Creating a language extension to get rid of a single character is overkill
>> and unnecessary.
>>
>> You can already get rid of the $ by just adding parentheses.
>
> which kinda kills any benefit in my mind. thats a HUGE complexity vs
> alternative ratio. I'm all in favor of doing engineering work to *improve*
> our parser error messages and suggestions, but not stuff that complicates
> parsing for humans  as well as machines
>
>
> On Wed, Jul 6, 2016 at 9:50 PM, Evan Laforge  wrote:
>>
>> On Wed, Jul 6, 2016 at 10:39 AM, Bardur Arantsson 
>> wrote:
>> > On 07/04/2016 12:31 PM, Akio Takano wrote:
>> >> Hi glasgow-haskell-users,
>> >>
>> >> I have written a wiki page about a proposed extension called
>> >> ArgumentDo. It's a small syntactic extension that allows "do"
>> >> expressions, lambdas and a few other kinds of expressions to be used
>> >> as function arguments, without parentheses.
>> >>
>> >> https://ghc.haskell.org/trac/ghc/wiki/ArgumentDo
>> >>
>> >> Any feedback is appreciated. In particular, since the idea has
>> >> received mixed support (see the "Discussion" section on the wiki
>> >> page), I'd like to make sure that there is enough support for this
>> >> feature to justify an implementation in GHC.
>> >>
>> >
>> > -1
>> >
>> > Reasons have already been given in previous threads on this. However,
>> > I'd point especially to the fact that people don't *agree* that this is
>> > more readable as a very strong point against -- regardless of whether
>> > any one individual thinks it's more readable or not. The point is the
>> > there seems to be a lot of disagreement -- that indicates to me that
>> > this cannot by definition be a "clear win"[1]. Disclosure: I personally
>> > find it less readable because of the implicitness. Implicitness which
>> > has a non-trivial probability of affecting semantics is bad in my book.
>> > Frankly, if it came to it, I'd rather just remove $ and deal with the
>> > parentheses.
>>
>> I'm -1 because I think there are already too many styles.  So I don't
>> agree with the general sentiment that the parser should accept lots of
>> stuff and to rely on style guides to specify something, because in
>> practice everyone has their own style guide.
>>
>> I trained myself to see juxtaposition as highest precedence (which
>> newcomers still struggle over) and it's confusing to see juxtaposition
>> that has higher precedence because one of them is a keyword.  In the
>> same way I'm confused by 'f a { b = c }', but it's too late to change
>> that one.  I suppose this is already on the wiki page in the "cons"
>> section.
>> ___
>> 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
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Proposal: ArgumentDo

[Carter Schonwald]

agreed -1,
ambiguity is bad for humans, not just parsers.

perhaps most damningly,


> f do{ x } do { y }


is just reallly really weird/confusing to me, and as the proposal
itself says at the end as the cons:



   - It's harder to read than the alternative.
>- Creating a language extension to get rid of a single character is 
> overkill and unnecessary.
>- You can already get rid of the $ by just adding parentheses.
>

which kinda kills any benefit in my mind. thats a HUGE complexity vs
alternative ratio. I'm all in favor of doing engineering work to
*improve* our parser error messages and suggestions, but not stuff
that complicates parsing for humans  as well as machines


On Wed, Jul 6, 2016 at 9:50 PM, Evan Laforge  wrote:

> On Wed, Jul 6, 2016 at 10:39 AM, Bardur Arantsson 
> wrote:
> > On 07/04/2016 12:31 PM, Akio Takano wrote:
> >> Hi glasgow-haskell-users,
> >>
> >> I have written a wiki page about a proposed extension called
> >> ArgumentDo. It's a small syntactic extension that allows "do"
> >> expressions, lambdas and a few other kinds of expressions to be used
> >> as function arguments, without parentheses.
> >>
> >> https://ghc.haskell.org/trac/ghc/wiki/ArgumentDo
> >>
> >> Any feedback is appreciated. In particular, since the idea has
> >> received mixed support (see the "Discussion" section on the wiki
> >> page), I'd like to make sure that there is enough support for this
> >> feature to justify an implementation in GHC.
> >>
> >
> > -1
> >
> > Reasons have already been given in previous threads on this. However,
> > I'd point especially to the fact that people don't *agree* that this is
> > more readable as a very strong point against -- regardless of whether
> > any one individual thinks it's more readable or not. The point is the
> > there seems to be a lot of disagreement -- that indicates to me that
> > this cannot by definition be a "clear win"[1]. Disclosure: I personally
> > find it less readable because of the implicitness. Implicitness which
> > has a non-trivial probability of affecting semantics is bad in my book.
> > Frankly, if it came to it, I'd rather just remove $ and deal with the
> > parentheses.
>
> I'm -1 because I think there are already too many styles.  So I don't
> agree with the general sentiment that the parser should accept lots of
> stuff and to rely on style guides to specify something, because in
> practice everyone has their own style guide.
>
> I trained myself to see juxtaposition as highest precedence (which
> newcomers still struggle over) and it's confusing to see juxtaposition
> that has higher precedence because one of them is a keyword.  In the
> same way I'm confused by 'f a { b = c }', but it's too late to change
> that one.  I suppose this is already on the wiki page in the "cons"
> section.
> ___
> 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

Re: Proposal: ArgumentDo

[Evan Laforge]

On Wed, Jul 6, 2016 at 10:39 AM, Bardur Arantsson  wrote:
> On 07/04/2016 12:31 PM, Akio Takano wrote:
>> Hi glasgow-haskell-users,
>>
>> I have written a wiki page about a proposed extension called
>> ArgumentDo. It's a small syntactic extension that allows "do"
>> expressions, lambdas and a few other kinds of expressions to be used
>> as function arguments, without parentheses.
>>
>> https://ghc.haskell.org/trac/ghc/wiki/ArgumentDo
>>
>> Any feedback is appreciated. In particular, since the idea has
>> received mixed support (see the "Discussion" section on the wiki
>> page), I'd like to make sure that there is enough support for this
>> feature to justify an implementation in GHC.
>>
>
> -1
>
> Reasons have already been given in previous threads on this. However,
> I'd point especially to the fact that people don't *agree* that this is
> more readable as a very strong point against -- regardless of whether
> any one individual thinks it's more readable or not. The point is the
> there seems to be a lot of disagreement -- that indicates to me that
> this cannot by definition be a "clear win"[1]. Disclosure: I personally
> find it less readable because of the implicitness. Implicitness which
> has a non-trivial probability of affecting semantics is bad in my book.
> Frankly, if it came to it, I'd rather just remove $ and deal with the
> parentheses.

I'm -1 because I think there are already too many styles.  So I don't
agree with the general sentiment that the parser should accept lots of
stuff and to rely on style guides to specify something, because in
practice everyone has their own style guide.

I trained myself to see juxtaposition as highest precedence (which
newcomers still struggle over) and it's confusing to see juxtaposition
that has higher precedence because one of them is a keyword.  In the
same way I'm confused by 'f a { b = c }', but it's too late to change
that one.  I suppose this is already on the wiki page in the "cons"
section.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Proposal: ArgumentDo

[Bardur Arantsson]

On 07/04/2016 12:31 PM, Akio Takano wrote:
> Hi glasgow-haskell-users,
> 
> I have written a wiki page about a proposed extension called
> ArgumentDo. It's a small syntactic extension that allows "do"
> expressions, lambdas and a few other kinds of expressions to be used
> as function arguments, without parentheses.
> 
> https://ghc.haskell.org/trac/ghc/wiki/ArgumentDo
> 
> Any feedback is appreciated. In particular, since the idea has
> received mixed support (see the "Discussion" section on the wiki
> page), I'd like to make sure that there is enough support for this
> feature to justify an implementation in GHC.
> 

-1

Reasons have already been given in previous threads on this. However,
I'd point especially to the fact that people don't *agree* that this is
more readable as a very strong point against -- regardless of whether
any one individual thinks it's more readable or not. The point is the
there seems to be a lot of disagreement -- that indicates to me that
this cannot by definition be a "clear win"[1]. Disclosure: I personally
find it less readable because of the implicitness. Implicitness which
has a non-trivial probability of affecting semantics is bad in my book.
Frankly, if it came to it, I'd rather just remove $ and deal with the
parentheses.

Regards,

[1] Which I should think the barrier to extensions should roughly be :).

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Proposal: ArgumentDo

[C Maeder]

Hi,

allowing group A constructs (do, case, ...) and group B constructs (\,
let, if, ...) as parts of functions application (fexp) without extra
parentheses looks natural to me. The current state is an artificial and
unnecessary restriction. Style guides may dictate restrictions, but the
parser/language should not (without good reasons).

So +1 for the proposal from me.

However, I would not distinguish group A and group B constructs in the
proposed grammar rules. The report already states (for the group B
constructs):
"The grammar is ambiguous regarding the extent of lambda abstractions,
let expressions, and conditionals. The ambiguity is resolved by the
meta-rule that each of these constructs extends as far to the right as
possible."

Therefore I would simply add all constructs (that start with a unique
keyword) to atomic expressions (aexp) where the term "atomic" might be
misleading but is already accepted for the record constructs.

For the group B constructs this simply means that they can only be the
last argument (or the mere function itself) in any expression (exp). The
non-terminal lexp is no longer needed (and could be replaced by fexp in
infixexp).

Furthermore group B constructs are also delimited by the layout rules
(of decls).

Cheers Christian

Am 04.07.2016 um 12:31 schrieb Akio Takano:
> Hi glasgow-haskell-users,
> 
> I have written a wiki page about a proposed extension called
> ArgumentDo. It's a small syntactic extension that allows "do"
> expressions, lambdas and a few other kinds of expressions to be used
> as function arguments, without parentheses.
> 
> https://ghc.haskell.org/trac/ghc/wiki/ArgumentDo
> 
> Any feedback is appreciated. In particular, since the idea has
> received mixed support (see the "Discussion" section on the wiki
> page), I'd like to make sure that there is enough support for this
> feature to justify an implementation in GHC.
> 
> Regards,
> Takano Akio
> ___
> 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

Re: Proposal: ArgumentDo

[David Luposchainsky via Glasgow-haskell-users]

Infix ($) is so noisy that I’ve adapted a code style that replaces it entirely
with parentheses. And the hack to make ($) work with higher-rank types is pretty
awkward too. Seen from these angles, I’m very much in favour of ArgumentDo.

However, the clarity of `runST do ...` comes at a high price: only some of the
missing ($) make the code clearer, where others make it much worse. You give a
couple of examples yourself:

> f
>   do x
>   do y

I have to think a bit how this might be parsed even after reading the proposal.
I’m a bit torn on whether I like or not like it, but I think the ArgumentDo
syntax that I find awkward now is a matter of style, and one could probably get
used to only using it in certain places, despite all of the possibilities.

David/quchen
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Proposal: ArgumentDo

[Akio Takano]

Hi glasgow-haskell-users,

I have written a wiki page about a proposed extension called
ArgumentDo. It's a small syntactic extension that allows "do"
expressions, lambdas and a few other kinds of expressions to be used
as function arguments, without parentheses.

https://ghc.haskell.org/trac/ghc/wiki/ArgumentDo

Any feedback is appreciated. In particular, since the idea has
received mixed support (see the "Discussion" section on the wiki
page), I'd like to make sure that there is enough support for this
feature to justify an implementation in GHC.

Regards,
Takano Akio
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users