It's a postfix operator, with the same precedence and same (left-)associativity as function application.

Yes, that’s right. Nice. Simon From: Richard Eisenberg Sent: 07 January 2020 11:39 To: Simon Peyton Jones Cc: ghc-steering-committee@haskell.org Subject: Re: [ghc-steering-committee] Record syntax On Jan 7, 2020, at 11:29 AM, Simon Peyton Jones via ghc-steering-committee mailto:ghc-steering-committee@haskell.org> wrote: It’s a postfix operator, binding less tightly than function application, but more tightly than any infix operator. I want to understand this a bit better. Looking at your examples, I would phrase it thusly:

It's a postfix operator, with the same precedence and same (left-)associativity as function application.

Does this agree with your idea? Indeed, I can't quite figure out what your text would mean. Richard

I’m rather uncomfortable with (1), for reasons mentioned by others before: it prevents cutting a sequence of .field with a newline. I’m agnostic between (2) and (3). I’m fine with a vote, but even more fine with Simon just choosing for everybody else :) . On Tue, Jan 7, 2020 at 1:50 PM Joachim Breitner wrote:

Hi,

I dislike separating the two major questions.

If we go with (3) (tight postfix, Ocaml-style), the no-space question becomes irrelevant; we’d not even have to mention it any more, as it follows naturally from tight binding.

If we go with (2) (same-as-application, JS-style), then the no-space question becomes “do we want to make zero whitespace special”.

So to me, the two questions are inherently tied together.

If it comes to a vote, that’s not a problem; ranked voting will take care of that.

Views have been exchanged, no new technical insights have appeared for a while and this is inherently opinion-based, so I am inclined to just resolve this by voting among the committee, instead of poking until consensus emerges.

Cheers, Joachim

-- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

I'm happy with either (2) or (3). But I do wonder how much we should be basing our decision off of the hypothetical method chaining. It looks very compelling, but xs .map double .filter isEven will not be valid since lists have no fields, much less functional fields. People could add virtual fields with custom instances of HasField, but (1) they'd be orphans until we add them to base (which would probably take time) and (2) something about using HasField for this just seems off to me. I can't quite put my finger on it though.. so maybe I'm just being overly conservative. The important thing for this discussion is that by invoking the method chaining example, we're implicitly endorsing either virtual fields or some other yet-to-be-designed way of treating functions as fields[1]. I think we should be more explicit about that. Eric [1] For example, you could imagine functions automatically being virtual fields of their last input type (the last one because we often design functions to be partially applied), but I'm pretty sure that would be awkward in practice. On Fri, Jan 10, 2020, at 04:41, Simon Marlow wrote:

My inclination was (3) over (2), because it seems more elegant: * it explains the interpretation of "f r.x", as you said, and * it means that "f r .x" is not different from "f r.x" (I prefer to avoid whitespace-sensitivity if we can)

But I'm somewhat persuaded by the "f.map double .filter isEven" example. So there are swings and roundabouts here, I don't see an obvious best choice between (2) and (3).

Cheers Simon

On Tue, 7 Jan 2020 at 11:29, Simon Peyton Jones via ghc-steering-committee wrote:

...

Friends____

...

I’d like to move our record-syntax discussion forward. Link to proposal discussion https://github.com/ghc-proposals/ghc-proposals/pull/282, and December GHC steering committee debates https://mail.haskell.org/pipermail/ghc-steering-committee/2019-December/thre....____

...

*No-space arguments____*

...

I believe have agreed that ____

...

f r.x____

...

(with no spaces around the dot, and no parens around r.x) means____

...

f (r.x)____

...

That is, treat it consistently with qualified names. I asked everyone to express a view; Iavor, Eric, Arnaud, Joachim, and Richard all said it was at least acceptable; others expressed no view. So let’s take that as a decision, at least for now.____

...

*Naked selectors____*

...

Next question: how should we treat a “naked selector”, namely .x where there is no space after the dot, but there is a space before. I think there are three viable choices:____

...

1. *It’s simply illegal*. This defers the choice; perhaps later we will have more experience to go on.____ 2. *It’s a postfix operator*, binding less tightly than function application, but more tightly than any infix operator. So then (r .x) means r.x, and (r .x .y) means r.x.y. But (f r .x) means (f r).x.____ This choice naturally supports chaining (nice to have, but not essential). We can write____

...

f .map double____

...

.filter isEven____

...

meaning *(f.map double).filter isEven*____

...

1. *It’s a postfix operator*, binding more tightly than function application, just as record update does. So then (f r .x) means (f r.x), and (f r .x .y s .z) means (f r.x.y s.z).____ This choice allows us to regard our decision about (f r.x) as what naturally happens if we parse it as three lexemes: f, r, and .x. But it also breaks the “function application binds more tightly than anything else” rule, just as (f r {x=3}) sadly does already.____

...

It does not permit chaining, at least not without stacked-up parens.____

...

In all three cases we allow (.x), meaning (\r. r.x). For (2) and (3) we can regard it as a “section”, like infix operators only simpler because there is no argument.____

...

I think this is the last major question we have to answer.____

...

What are your views? Personally I lean towards (2), but I could certainly live with (1). I’m a bit reluctant to adopt (3).____

...

Simon____

...

__ __

...

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

---

ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Hi,

Consider (f .x g .y h .z)

(2) says this means ((((f .x) g) .y) h) .z), so that it parenthesises exactly like function application.

(3) says it means (((f .x) (g .y)) (h .z)) which, while unambiguous, I dislike cordially.

I propose to adopt (2).

I agree that “exactly like function application” is a great, simple universal way of explaining the parsing. But I can't stop pointing out that this is inconsistent if we insist that `f r.x = f (r.x)`. With function application, no space or space is irrelevant: f r"" = f r "" ≠ f (r "") = f (r "") You propose f r.x ≠ f r .x = f (r .x) = f (r .x) while I am still attached to f r.x = f r .x ≠ f (r .x) = f (r .x) I know that this will disappoint a few who want their code to look like it does in some other languages (many object oriented langauges, Ocaml), and who do not want to put in the extra parentheses. But in this case I am leaning towards the elegance of _really_ saying “exactly like function application”, not only syntactically, but also morally (a record is a function on a finite set of field names.) I find this very justifiable for a functional programming language. And I find it very un-haskelly that going from a space to no space between expressions makes a difference (I believe Simon Marlow shared this reservation.) If we do insist on “binds more tightly if no space”, then I am actually in favor of “also binds more tightly if there is a space”, i.e. (3) above, to avoid the whitespace-sensitivity. So if it comes to a vote, I think these three options cover all opinions so far? * f r .x = (f r).x; f r.x = f (r.x) -- Simon’s (2) * f r .x = (f r).x; f r.x = (f r).x) -- My take on it * f r .x = f (r.x); f r.x = f (r.x) -- Simon’s (3) Anything else? If we vote, I hope we don't get too many abstinations. Nobody will be personally offended if you vote “against” them (I hope), but whatever outcome we have better have weight, and is supported by a high turnout. And I think we should just vote; we keep rephrasing the same arguments with different words. Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

I know I know. It matters for what are the names of variables. My mental parser first looks what are the names (and handles module prefixes), and then the expression parser runs. At least in my head. And module prefixes are not arbitrary expressions (yet…), but the `r` can be an arbitrary complex expression! f (foo bar // baz).r vs f (foo bar // baz) .r would be different under your proposal, but the same under mine. But none of this is new to anyone here… why not just vote and get a decision? Cheers, Joachim Am 28. Januar 2020 12:58:34 MEZ schrieb Simon Peyton Jones :

| With function application, no space or space is irrelevant: | | f r"" = f r "" ≠ f (r "") = f (r "")

But that is not so

f r x ≠ f rx f M.x ≠ f M x

White space (or its absence) matters.

Simon

| -----Original Message----- | From: ghc-steering-committee | On Behalf Of Joachim Breitner | Sent: 28 January 2020 11:55 | To: ghc-steering-committee@haskell.org | Subject: Re: [ghc-steering-committee] Record syntax | | Hi, | | > Consider (f .x g .y h .z) | > | > (2) says this means ((((f .x) g) .y) h) .z), so that it parenthesises | > exactly like function application. | > | > (3) says it means (((f .x) (g .y)) (h .z)) which, while unambiguous, | > I dislike cordially. | > | > I propose to adopt (2). | | I agree that “exactly like function application” is a great, simple | universal way of explaining the parsing. | | But I can't stop pointing out that this is inconsistent if we insist | that `f r.x = f (r.x)`. | | With function application, no space or space is irrelevant: | | f r"" = f r "" ≠ f (r "") = f (r "") | | You propose | | f r.x ≠ f r .x = f (r .x) = f (r .x) | | while I am still attached to | | f r.x = f r .x ≠ f (r .x) = f (r .x) | | I know that this will disappoint a few who want their code to look like | it does in some other languages (many object oriented langauges, | Ocaml), and who do not want to put in the extra parentheses. But in | this case I am leaning towards the elegance of _really_ saying “exactly | like function application”, not only syntactically, but also morally (a | record is a function on a finite set of field names.) | I find this very justifiable for a functional programming language. | | And I find it very un-haskelly that going from a space to no space | between expressions makes a difference (I believe Simon Marlow shared | this reservation.) | | | If we do insist on “binds more tightly if no space”, then I am actually | in favor of “also binds more tightly if there is a space”, i.e. (3) | above, to avoid the whitespace-sensitivity. | | | So if it comes to a vote, I think these three options cover all | opinions so far? | | * f r .x = (f r).x; f r.x = f (r.x) -- Simon’s (2) | * f r .x = (f r).x; f r.x = (f r).x) -- My take on it | * f r .x = f (r.x); f r.x = f (r.x) -- Simon’s (3) | | Anything else? | | | If we vote, I hope we don't get too many abstinations. Nobody will be | personally offended if you vote “against” them (I hope), but whatever | outcome we have better have weight, and is supported by a high turnout. | | | And I think we should just vote; we keep rephrasing the same arguments | with different words. | | Cheers, | Joachim | | -- | Joachim Breitner | mail@joachim-breitner.de | | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joach | im- | breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C99dc94685bb34e | 1f694a08d7a3e8faa2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6371580933 | 72311824&sdata=N7iqz4VoL6oe4ICm3JIVVLW%2BBM%2BVIdGOeYa2obcjqdI%3D& | reserved=0 | | | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee@haskell.org | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.has | kell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=02%7C01%7Csimonpj%40microsoft.com%7C99dc94685bb34e1f694 | a08d7a3e8faa2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637158093372311 | 824&sdata=AnxNHulQCUqWkKaKYmEXYQMQwl3F1MDPYS64GIAnVhA%3D&reserved= | 0

Hey guys, I'm new here, what is this weird dot nonsense? :D Can we perhaps avoid overloading (.) further? Function composition is really important, and I was already upset at the lack of visual clarity by the time it was used for qualifying modules... On Tue, 28 Jan 2020 at 08:58, Eric Seidel wrote:

I agree with Joachim that we should have a formal vote on this point. It's contentious, as syntax always seems to be, so it would be good to get everyone's opinion on record, even if that opinion is just "2 and 3 both seem reasonable to me".

But, before we vote, it occurs to me that we have three new committee members (welcome!) who might have comments or questions. Alejandro, Cale, and Tom, have you been following the discussion so far, or do you need a summary? I wouldn't blame you, it's been dragging on for a very long time..

On Tue, Jan 28, 2020, at 07:12, Joachim Breitner wrote:

...

I know I know. It matters for what are the names of variables. My mental parser first looks what are the names (and handles module prefixes), and then the expression parser runs. At least in my head.

And module prefixes are not arbitrary expressions (yet…), but the `r` can be an arbitrary complex expression!

f (foo bar // baz).r

vs

f (foo bar // baz) .r

would be different under your proposal, but the same under mine.

But none of this is new to anyone here… why not just vote and get a decision?

Cheers, Joachim

Am 28. Januar 2020 12:58:34 MEZ schrieb Simon Peyton Jones :

...

| With function application, no space or space is irrelevant: | | f r"" = f r "" ≠ f (r "") = f (r "")

But that is not so

f r x ≠ f rx f M.x ≠ f M x

White space (or its absence) matters.

Simon

| -----Original Message----- | From: ghc-steering-committee | On Behalf Of Joachim Breitner | Sent: 28 January 2020 11:55 | To: ghc-steering-committee@haskell.org | Subject: Re: [ghc-steering-committee] Record syntax | | Hi, | | > Consider (f .x g .y h .z) | > | > (2) says this means ((((f .x) g) .y) h) .z), so that it parenthesises | > exactly like function application. | > | > (3) says it means (((f .x) (g .y)) (h .z)) which, while unambiguous, | > I dislike cordially. | > | > I propose to adopt (2). | | I agree that “exactly like function application” is a great, simple | universal way of explaining the parsing. | | But I can't stop pointing out that this is inconsistent if we insist | that `f r.x = f (r.x)`. | | With function application, no space or space is irrelevant: | | f r"" = f r "" ≠ f (r "") = f (r "") | | You propose | | f r.x ≠ f r .x = f (r .x) = f (r .x) | | while I am still attached to | | f r.x = f r .x ≠ f (r .x) = f (r .x) | | I know that this will disappoint a few who want their code to look like | it does in some other languages (many object oriented langauges, | Ocaml), and who do not want to put in the extra parentheses. But in | this case I am leaning towards the elegance of _really_ saying “exactly | like function application”, not only syntactically, but also morally (a | record is a function on a finite set of field names.) | I find this very justifiable for a functional programming language. | | And I find it very un-haskelly that going from a space to no space | between expressions makes a difference (I believe Simon Marlow shared | this reservation.) | | | If we do insist on “binds more tightly if no space”, then I am actually | in favor of “also binds more tightly if there is a space”, i.e. (3) | above, to avoid the whitespace-sensitivity. | | | So if it comes to a vote, I think these three options cover all | opinions so far? | | * f r .x = (f r).x; f r.x = f (r.x) -- Simon’s (2) | * f r .x = (f r).x; f r.x = (f r).x) -- My take on it | * f r .x = f (r.x); f r.x = f (r.x) -- Simon’s (3) | | Anything else? | | | If we vote, I hope we don't get too many abstinations. Nobody will be | personally offended if you vote “against” them (I hope), but whatever | outcome we have better have weight, and is supported by a high turnout. | | | And I think we should just vote; we keep rephrasing the same arguments | with different words. | | Cheers, | Joachim | | -- | Joachim Breitner | mail@joachim-breitner.de | | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joach | im- | breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C99dc94685bb34e | 1f694a08d7a3e8faa2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6371580933 | 72311824&sdata=N7iqz4VoL6oe4ICm3JIVVLW%2BBM%2BVIdGOeYa2obcjqdI%3D& | reserved=0 | | | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee@haskell.org | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.has | kell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=02%7C01%7Csimonpj%40microsoft.com%7C99dc94685bb34e1f694 | a08d7a3e8faa2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637158093372311 | 824&sdata=AnxNHulQCUqWkKaKYmEXYQMQwl3F1MDPYS64GIAnVhA%3D&reserved= | 0

---

ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

| I hope we'll get a proposal that doesn't trip into so many gnarly problems | and achieves more of what is expected of a modern record system. It's | worth waiting. That's a legitimate point of view, but we have been waiting -- for *precisely* this reason -- for well over a decade. Personally I think it's time to move. I think voting is fine -- there are matters of judgement here. I'll think about what the questions are. Simon | -----Original Message----- | From: ghc-steering-committee | On Behalf Of Christopher Allen | Sent: 28 January 2020 14:18 | To: Cale Gibbard | Cc: ghc-steering-committee@haskell.org | Subject: Re: [ghc-steering-committee] Record syntax | | I'm still where I was before: we should reject this proposal. The | exploding state space of how code using (.) should be parsed and the fact | that there are this many dark corners make this a bad idea. It's not worth | it. | | I hope we'll get a proposal that doesn't trip into so many gnarly problems | and achieves more of what is expected of a modern record system. It's | worth waiting. | | > On Jan 28, 2020, at 08:05, Cale Gibbard wrote: | > | > Hey guys, I'm new here, what is this weird dot nonsense? :D | > | > Can we perhaps avoid overloading (.) further? Function composition is | > really important, and I was already upset at the lack of visual | > clarity by the time it was used for qualifying modules... | > | >> On Tue, 28 Jan 2020 at 08:58, Eric Seidel wrote: | >> | >> I agree with Joachim that we should have a formal vote on this point. | It's contentious, as syntax always seems to be, so it would be good to get | everyone's opinion on record, even if that opinion is just "2 and 3 both | seem reasonable to me". | >> | >> But, before we vote, it occurs to me that we have three new committee | members (welcome!) who might have comments or questions. Alejandro, Cale, | and Tom, have you been following the discussion so far, or do you need a | summary? I wouldn't blame you, it's been dragging on for a very long | time.. | >> | >>> On Tue, Jan 28, 2020, at 07:12, Joachim Breitner wrote: | >>> I know I know. It matters for what are the names of variables. My | >>> mental parser first looks what are the names (and handles module | >>> prefixes), and then the expression parser runs. At least in my head. | >>> | >>> And module prefixes are not arbitrary expressions (yet…), but the `r` | >>> can be an arbitrary complex expression! | >>> | >>> f (foo bar // baz).r | >>> | >>> vs | >>> | >>> f (foo bar // baz) .r | >>> | >>> would be different under your proposal, but the same under mine. | >>> | >>> But none of this is new to anyone here… why not just vote and get a | decision? | >>> | >>> Cheers, | >>> Joachim | >>> | >>> | >>> Am 28. Januar 2020 12:58:34 MEZ schrieb Simon Peyton Jones | >>> : | >>>> | With function application, no space or space is irrelevant: | >>>> | | >>>> | f r"" = f r "" ≠ f (r "") = f (r "") | >>>> | >>>> But that is not so | >>>> | >>>> f r x ≠ f rx | >>>> f M.x ≠ f M x | >>>> | >>>> White space (or its absence) matters. | >>>> | >>>> Simon | >>>> | >>>> | -----Original Message----- | >>>> | From: ghc-steering-committee | >>>> | >>>> | On Behalf Of Joachim Breitner | >>>> | Sent: 28 January 2020 11:55 | >>>> | To: ghc-steering-committee@haskell.org | >>>> | Subject: Re: [ghc-steering-committee] Record syntax | >>>> | | >>>> | Hi, | >>>> | | >>>> | > Consider (f .x g .y h .z) | >>>> | > | >>>> | > (2) says this means ((((f .x) g) .y) h) .z), so that it | >>>> parenthesises | >>>> | > exactly like function application. | >>>> | > | >>>> | > (3) says it means (((f .x) (g .y)) (h .z)) which, while | >>>> unambiguous, | >>>> | > I dislike cordially. | >>>> | > | >>>> | > I propose to adopt (2). | >>>> | | >>>> | I agree that “exactly like function application” is a great, | simple | >>>> | universal way of explaining the parsing. | >>>> | | >>>> | But I can't stop pointing out that this is inconsistent if we | insist | >>>> | that `f r.x = f (r.x)`. | >>>> | | >>>> | With function application, no space or space is irrelevant: | >>>> | | >>>> | f r"" = f r "" ≠ f (r "") = f (r "") | >>>> | | >>>> | You propose | >>>> | | >>>> | f r.x ≠ f r .x = f (r .x) = f (r .x) | >>>> | | >>>> | while I am still attached to | >>>> | | >>>> | f r.x = f r .x ≠ f (r .x) = f (r .x) | >>>> | | >>>> | I know that this will disappoint a few who want their code to look | >>>> like | >>>> | it does in some other languages (many object oriented langauges, | >>>> | Ocaml), and who do not want to put in the extra parentheses. But | in | >>>> | this case I am leaning towards the elegance of _really_ saying | >>>> “exactly | >>>> | like function application”, not only syntactically, but also | morally | >>>> (a | >>>> | record is a function on a finite set of field names.) | >>>> | I find this very justifiable for a functional programming | language. | >>>> | | >>>> | And I find it very un-haskelly that going from a space to no space | >>>> | between expressions makes a difference (I believe Simon Marlow | >>>> shared | >>>> | this reservation.) | >>>> | | >>>> | | >>>> | If we do insist on “binds more tightly if no space”, then I am | >>>> actually | >>>> | in favor of “also binds more tightly if there is a space”, i.e. | (3) | >>>> | above, to avoid the whitespace-sensitivity. | >>>> | | >>>> | | >>>> | So if it comes to a vote, I think these three options cover all | >>>> | opinions so far? | >>>> | | >>>> | * f r .x = (f r).x; f r.x = f (r.x) -- Simon’s (2) | >>>> | * f r .x = (f r).x; f r.x = (f r).x) -- My take on it | >>>> | * f r .x = f (r.x); f r.x = f (r.x) -- Simon’s (3) | >>>> | | >>>> | Anything else? | >>>> | | >>>> | | >>>> | If we vote, I hope we don't get too many abstinations. Nobody will | >>>> be | >>>> | personally offended if you vote “against” them (I hope), but | >>>> whatever | >>>> | outcome we have better have weight, and is supported by a high | >>>> turnout. | >>>> | | >>>> | | >>>> | And I think we should just vote; we keep rephrasing the same | >>>> arguments | >>>> | with different words. | >>>> | | >>>> | Cheers, | >>>> | Joachim | >>>> | | >>>> | -- | >>>> | Joachim Breitner | >>>> | mail@joachim-breitner.de | >>>> | | >>>> | | >>>> | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joach | >>>> | im- | >>>> | | >>>> | breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C99dc94685bb34e | >>>> | | >>>> | 1f694a08d7a3e8faa2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6371580933 | >>>> | | >>>> | 72311824&sdata=N7iqz4VoL6oe4ICm3JIVVLW%2BBM%2BVIdGOeYa2obcjqdI%3D& | >>>> | reserved=0 | >>>> | | >>>> | | >>>> | _______________________________________________ | >>>> | ghc-steering-committee mailing list | >>>> | ghc-steering-committee@haskell.org | >>>> | | >>>> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.has | >>>> | kell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | >>>> | | >>>> | committee&data=02%7C01%7Csimonpj%40microsoft.com%7C99dc94685bb34e1f694 | >>>> | | >>>> | a08d7a3e8faa2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637158093372311 | >>>> | | >>>> | 824&sdata=AnxNHulQCUqWkKaKYmEXYQMQwl3F1MDPYS64GIAnVhA%3D&reserved= | >>>> | 0 | >>> _______________________________________________ | >>> ghc-steering-committee mailing list | >>> ghc-steering-committee@haskell.org | >>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering- | committee | >>> | >> _______________________________________________ | >> ghc-steering-committee mailing list | >> ghc-steering-committee@haskell.org | >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering- | committee | > _______________________________________________ | > ghc-steering-committee mailing list | > ghc-steering-committee@haskell.org | > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee@haskell.org | https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

I'd be willing, in some cases, to use things like getField. I have done so in the past. I have been a happy `lens` user in production projects. I don't think the proposal is worth accepting as-is. One of the reasons I've liked Haskell's design historically is that features were orthogonal, well-designed, consistent with the rest of the language, and fairly complete. I do realize that when you're closer to the sausage-making you're more aware of the flaws. The grade of proposals some of you are proposing for acceptance into GHC aren't up to the standards of even languages I wouldn't want to use in my everyday work. We can and should set a higher standard than this proposal meets whether it's been a problem for 10 years or 10 weeks. Anybody that wants this functionality can have it with the libraries that already exist. This is how we get another GHC extension that is poorly understood and doesn't consistently work from one major GHC version to the next. I get that it's fun to figure out what kind of syntax would seem the most sensible or cleanly designed for this feature. What makes this fun to kick around is the same as what makes it unacceptable for inclusion in GHC. None of this is a judgment on the proposal authors themselves. They're trying to move the ball forward and they put serious effort into the proposal. I respect that but that doesn't factor into whether it's a good candidate for inclusion into the compiler. I think perhaps the design space isn't developed enough right now. I'm hoping we'll have a compelling solution for this in the future. On Tue, Jan 28, 2020 at 8:43 AM Cale Gibbard wrote:

Thinking about it further, I'd often already be somewhat upset with overuse of polymorphic getField making it hard to mentally typecheck expressions, and hard to ensure that things work as intended.

The meaning of HasField x r a is just that a value of type r has a field with the appropriate name x and type a -- it doesn't necessarily express that the /meaning/ of that field is what my function expects, unless we're globally very careful about our record field names. If on the other hand, I ask that people implement an instance of some new explicit type class HasMyRelevantQuantity for their types, I am provided with some assurance that someone at least thought about what the methods of my class were intended to mean, and are not just mashing things together which happen to typecheck only because someone reused the name of a field that happened to be an Int in both cases.

So I'm already a bit hesitant there. I can imagine it's still very convenient in some cases, especially those involving automatically-generated types, but usually I'd want people to do better about saying what they mean than what HasField gives them.

On Tue, 28 Jan 2020 at 09:29, Simon Peyton Jones wrote:

...

| I hope we'll get a proposal that doesn't trip into so many gnarly problems | and achieves more of what is expected of a modern record system. It's | worth waiting.

That's a legitimate point of view, but we have been waiting -- for *precisely* this reason -- for well over a decade. Personally I think it's time to move.

I think voting is fine -- there are matters of judgement here. I'll think about what the questions are.

Simon

| -----Original Message----- | From: ghc-steering-committee | On Behalf Of Christopher Allen | Sent: 28 January 2020 14:18 | To: Cale Gibbard | Cc: ghc-steering-committee@haskell.org | Subject: Re: [ghc-steering-committee] Record syntax | | I'm still where I was before: we should reject this proposal. The | exploding state space of how code using (.) should be parsed and the fact | that there are this many dark corners make this a bad idea. It's not worth | it. | | I hope we'll get a proposal that doesn't trip into so many gnarly problems | and achieves more of what is expected of a modern record system. It's | worth waiting. | | > On Jan 28, 2020, at 08:05, Cale Gibbard wrote: | > | > Hey guys, I'm new here, what is this weird dot nonsense? :D | > | > Can we perhaps avoid overloading (.) further? Function composition is | > really important, and I was already upset at the lack of visual | > clarity by the time it was used for qualifying modules... | > | >> On Tue, 28 Jan 2020 at 08:58, Eric Seidel wrote: | >> | >> I agree with Joachim that we should have a formal vote on this point. | It's contentious, as syntax always seems to be, so it would be good to get | everyone's opinion on record, even if that opinion is just "2 and 3 both | seem reasonable to me". | >> | >> But, before we vote, it occurs to me that we have three new committee | members (welcome!) who might have comments or questions. Alejandro, Cale, | and Tom, have you been following the discussion so far, or do you need a | summary? I wouldn't blame you, it's been dragging on for a very long | time.. | >> | >>> On Tue, Jan 28, 2020, at 07:12, Joachim Breitner wrote: | >>> I know I know. It matters for what are the names of variables. My | >>> mental parser first looks what are the names (and handles module | >>> prefixes), and then the expression parser runs. At least in my head. | >>> | >>> And module prefixes are not arbitrary expressions (yet…), but the `r` | >>> can be an arbitrary complex expression! | >>> | >>> f (foo bar // baz).r | >>> | >>> vs | >>> | >>> f (foo bar // baz) .r | >>> | >>> would be different under your proposal, but the same under mine. | >>> | >>> But none of this is new to anyone here… why not just vote and get a | decision? | >>> | >>> Cheers, | >>> Joachim | >>> | >>> | >>> Am 28. Januar 2020 12:58:34 MEZ schrieb Simon Peyton Jones | >>> : | >>>> | With function application, no space or space is irrelevant: | >>>> | | >>>> | f r"" = f r "" ≠ f (r "") = f (r "") | >>>> | >>>> But that is not so | >>>> | >>>> f r x ≠ f rx | >>>> f M.x ≠ f M x | >>>> | >>>> White space (or its absence) matters. | >>>> | >>>> Simon | >>>> | >>>> | -----Original Message----- | >>>> | From: ghc-steering-committee | >>>> | >>>> | On Behalf Of Joachim Breitner | >>>> | Sent: 28 January 2020 11:55 | >>>> | To: ghc-steering-committee@haskell.org | >>>> | Subject: Re: [ghc-steering-committee] Record syntax | >>>> | | >>>> | Hi, | >>>> | | >>>> | > Consider (f .x g .y h .z) | >>>> | > | >>>> | > (2) says this means ((((f .x) g) .y) h) .z), so that it | >>>> parenthesises | >>>> | > exactly like function application. | >>>> | > | >>>> | > (3) says it means (((f .x) (g .y)) (h .z)) which, while | >>>> unambiguous, | >>>> | > I dislike cordially. | >>>> | > | >>>> | > I propose to adopt (2). | >>>> | | >>>> | I agree that “exactly like function application” is a great, | simple | >>>> | universal way of explaining the parsing. | >>>> | | >>>> | But I can't stop pointing out that this is inconsistent if we | insist | >>>> | that `f r.x = f (r.x)`. | >>>> | | >>>> | With function application, no space or space is irrelevant: | >>>> | | >>>> | f r"" = f r "" ≠ f (r "") = f (r "") | >>>> | | >>>> | You propose | >>>> | | >>>> | f r.x ≠ f r .x = f (r .x) = f (r .x) | >>>> | | >>>> | while I am still attached to | >>>> | | >>>> | f r.x = f r .x ≠ f (r .x) = f (r .x) | >>>> | | >>>> | I know that this will disappoint a few who want their code to look | >>>> like | >>>> | it does in some other languages (many object oriented langauges, | >>>> | Ocaml), and who do not want to put in the extra parentheses. But | in | >>>> | this case I am leaning towards the elegance of _really_ saying | >>>> “exactly | >>>> | like function application”, not only syntactically, but also | morally | >>>> (a | >>>> | record is a function on a finite set of field names.) | >>>> | I find this very justifiable for a functional programming | language. | >>>> | | >>>> | And I find it very un-haskelly that going from a space to no space | >>>> | between expressions makes a difference (I believe Simon Marlow | >>>> shared | >>>> | this reservation.) | >>>> | | >>>> | | >>>> | If we do insist on “binds more tightly if no space”, then I am | >>>> actually | >>>> | in favor of “also binds more tightly if there is a space”, i.e. | (3) | >>>> | above, to avoid the whitespace-sensitivity. | >>>> | | >>>> | | >>>> | So if it comes to a vote, I think these three options cover all | >>>> | opinions so far? | >>>> | | >>>> | * f r .x = (f r).x; f r.x = f (r.x) -- Simon’s (2) | >>>> | * f r .x = (f r).x; f r.x = (f r).x) -- My take on it | >>>> | * f r .x = f (r.x); f r.x = f (r.x) -- Simon’s (3) | >>>> | | >>>> | Anything else? | >>>> | | >>>> | | >>>> | If we vote, I hope we don't get too many abstinations. Nobody will | >>>> be | >>>> | personally offended if you vote “against” them (I hope), but | >>>> whatever | >>>> | outcome we have better have weight, and is supported by a high | >>>> turnout. | >>>> | | >>>> | | >>>> | And I think we should just vote; we keep rephrasing the same | >>>> arguments | >>>> | with different words. | >>>> | | >>>> | Cheers, | >>>> | Joachim | >>>> | | >>>> | -- | >>>> | Joachim Breitner | >>>> | mail@joachim-breitner.de | >>>> | | >>>> | | >>>> | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joach | >>>> | im- | >>>> | | >>>> | breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C99dc94685bb34e | >>>> | | >>>> | 1f694a08d7a3e8faa2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6371580933 | >>>> | | >>>> | 72311824&sdata=N7iqz4VoL6oe4ICm3JIVVLW%2BBM%2BVIdGOeYa2obcjqdI%3D& | >>>> | reserved=0 | >>>> | | >>>> | | >>>> | _______________________________________________ | >>>> | ghc-steering-committee mailing list | >>>> | ghc-steering-committee@haskell.org | >>>> | | >>>> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.has | >>>> | kell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | >>>> | | >>>> | committee&data=02%7C01%7Csimonpj%40microsoft.com%7C99dc94685bb34e1f694 | >>>> | | >>>> | a08d7a3e8faa2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637158093372311 | >>>> | | >>>> | 824&sdata=AnxNHulQCUqWkKaKYmEXYQMQwl3F1MDPYS64GIAnVhA%3D&reserved= | >>>> | 0 | >>> _______________________________________________ | >>> ghc-steering-committee mailing list | >>> ghc-steering-committee@haskell.org | >>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering- | committee | >>> | >> _______________________________________________ | >> ghc-steering-committee mailing list | >> ghc-steering-committee@haskell.org | >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering- | committee | > _______________________________________________ | > ghc-steering-committee mailing list | > ghc-steering-committee@haskell.org | > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee@haskell.org | https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

-- Chris Allen Currently working on http://haskellbook.com