From mail at joachim-breitner.de  Fri Jan  3 14:20:43 2020
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Fri, 03 Jan 2020 15:20:43 +0100
Subject: [ghc-steering-committee] Please review #303: Constraint based arrow
 notation, Shepherd: Chis Done
Message-ID: <43b1824024f79622e11434d50d49ada8e5c02b38.camel@joachim-breitner.de>

Dear Committee,

this is your secretary speaking:

Constraint based arrow notation
has been proposed by Aleix King
https://github.com/ghc-proposals/ghc-proposals/pull/303
https://github.com/lexi-lambda/ghc-proposals/blob/constraint-based-arrow-notation/proposals/0000-constraint-based-arrow-notation.md

I propose Chris Done as the shepherd.

Please guide us to a conclusion as outlined in 
https://github.com/ghc-proposals/ghc-proposals#committee-process

Thanks,
Joachim
-- 
Joachim “nomeata” Breitner
  mail at joachim-breitner.de
  https://www.joachim-breitner.de/



From mail at joachim-breitner.de  Fri Jan  3 14:28:39 2020
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Fri, 03 Jan 2020 15:28:39 +0100
Subject: [ghc-steering-committee] Request for Nominations to the GHC
 Steering Committee
In-Reply-To: <c5ff9334a703bbad7c68860798686ca27c4921cb.camel@joachim-breitner.de>
References: <c5ff9334a703bbad7c68860798686ca27c4921cb.camel@joachim-breitner.de>
Message-ID: <b0403f3d92b169e71d378179fa3e4f830673da7c.camel@joachim-breitner.de>

Hi,

JFT(public)R: We have received two nominations, which I will distribute
internally and privately now, to begin discussions and voting.

Cheers,
Joachim

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



From mail at joachim-breitner.de  Fri Jan  3 17:30:17 2020
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Fri, 03 Jan 2020 18:30:17 +0100
Subject: [ghc-steering-committee] Please review #303: Constraint based
 arrow notation, Shepherd: Chis Allen
In-Reply-To: <43b1824024f79622e11434d50d49ada8e5c02b38.camel@joachim-breitner.de>
References: <43b1824024f79622e11434d50d49ada8e5c02b38.camel@joachim-breitner.de>
Message-ID: <8b4a5b83cfcf2f1fcbe30ff25dd51ca968a9eedc.camel@joachim-breitner.de>

Of course I mean Chris Allen. Sorry for the confusion.

Am Freitag, den 03.01.2020, 15:20 +0100 schrieb Joachim Breitner:
> Dear Committee,
> 
> this is your secretary speaking:
> 
> Constraint based arrow notation
> has been proposed by Aleix King
> https://github.com/ghc-proposals/ghc-proposals/pull/303
> https://github.com/lexi-lambda/ghc-proposals/blob/constraint-based-arrow-notation/proposals/0000-constraint-based-arrow-notation.md
> 
> I propose Chris Done as the shepherd.
> 
> Please guide us to a conclusion as outlined in 
> https://github.com/ghc-proposals/ghc-proposals#committee-process
> 
> Thanks,
> Joachim
-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/



From cma at bitemyapp.com  Fri Jan  3 17:43:59 2020
From: cma at bitemyapp.com (Christopher Allen)
Date: Fri, 3 Jan 2020 11:43:59 -0600
Subject: [ghc-steering-committee] Please review #303: Constraint based
 arrow notation, Shepherd: Chis Allen
In-Reply-To: <8b4a5b83cfcf2f1fcbe30ff25dd51ca968a9eedc.camel@joachim-breitner.de>
References: <43b1824024f79622e11434d50d49ada8e5c02b38.camel@joachim-breitner.de>
 <8b4a5b83cfcf2f1fcbe30ff25dd51ca968a9eedc.camel@joachim-breitner.de>
Message-ID: <CADnndOrQCfYArtUttoP3W8u0N0JH+b4JEQfotP7ezTJjk+GsOQ@mail.gmail.com>

This is an interesting proposal. The merits of the proposal are one
thing, but it also feels like someone is proposing to renovate an
abandoned corner of GHC. I'll try to weigh these orthogonal benefits
as best I can.

I'll take a deeper look after work.

Cheers,
Chris

On Fri, Jan 3, 2020 at 11:30 AM Joachim Breitner
<mail at joachim-breitner.de> wrote:
>
> Of course I mean Chris Allen. Sorry for the confusion.
>
> Am Freitag, den 03.01.2020, 15:20 +0100 schrieb Joachim Breitner:
> > Dear Committee,
> >
> > this is your secretary speaking:
> >
> > Constraint based arrow notation
> > has been proposed by Aleix King
> > https://github.com/ghc-proposals/ghc-proposals/pull/303
> > https://github.com/lexi-lambda/ghc-proposals/blob/constraint-based-arrow-notation/proposals/0000-constraint-based-arrow-notation.md
> >
> > I propose Chris Done as the shepherd.
> >
> > Please guide us to a conclusion as outlined in
> > https://github.com/ghc-proposals/ghc-proposals#committee-process
> >
> > Thanks,
> > Joachim
> --
> Joachim Breitner
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee



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

From simonpj at microsoft.com  Tue Jan  7 11:29:04 2020
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 7 Jan 2020 11:29:04 +0000
Subject: [ghc-steering-committee] Record syntax
Message-ID: <VI1PR8303MB0093086905AE75AF5B287A89AD3F0@VI1PR8303MB0093.EURPRD83.prod.outlook.com>

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/thread.html#1387>.
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20200107/9a72e878/attachment.html>

From rae at richarde.dev  Tue Jan  7 11:38:46 2020
From: rae at richarde.dev (Richard Eisenberg)
Date: Tue, 7 Jan 2020 11:38:46 +0000
Subject: [ghc-steering-committee] Record syntax
In-Reply-To: <VI1PR8303MB0093086905AE75AF5B287A89AD3F0@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
References: <VI1PR8303MB0093086905AE75AF5B287A89AD3F0@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
Message-ID: <F78DDEF9-4711-48AE-B23C-4C8F16CB0D52@richarde.dev>



> On Jan 7, 2020, at 11:29 AM, Simon Peyton Jones via ghc-steering-committee <ghc-steering-committee at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20200107/14c81da7/attachment.html>

From simonpj at microsoft.com  Tue Jan  7 11:59:41 2020
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 7 Jan 2020 11:59:41 +0000
Subject: [ghc-steering-committee] Record syntax
In-Reply-To: <F78DDEF9-4711-48AE-B23C-4C8F16CB0D52@richarde.dev>
References: <VI1PR8303MB0093086905AE75AF5B287A89AD3F0@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
 <F78DDEF9-4711-48AE-B23C-4C8F16CB0D52@richarde.dev>
Message-ID: <VI1PR8303MB00935DAA1787454062B08E1FAD3F0@VI1PR8303MB0093.EURPRD83.prod.outlook.com>

> 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 <rae at richarde.dev>
Sent: 07 January 2020 11:39
To: Simon Peyton Jones <simonpj at microsoft.com>
Cc: ghc-steering-committee at haskell.org
Subject: Re: [ghc-steering-committee] Record syntax




On Jan 7, 2020, at 11:29 AM, Simon Peyton Jones via ghc-steering-committee <ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20200107/2e6d665f/attachment-0001.html>

From mail at joachim-breitner.de  Tue Jan  7 12:49:51 2020
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 07 Jan 2020 13:49:51 +0100
Subject: [ghc-steering-committee] Record syntax
In-Reply-To: <VI1PR8303MB0093086905AE75AF5B287A89AD3F0@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
References: <VI1PR8303MB0093086905AE75AF5B287A89AD3F0@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
Message-ID: <890c1a90f3f64982cd2b6e6823c70655764fafb0.camel@joachim-breitner.de>

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 at joachim-breitner.de
  http://www.joachim-breitner.de/



From arnaud.spiwack at tweag.io  Tue Jan  7 15:50:31 2020
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Tue, 7 Jan 2020 16:50:31 +0100
Subject: [ghc-steering-committee] Record syntax
In-Reply-To: <890c1a90f3f64982cd2b6e6823c70655764fafb0.camel@joachim-breitner.de>
References: <VI1PR8303MB0093086905AE75AF5B287A89AD3F0@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
 <890c1a90f3f64982cd2b6e6823c70655764fafb0.camel@joachim-breitner.de>
Message-ID: <CAH6fHQnMQ_H6basfaqf+EJYNvDjw8RMD7gnUSaiJhV32PvnirQ@mail.gmail.com>

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 <mail at joachim-breitner.de>
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 at joachim-breitner.de
>   http://www.joachim-breitner.de/
>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20200107/80514cfd/attachment.html>

From marlowsd at gmail.com  Fri Jan 10 09:41:35 2020
From: marlowsd at gmail.com (Simon Marlow)
Date: Fri, 10 Jan 2020 09:41:35 +0000
Subject: [ghc-steering-committee] Record syntax
In-Reply-To: <VI1PR8303MB0093086905AE75AF5B287A89AD3F0@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
References: <VI1PR8303MB0093086905AE75AF5B287A89AD3F0@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
Message-ID: <CANsrgPLbjYfzf174diXgA2GPwSOnVZ1gC7vr+1u+LzjtQhaAhA@mail.gmail.com>

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 <
ghc-steering-committee at haskell.org> 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/thread.html#1387>
> .
> *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 at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20200110/b04a0d8e/attachment.html>

From eric at seidel.io  Fri Jan 10 15:08:43 2020
From: eric at seidel.io (Eric Seidel)
Date: Fri, 10 Jan 2020 10:08:43 -0500
Subject: [ghc-steering-committee] Record syntax
In-Reply-To: <CANsrgPLbjYfzf174diXgA2GPwSOnVZ1gC7vr+1u+LzjtQhaAhA@mail.gmail.com>
References: <VI1PR8303MB0093086905AE75AF5B287A89AD3F0@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
 <CANsrgPLbjYfzf174diXgA2GPwSOnVZ1gC7vr+1u+LzjtQhaAhA@mail.gmail.com>
Message-ID: <dcc777c0-9896-4cab-9247-eddf2ffde5d5@www.fastmail.com>

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 <ghc-steering-committee at haskell.org> 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/thread.html#1387>.____
> 
> > *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 at haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>

From mail at joachim-breitner.de  Fri Jan 10 16:34:39 2020
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Fri, 10 Jan 2020 17:34:39 +0100
Subject: [ghc-steering-committee] Record syntax
In-Reply-To: <dcc777c0-9896-4cab-9247-eddf2ffde5d5@www.fastmail.com>
References: <VI1PR8303MB0093086905AE75AF5B287A89AD3F0@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
 <CANsrgPLbjYfzf174diXgA2GPwSOnVZ1gC7vr+1u+LzjtQhaAhA@mail.gmail.com>
 <dcc777c0-9896-4cab-9247-eddf2ffde5d5@www.fastmail.com>
Message-ID: <819c8605929e5c20f98716d0eea27462b0793b5b.camel@joachim-breitner.de>

Hi,

Am Freitag, den 10.01.2020, 10:08 -0500 schrieb Eric Seidel:
> 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.

Well, or simply records that store functions, some of which return such
records. Think common idioms like explicit dictionaries. Or something
like


   data Automaton a b =
     { val :: a
     , next :: b -> Automaton a b
     }


   print $ a.next "hello"
            .next "word"
            .val

And I am sure our users would find other great use of that features.


But to me, function chaining a nice side-effect of (2).

What I really like about 2 is that that "r .x" can be explained using
function application (it evaluates the record, seen as a function with
a finite set of field names as its domain, by passing it the argument
.f), and by using the same syntax as function application, many
questions about parsing are already answered, in a nicely consistent
way.

Cheers,
Joachim

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



From mail at joachim-breitner.de  Tue Jan 14 13:37:59 2020
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 14 Jan 2020 14:37:59 +0100
Subject: [ghc-steering-committee]  Please review #287: Simplify subsumption,
 Shepherd: Arnaud
Message-ID: <f0dd1af37f6800d7c23a62f093d15d8f84492c84.camel@joachim-breitner.de>

Dear Committee,

this is your secretary speaking:

Simplify subsumption
has been proposed by Simon PJ
https://github.com/ghc-proposals/ghc-proposals/pull/287
https://github.com/ghc-proposals/ghc-proposals/blob/wip/spj-deep-skol/proposals/0000-simplify-subsumption.md

I propose Arnaud Spiwak as the shepherd.

Please guide us to a conclusion as outlined in 
https://github.com/ghc-proposals/ghc-proposals#committee-process

Thanks,
Joachim
-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/



From arnaud.spiwack at tweag.io  Fri Jan 17 13:49:42 2020
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Fri, 17 Jan 2020 14:49:42 +0100
Subject: [ghc-steering-committee] #287: Simplify subsumption ,
	recommendation: accept
Message-ID: <CAH6fHQmfkynT8V1GLWKprmVs6VgThdKniFMdq5PRQUVQ5bVR0g@mail.gmail.com>

Dear all,

As the shepherd for proposal #287 [
https://github.com/ghc-proposals/ghc-proposals/pull/287 ], I recommend
acceptance

Summary

The proposal is to remove a bunch of typing rules meant to make RankNTypes
a bit more powerful (covariance and contravariance of the arrow
constructor, as well as deep instantiation and deep skolemisation). The
problem with these rules is that 1/ they complicate the type checker 2/
They are implemented by performing eta-expansion during elaboration, which
changes the semantics of program 3/ Dropping (some of) them is beneficial
for the quick-look story (proposal currently on hold).

The authors have tried this change on all of Stackage, and could come up
with simple fixes (~300 lines of which) for all but 2 packages (namely,
singleton, because of template haskell stuff, and labels for reason not
well identified).

Rationale

The common point of all these features is that they jiggle the position of
foralls around. Which sounds reasonable at first glance. But really, they
tend to interact badly with other stuff (I don't remember the
circumstances, but there was a discussion of deep instantiation and deep
skolemisation in the context of linear types as well). Basically, they are
rather fragile features, I'd rather we did without them.

I think that 300 lines of simple fixes for all of Stackage is a very small
number. So it is legitimate to consider this change to have low impact.
Regarding the singleton, I'm sure Richard will be happy to fix it ;-) .
Only labels remains. It shouldn't be a blocker.

Remaining question

There is one open question on the pull request thread. Namely, how to
schedule the removal. Two paths are being discussed

   1. Add a `-XLessSubsumption` flag, turn it off by default, then turn it
   on by default in version n+1, then remove the subsumption rules altogether
   in version n+3
   2. Simply remove the code, preferably early in the release cycle,
   communicate profusely.

The thread participants seem to lean towards (2). The reason being that
this is a change where it is easy to write code compatible with previous
versions of the compiler (everything which compiles after this change also
compiles before this change). Also, there is a preference for removing the
relevant code sooner rather than later. But I'd like the opinion of the
committee.

Best,
Arnaud
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20200117/089dea75/attachment.html>

From eric at seidel.io  Fri Jan 17 14:16:11 2020
From: eric at seidel.io (Eric Seidel)
Date: Fri, 17 Jan 2020 09:16:11 -0500
Subject: [ghc-steering-committee]
 =?utf-8?q?=23287=3A_Simplify_subsumption?=
 =?utf-8?q?_=2C=09recommendation=3A_accept?=
In-Reply-To: <CAH6fHQmfkynT8V1GLWKprmVs6VgThdKniFMdq5PRQUVQ5bVR0g@mail.gmail.com>
References: <CAH6fHQmfkynT8V1GLWKprmVs6VgThdKniFMdq5PRQUVQ5bVR0g@mail.gmail.com>
Message-ID: <9447b560-3294-4223-9ba3-85ef948a8028@www.fastmail.com>

I support acceptance as well. Changing the semantics of the program as part of type-checking is just bizarre and it seems like the impact in terms of required code changes is quite limited.

Given how easy the fixes appear to be, and the fact that the fixed program will compile just fine with older GHCs, I'm inclined to support option (2): ripping the code out immediately. I've left a comment on the PR asking if we can do so while providing helpful fixit hints to unaware users.

On Fri, Jan 17, 2020, at 08:49, Spiwack, Arnaud wrote:
> Dear all,
> 
> As the shepherd for proposal #287 [ 
> https://github.com/ghc-proposals/ghc-proposals/pull/287 ], I recommend 
> acceptance
> 
> Summary
> 
> The proposal is to remove a bunch of typing rules meant to make 
> RankNTypes a bit more powerful (covariance and contravariance of the 
> arrow constructor, as well as deep instantiation and deep 
> skolemisation). The problem with these rules is that 1/ they complicate 
> the type checker 2/ They are implemented by performing eta-expansion 
> during elaboration, which changes the semantics of program 3/ Dropping 
> (some of) them is beneficial for the quick-look story (proposal 
> currently on hold).
> 
> The authors have tried this change on all of Stackage, and could come 
> up with simple fixes (~300 lines of which) for all but 2 packages 
> (namely, singleton, because of template haskell stuff, and labels for 
> reason not well identified).
> 
> Rationale
> 
> The common point of all these features is that they jiggle the position 
> of foralls around. Which sounds reasonable at first glance. But really, 
> they tend to interact badly with other stuff (I don't remember the 
> circumstances, but there was a discussion of deep instantiation and 
> deep skolemisation in the context of linear types as well). Basically, 
> they are rather fragile features, I'd rather we did without them.
> 
> I think that 300 lines of simple fixes for all of Stackage is a very 
> small number. So it is legitimate to consider this change to have low 
> impact. Regarding the singleton, I'm sure Richard will be happy to fix 
> it ;-) . Only labels remains. It shouldn't be a blocker.
> 
> Remaining question
> 
> There is one open question on the pull request thread. Namely, how to 
> schedule the removal. Two paths are being discussed
>  1. Add a `-XLessSubsumption` flag, turn it off by default, then turn 
> it on by default in version n+1, then remove the subsumption rules 
> altogether in version n+3
>  2. Simply remove the code, preferably early in the release cycle, 
> communicate profusely.
> The thread participants seem to lean towards (2). The reason being that 
> this is a change where it is easy to write code compatible with 
> previous versions of the compiler (everything which compiles after this 
> change also compiles before this change). Also, there is a preference 
> for removing the relevant code sooner rather than later. But I'd like 
> the opinion of the committee.
> 
> Best,
> Arnaud
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>

From rae at richarde.dev  Fri Jan 17 14:35:40 2020
From: rae at richarde.dev (Richard Eisenberg)
Date: Fri, 17 Jan 2020 14:35:40 +0000
Subject: [ghc-steering-committee] #287: Simplify subsumption ,
	recommendation: accept
In-Reply-To: <9447b560-3294-4223-9ba3-85ef948a8028@www.fastmail.com>
References: <CAH6fHQmfkynT8V1GLWKprmVs6VgThdKniFMdq5PRQUVQ5bVR0g@mail.gmail.com>
 <9447b560-3294-4223-9ba3-85ef948a8028@www.fastmail.com>
Message-ID: <59A05FA1-A2CF-4B16-9651-A7CF0F56A374@richarde.dev>

I'm in support of acceptance and the quick transition strategy. One more bit of rationale: if we didn't have these features and someone proposed them today, we'd shoot them down without much discussion, given the way these features invisibly change the semantics of programs.

Richard

> On Jan 17, 2020, at 2:16 PM, Eric Seidel <eric at seidel.io> wrote:
> 
> I support acceptance as well. Changing the semantics of the program as part of type-checking is just bizarre and it seems like the impact in terms of required code changes is quite limited.
> 
> Given how easy the fixes appear to be, and the fact that the fixed program will compile just fine with older GHCs, I'm inclined to support option (2): ripping the code out immediately. I've left a comment on the PR asking if we can do so while providing helpful fixit hints to unaware users.
> 
> On Fri, Jan 17, 2020, at 08:49, Spiwack, Arnaud wrote:
>> Dear all,
>> 
>> As the shepherd for proposal #287 [ 
>> https://github.com/ghc-proposals/ghc-proposals/pull/287 ], I recommend 
>> acceptance
>> 
>> Summary
>> 
>> The proposal is to remove a bunch of typing rules meant to make 
>> RankNTypes a bit more powerful (covariance and contravariance of the 
>> arrow constructor, as well as deep instantiation and deep 
>> skolemisation). The problem with these rules is that 1/ they complicate 
>> the type checker 2/ They are implemented by performing eta-expansion 
>> during elaboration, which changes the semantics of program 3/ Dropping 
>> (some of) them is beneficial for the quick-look story (proposal 
>> currently on hold).
>> 
>> The authors have tried this change on all of Stackage, and could come 
>> up with simple fixes (~300 lines of which) for all but 2 packages 
>> (namely, singleton, because of template haskell stuff, and labels for 
>> reason not well identified).
>> 
>> Rationale
>> 
>> The common point of all these features is that they jiggle the position 
>> of foralls around. Which sounds reasonable at first glance. But really, 
>> they tend to interact badly with other stuff (I don't remember the 
>> circumstances, but there was a discussion of deep instantiation and 
>> deep skolemisation in the context of linear types as well). Basically, 
>> they are rather fragile features, I'd rather we did without them.
>> 
>> I think that 300 lines of simple fixes for all of Stackage is a very 
>> small number. So it is legitimate to consider this change to have low 
>> impact. Regarding the singleton, I'm sure Richard will be happy to fix 
>> it ;-) . Only labels remains. It shouldn't be a blocker.
>> 
>> Remaining question
>> 
>> There is one open question on the pull request thread. Namely, how to 
>> schedule the removal. Two paths are being discussed
>> 1. Add a `-XLessSubsumption` flag, turn it off by default, then turn 
>> it on by default in version n+1, then remove the subsumption rules 
>> altogether in version n+3
>> 2. Simply remove the code, preferably early in the release cycle, 
>> communicate profusely.
>> The thread participants seem to lean towards (2). The reason being that 
>> this is a change where it is easy to write code compatible with 
>> previous versions of the compiler (everything which compiles after this 
>> change also compiles before this change). Also, there is a preference 
>> for removing the relevant code sooner rather than later. But I'd like 
>> the opinion of the committee.
>> 
>> Best,
>> Arnaud
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
>> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20200117/df8d2afc/attachment-0001.html>

From mail at joachim-breitner.de  Fri Jan 17 16:17:43 2020
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Fri, 17 Jan 2020 17:17:43 +0100
Subject: [ghc-steering-committee] #287: Simplify subsumption ,
	recommendation: accept
In-Reply-To: <9447b560-3294-4223-9ba3-85ef948a8028@www.fastmail.com>
References: <CAH6fHQmfkynT8V1GLWKprmVs6VgThdKniFMdq5PRQUVQ5bVR0g@mail.gmail.com>
 <9447b560-3294-4223-9ba3-85ef948a8028@www.fastmail.com>
Message-ID: <a851527938eccc33728a61d511abfeb1c08f7daa.camel@joachim-breitner.de>

Hi,

I’m with Eric here.

Cheers,
Joachim

Am Freitag, den 17.01.2020, 09:16 -0500 schrieb Eric Seidel:
> I support acceptance as well. Changing the semantics of the program as part of type-checking is just bizarre and it seems like the impact in terms of required code changes is quite limited.
> 
> Given how easy the fixes appear to be, and the fact that the fixed program will compile just fine with older GHCs, I'm inclined to support option (2): ripping the code out immediately. I've left a comment on the PR asking if we can do so while providing helpful fixit hints to unaware users.
> 
> On Fri, Jan 17, 2020, at 08:49, Spiwack, Arnaud wrote:
> > Dear all,
> > 
> > As the shepherd for proposal #287 [ 
> > https://github.com/ghc-proposals/ghc-proposals/pull/287 ], I recommend 
> > acceptance
> > 
> > Summary
> > 
> > The proposal is to remove a bunch of typing rules meant to make 
> > RankNTypes a bit more powerful (covariance and contravariance of the 
> > arrow constructor, as well as deep instantiation and deep 
> > skolemisation). The problem with these rules is that 1/ they complicate 
> > the type checker 2/ They are implemented by performing eta-expansion 
> > during elaboration, which changes the semantics of program 3/ Dropping 
> > (some of) them is beneficial for the quick-look story (proposal 
> > currently on hold).
> > 
> > The authors have tried this change on all of Stackage, and could come 
> > up with simple fixes (~300 lines of which) for all but 2 packages 
> > (namely, singleton, because of template haskell stuff, and labels for 
> > reason not well identified).
> > 
> > Rationale
> > 
> > The common point of all these features is that they jiggle the position 
> > of foralls around. Which sounds reasonable at first glance. But really, 
> > they tend to interact badly with other stuff (I don't remember the 
> > circumstances, but there was a discussion of deep instantiation and 
> > deep skolemisation in the context of linear types as well). Basically, 
> > they are rather fragile features, I'd rather we did without them.
> > 
> > I think that 300 lines of simple fixes for all of Stackage is a very 
> > small number. So it is legitimate to consider this change to have low 
> > impact. Regarding the singleton, I'm sure Richard will be happy to fix 
> > it ;-) . Only labels remains. It shouldn't be a blocker.
> > 
> > Remaining question
> > 
> > There is one open question on the pull request thread. Namely, how to 
> > schedule the removal. Two paths are being discussed
> >  1. Add a `-XLessSubsumption` flag, turn it off by default, then turn 
> > it on by default in version n+1, then remove the subsumption rules 
> > altogether in version n+3
> >  2. Simply remove the code, preferably early in the release cycle, 
> > communicate profusely.
> > The thread participants seem to lean towards (2). The reason being that 
> > this is a change where it is easy to write code compatible with 
> > previous versions of the compiler (everything which compiles after this 
> > change also compiles before this change). Also, there is a preference 
> > for removing the relevant code sooner rather than later. But I'd like 
> > the opinion of the committee.
> > 
> > Best,
> > Arnaud
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> > 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/



From bravit111 at gmail.com  Sat Jan 18 14:59:00 2020
From: bravit111 at gmail.com (Vitaly Bragilevsky)
Date: Sat, 18 Jan 2020 17:59:00 +0300
Subject: [ghc-steering-committee] #287: Simplify subsumption ,
 recommendation: accept
In-Reply-To: <CAH6fHQmfkynT8V1GLWKprmVs6VgThdKniFMdq5PRQUVQ5bVR0g@mail.gmail.com>
References: <CAH6fHQmfkynT8V1GLWKprmVs6VgThdKniFMdq5PRQUVQ5bVR0g@mail.gmail.com>
Message-ID: <CALpVSmOQjOv+PE4qD7qAo8d7B8BZtCmL6M87W1BWh04XRBMM4A@mail.gmail.com>

I'm next to support the acceptance with the quick transition strategy.

Vitaly

пт, 17 янв. 2020 г. в 16:50, Spiwack, Arnaud <arnaud.spiwack at tweag.io>:

> Dear all,
>
> As the shepherd for proposal #287 [
> https://github.com/ghc-proposals/ghc-proposals/pull/287 ], I recommend
> acceptance
>
> Summary
>
> The proposal is to remove a bunch of typing rules meant to make RankNTypes
> a bit more powerful (covariance and contravariance of the arrow
> constructor, as well as deep instantiation and deep skolemisation). The
> problem with these rules is that 1/ they complicate the type checker 2/
> They are implemented by performing eta-expansion during elaboration, which
> changes the semantics of program 3/ Dropping (some of) them is beneficial
> for the quick-look story (proposal currently on hold).
>
> The authors have tried this change on all of Stackage, and could come up
> with simple fixes (~300 lines of which) for all but 2 packages (namely,
> singleton, because of template haskell stuff, and labels for reason not
> well identified).
>
> Rationale
>
> The common point of all these features is that they jiggle the position of
> foralls around. Which sounds reasonable at first glance. But really, they
> tend to interact badly with other stuff (I don't remember the
> circumstances, but there was a discussion of deep instantiation and deep
> skolemisation in the context of linear types as well). Basically, they are
> rather fragile features, I'd rather we did without them.
>
> I think that 300 lines of simple fixes for all of Stackage is a very small
> number. So it is legitimate to consider this change to have low impact.
> Regarding the singleton, I'm sure Richard will be happy to fix it ;-) .
> Only labels remains. It shouldn't be a blocker.
>
> Remaining question
>
> There is one open question on the pull request thread. Namely, how to
> schedule the removal. Two paths are being discussed
>
>    1. Add a `-XLessSubsumption` flag, turn it off by default, then turn
>    it on by default in version n+1, then remove the subsumption rules
>    altogether in version n+3
>    2. Simply remove the code, preferably early in the release cycle,
>    communicate profusely.
>
> The thread participants seem to lean towards (2). The reason being that
> this is a change where it is easy to write code compatible with previous
> versions of the compiler (everything which compiles after this change also
> compiles before this change). Also, there is a preference for removing the
> relevant code sooner rather than later. But I'd like the opinion of the
> committee.
>
> Best,
> Arnaud
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20200118/fb4e8cbf/attachment.html>

From marlowsd at gmail.com  Mon Jan 20 08:37:29 2020
From: marlowsd at gmail.com (Simon Marlow)
Date: Mon, 20 Jan 2020 08:37:29 +0000
Subject: [ghc-steering-committee] #285: -XNoImplicitForAll,
 recommendation: accept
In-Reply-To: <CADRtjwaMa1Kpd8np0bvV=osGN_+Aji=MvryKWO4hV6OfbAxc4A@mail.gmail.com>
References: <33139f4fee8951fed22bc949d9f3e30c2bb752ba.camel@joachim-breitner.de>
 <CANsrgPLJ4HL=kOwcc5Gidu0pdeGZ1z9YJFckSrm-kVvmk12unA@mail.gmail.com>
 <CAH6fHQ=jqbovwGg_ZC3mDF-ErTa7O8QsACYJwq28zbbYA=c80A@mail.gmail.com>
 <CADRtjwaMa1Kpd8np0bvV=osGN_+Aji=MvryKWO4hV6OfbAxc4A@mail.gmail.com>
Message-ID: <CANsrgPKrwPZepq9-oQA7xi9NOTho9tSiCheKzLp23gsebUeL=g@mail.gmail.com>

Dear committee:

Proposal #285 is currently under consideration:
https://github.com/ghc-proposals/ghc-proposals/pull/285

I previously recommended acceptance, and there was some followup discussion
on the GitHub thread where Simon PJ and Arnaud requested changes. The
changes, namely clarifications and more examples, have all been implemented
and those that requested changes have signed off.

I think we can accept the proposal now. Any final concerns?

Cheers
Simon


On Wed, 13 Nov 2019 at 01:18, Sandy Maguire <sandy at sandymaguire.me> wrote:

> I'm largely in agreement with Arnaud here.
>
> On Wed, Nov 13, 2019 at 1:59 AM Spiwack, Arnaud <arnaud.spiwack at tweag.io>
> wrote:
>
>> I've left comments on the Github thread.
>>
>> I'm rather sympathetic to this idea. I personally think that the implicit
>> binding rules that we have in place are a bit messy, so simply turning them
>> off may be of help.
>>
>> My Github comments raise two points:
>>
>> - The proposal is a tad challenging to read, and I'd like some
>> improvements before acceptance be considered
>> - I'm questioning whether we really want two extensions for these two
>> very related behaviours
>>
>> On Mon, Nov 11, 2019 at 10:44 AM Simon Marlow <marlowsd at gmail.com> wrote:
>>
>>> Proposal #285:
>>>
>>> https://github.com/ghc-proposals/ghc-proposals/pull/285
>>>
>>> suggests two new LANGUAGE pragmas -XNoImplicitForall and
>>> -XNoPatternSignatureBinds.
>>>
>>> They have the effect of making a subset of existing programs illegal,
>>> and in that sense I don't think these are problematic. The intention is
>>> that these would be used with ExplicitForalls to enforce that all
>>> identifiers have explicit binding sites. I'm generally supportive of that.
>>>
>>> However I think we should be wary of the potential future direction,
>>> mentioned in the proposal:
>>>
>>> > As described in the motivation, this opens the door to other means to
>>> bind the previously implicitly bound variables.
>>>
>>> i.e. an unbound name in a type could refer to a type variable bound in
>>> an enclosing scope. This would be a language *change*, not merely an
>>> addition or subtraction, and hence potentially fork-like. So we would want
>>> to consider very carefully whether that's the direction we want to take the
>>> language.
>>>
>>> But since that isn't part of the current proposal, and the current
>>> proposal is merely an optional subtraction, I don't think it's
>>> controversial.
>>>
>>> Cheers
>>> Simon
>>>
>>> On Thu, 7 Nov 2019 at 09:29, Joachim Breitner <mail at joachim-breitner.de>
>>> wrote:
>>>
>>>> Dear Committee,
>>>>
>>>> this is your secretary speaking:
>>>>
>>>> -XNoImplicitForAll
>>>> has been proposed by John Ericson
>>>> https://github.com/ghc-proposals/ghc-proposals/pull/285
>>>>
>>>> https://github.com/Ericson2314/ghc-proposals/blob/no-implicit-forall/proposals/0000-no-implicit-forall.rst
>>>>
>>>> I propose Simon Marlow as the shepherd.
>>>>
>>>> Please reach consensus as described in
>>>> https://github.com/ghc-proposals/ghc-proposals#committee-process
>>>> I suggest you make a recommendation, in a new e-mail thread with the
>>>> proposal number in the subject, about the decision, maybe point out
>>>> debatable points, and assume that anyone who stays quiet agrees with
>>>> you.
>>>>
>>>> Thanks,
>>>> Joachim
>>>> --
>>>> Joachim Breitner
>>>>   mail at joachim-breitner.de
>>>>   http://www.joachim-breitner.de/
>>>>
>>>> _______________________________________________
>>>> ghc-steering-committee mailing list
>>>> ghc-steering-committee at haskell.org
>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>>
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at haskell.org
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
>
>
> --
> I'm currently travelling the world, sleeping on people's couches and doing
> full-time collaboration on Haskell projects. If this seems interesting to
> you, please consider signing up as a host!
> https://isovector.github.io/erdos/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20200120/5d82db0f/attachment.html>

From simonpj at microsoft.com  Mon Jan 20 15:46:31 2020
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 20 Jan 2020 15:46:31 +0000
Subject: [ghc-steering-committee] #285: -XNoImplicitForAll,
 recommendation: accept
In-Reply-To: <CANsrgPKrwPZepq9-oQA7xi9NOTho9tSiCheKzLp23gsebUeL=g@mail.gmail.com>
References: <33139f4fee8951fed22bc949d9f3e30c2bb752ba.camel@joachim-breitner.de>
 <CANsrgPLJ4HL=kOwcc5Gidu0pdeGZ1z9YJFckSrm-kVvmk12unA@mail.gmail.com>
 <CAH6fHQ=jqbovwGg_ZC3mDF-ErTa7O8QsACYJwq28zbbYA=c80A@mail.gmail.com>
 <CADRtjwaMa1Kpd8np0bvV=osGN_+Aji=MvryKWO4hV6OfbAxc4A@mail.gmail.com>
 <CANsrgPKrwPZepq9-oQA7xi9NOTho9tSiCheKzLp23gsebUeL=g@mail.gmail.com>
Message-ID: <VI1PR8303MB0093BFB279014B358D24D486AD320@VI1PR8303MB0093.EURPRD83.prod.outlook.com>

I support it.

Simon

From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On Behalf Of Simon Marlow
Sent: 20 January 2020 08:37
To: Sandy Maguire <sandy at sandymaguire.me>
Cc: ghc-steering-committee at haskell.org; Joachim Breitner <mail at joachim-breitner.de>
Subject: Re: [ghc-steering-committee] #285: -XNoImplicitForAll, recommendation: accept

Dear committee:

Proposal #285 is currently under consideration: https://github.com/ghc-proposals/ghc-proposals/pull/285<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F285&data=02%7C01%7Csimonpj%40microsoft.com%7C7b34ece5aaca4bf1061808d79d840b1c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637151062760511549&sdata=viFsM%2FAfs61mWTEzPUkQ48PLfj%2FBEbBoSXOUn1WPkwM%3D&reserved=0>

I previously recommended acceptance, and there was some followup discussion on the GitHub thread where Simon PJ and Arnaud requested changes. The changes, namely clarifications and more examples, have all been implemented and those that requested changes have signed off.

I think we can accept the proposal now. Any final concerns?

Cheers
Simon


On Wed, 13 Nov 2019 at 01:18, Sandy Maguire <sandy at sandymaguire.me<mailto:sandy at sandymaguire.me>> wrote:
I'm largely in agreement with Arnaud here.

On Wed, Nov 13, 2019 at 1:59 AM Spiwack, Arnaud <arnaud.spiwack at tweag.io<mailto:arnaud.spiwack at tweag.io>> wrote:
I've left comments on the Github thread.

I'm rather sympathetic to this idea. I personally think that the implicit binding rules that we have in place are a bit messy, so simply turning them off may be of help.

My Github comments raise two points:

- The proposal is a tad challenging to read, and I'd like some improvements before acceptance be considered
- I'm questioning whether we really want two extensions for these two very related behaviours

On Mon, Nov 11, 2019 at 10:44 AM Simon Marlow <marlowsd at gmail.com<mailto:marlowsd at gmail.com>> wrote:
Proposal #285:

https://github.com/ghc-proposals/ghc-proposals/pull/285<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F285&data=02%7C01%7Csimonpj%40microsoft.com%7C7b34ece5aaca4bf1061808d79d840b1c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637151062760511549&sdata=viFsM%2FAfs61mWTEzPUkQ48PLfj%2FBEbBoSXOUn1WPkwM%3D&reserved=0>

suggests two new LANGUAGE pragmas -XNoImplicitForall and -XNoPatternSignatureBinds.

They have the effect of making a subset of existing programs illegal, and in that sense I don't think these are problematic. The intention is that these would be used with ExplicitForalls to enforce that all identifiers have explicit binding sites. I'm generally supportive of that.

However I think we should be wary of the potential future direction, mentioned in the proposal:

> As described in the motivation, this opens the door to other means to bind the previously implicitly bound variables.

i.e. an unbound name in a type could refer to a type variable bound in an enclosing scope. This would be a language *change*, not merely an addition or subtraction, and hence potentially fork-like. So we would want to consider very carefully whether that's the direction we want to take the language.

But since that isn't part of the current proposal, and the current proposal is merely an optional subtraction, I don't think it's controversial.

Cheers
Simon

On Thu, 7 Nov 2019 at 09:29, Joachim Breitner <mail at joachim-breitner.de<mailto:mail at joachim-breitner.de>> wrote:
Dear Committee,

this is your secretary speaking:

-XNoImplicitForAll
has been proposed by John Ericson
https://github.com/ghc-proposals/ghc-proposals/pull/285<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F285&data=02%7C01%7Csimonpj%40microsoft.com%7C7b34ece5aaca4bf1061808d79d840b1c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637151062760521544&sdata=ejc%2FJIQfLnuiBFjxOIWJlYeO8BeGZXowfE8x7T6zEaY%3D&reserved=0>
https://github.com/Ericson2314/ghc-proposals/blob/no-implicit-forall/proposals/0000-no-implicit-forall.rst<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FEricson2314%2Fghc-proposals%2Fblob%2Fno-implicit-forall%2Fproposals%2F0000-no-implicit-forall.rst&data=02%7C01%7Csimonpj%40microsoft.com%7C7b34ece5aaca4bf1061808d79d840b1c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637151062760521544&sdata=iWi%2Bzg3qDTF6OMdAQS2Hri%2Br9pMjpKLdN4Ua2NpmPwE%3D&reserved=0>

I propose Simon Marlow as the shepherd.

Please reach consensus as described in
https://github.com/ghc-proposals/ghc-proposals#committee-process<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%23committee-process&data=02%7C01%7Csimonpj%40microsoft.com%7C7b34ece5aaca4bf1061808d79d840b1c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637151062760531535&sdata=Gfhz1Ed37fTO9yPAa06MGi0xDwDm0eiHMXuvzKSt%2BhM%3D&reserved=0>
I suggest you make a recommendation, in a new e-mail thread with the
proposal number in the subject, about the decision, maybe point out
debatable points, and assume that anyone who stays quiet agrees with
you.

Thanks,
Joachim
--
Joachim Breitner
  mail at joachim-breitner.de<mailto:mail at joachim-breitner.de>
  http://www.joachim-breitner.de/<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C7b34ece5aaca4bf1061808d79d840b1c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637151062760531535&sdata=9D8Dc0ssSdOJQ%2BZeZDEGdH%2FblHCxGupgA%2FJSdYhufMQ%3D&reserved=0>

_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7C7b34ece5aaca4bf1061808d79d840b1c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637151062760531535&sdata=2a6%2FP1ED6XTXeQo0wZZAVTZtV29uQ9ODX0dBLh%2BvrFo%3D&reserved=0>
_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7C7b34ece5aaca4bf1061808d79d840b1c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637151062760541531&sdata=5%2Foe2KhonSKfa5jPmjVm8%2FCkWtSU5Qom534GWn%2Fb7LA%3D&reserved=0>
_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7C7b34ece5aaca4bf1061808d79d840b1c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637151062760541531&sdata=5%2Foe2KhonSKfa5jPmjVm8%2FCkWtSU5Qom534GWn%2Fb7LA%3D&reserved=0>


--
I'm currently travelling the world, sleeping on people's couches and doing full-time collaboration on Haskell projects. If this seems interesting to you, please consider signing up as a host! https://isovector.github.io/erdos/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fisovector.github.io%2Ferdos%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C7b34ece5aaca4bf1061808d79d840b1c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637151062760551523&sdata=T5V%2FuhomK2C6trPiDNHxA4hb71jX%2BPT9NG%2FCxpEvqjY%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20200120/e1df24e1/attachment-0001.html>

From iavor.diatchki at gmail.com  Mon Jan 20 18:08:32 2020
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Mon, 20 Jan 2020 10:08:32 -0800
Subject: [ghc-steering-committee] #287: Simplify subsumption ,
 recommendation: accept
In-Reply-To: <CAH6fHQmfkynT8V1GLWKprmVs6VgThdKniFMdq5PRQUVQ5bVR0g@mail.gmail.com>
References: <CAH6fHQmfkynT8V1GLWKprmVs6VgThdKniFMdq5PRQUVQ5bVR0g@mail.gmail.com>
Message-ID: <CAGK9nurymCM=a6R5h6zL8XOxuz1q6_1pXYve25ZnR=_=g9NQ4Q@mail.gmail.com>

I am in support

On Fri, Jan 17, 2020, 05:50 Spiwack, Arnaud <arnaud.spiwack at tweag.io> wrote:

> Dear all,
>
> As the shepherd for proposal #287 [
> https://github.com/ghc-proposals/ghc-proposals/pull/287 ], I recommend
> acceptance
>
> Summary
>
> The proposal is to remove a bunch of typing rules meant to make RankNTypes
> a bit more powerful (covariance and contravariance of the arrow
> constructor, as well as deep instantiation and deep skolemisation). The
> problem with these rules is that 1/ they complicate the type checker 2/
> They are implemented by performing eta-expansion during elaboration, which
> changes the semantics of program 3/ Dropping (some of) them is beneficial
> for the quick-look story (proposal currently on hold).
>
> The authors have tried this change on all of Stackage, and could come up
> with simple fixes (~300 lines of which) for all but 2 packages (namely,
> singleton, because of template haskell stuff, and labels for reason not
> well identified).
>
> Rationale
>
> The common point of all these features is that they jiggle the position of
> foralls around. Which sounds reasonable at first glance. But really, they
> tend to interact badly with other stuff (I don't remember the
> circumstances, but there was a discussion of deep instantiation and deep
> skolemisation in the context of linear types as well). Basically, they are
> rather fragile features, I'd rather we did without them.
>
> I think that 300 lines of simple fixes for all of Stackage is a very small
> number. So it is legitimate to consider this change to have low impact.
> Regarding the singleton, I'm sure Richard will be happy to fix it ;-) .
> Only labels remains. It shouldn't be a blocker.
>
> Remaining question
>
> There is one open question on the pull request thread. Namely, how to
> schedule the removal. Two paths are being discussed
>
>    1. Add a `-XLessSubsumption` flag, turn it off by default, then turn
>    it on by default in version n+1, then remove the subsumption rules
>    altogether in version n+3
>    2. Simply remove the code, preferably early in the release cycle,
>    communicate profusely.
>
> The thread participants seem to lean towards (2). The reason being that
> this is a change where it is easy to write code compatible with previous
> versions of the compiler (everything which compiles after this change also
> compiles before this change). Also, there is a preference for removing the
> relevant code sooner rather than later. But I'd like the opinion of the
> committee.
>
> Best,
> Arnaud
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20200120/72c73a6f/attachment.html>

From arnaud.spiwack at tweag.io  Tue Jan 21 07:43:11 2020
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Tue, 21 Jan 2020 08:43:11 +0100
Subject: [ghc-steering-committee] #287: Simplify subsumption ,
 recommendation: accept
In-Reply-To: <CAGK9nurymCM=a6R5h6zL8XOxuz1q6_1pXYve25ZnR=_=g9NQ4Q@mail.gmail.com>
References: <CAH6fHQmfkynT8V1GLWKprmVs6VgThdKniFMdq5PRQUVQ5bVR0g@mail.gmail.com>
 <CAGK9nurymCM=a6R5h6zL8XOxuz1q6_1pXYve25ZnR=_=g9NQ4Q@mail.gmail.com>
Message-ID: <CAH6fHQ=y1Lh9qWbLK2HKK5MksTBazxX-Jj-vqSW5-FL1_BK8Kg@mail.gmail.com>

Support seems unanimous so far. Barring any counter-argument by then, I'll
mark the proposal as accepted, with the short path, on Thursday.

/Arnaud

On Mon, Jan 20, 2020 at 7:08 PM Iavor Diatchki <iavor.diatchki at gmail.com>
wrote:

> I am in support
>
> On Fri, Jan 17, 2020, 05:50 Spiwack, Arnaud <arnaud.spiwack at tweag.io>
> wrote:
>
>> Dear all,
>>
>> As the shepherd for proposal #287 [
>> https://github.com/ghc-proposals/ghc-proposals/pull/287 ], I recommend
>> acceptance
>>
>> Summary
>>
>> The proposal is to remove a bunch of typing rules meant to make
>> RankNTypes a bit more powerful (covariance and contravariance of the arrow
>> constructor, as well as deep instantiation and deep skolemisation). The
>> problem with these rules is that 1/ they complicate the type checker 2/
>> They are implemented by performing eta-expansion during elaboration, which
>> changes the semantics of program 3/ Dropping (some of) them is beneficial
>> for the quick-look story (proposal currently on hold).
>>
>> The authors have tried this change on all of Stackage, and could come up
>> with simple fixes (~300 lines of which) for all but 2 packages (namely,
>> singleton, because of template haskell stuff, and labels for reason not
>> well identified).
>>
>> Rationale
>>
>> The common point of all these features is that they jiggle the position
>> of foralls around. Which sounds reasonable at first glance. But really,
>> they tend to interact badly with other stuff (I don't remember the
>> circumstances, but there was a discussion of deep instantiation and deep
>> skolemisation in the context of linear types as well). Basically, they are
>> rather fragile features, I'd rather we did without them.
>>
>> I think that 300 lines of simple fixes for all of Stackage is a very
>> small number. So it is legitimate to consider this change to have low
>> impact. Regarding the singleton, I'm sure Richard will be happy to fix it
>> ;-) . Only labels remains. It shouldn't be a blocker.
>>
>> Remaining question
>>
>> There is one open question on the pull request thread. Namely, how to
>> schedule the removal. Two paths are being discussed
>>
>>    1. Add a `-XLessSubsumption` flag, turn it off by default, then turn
>>    it on by default in version n+1, then remove the subsumption rules
>>    altogether in version n+3
>>    2. Simply remove the code, preferably early in the release cycle,
>>    communicate profusely.
>>
>> The thread participants seem to lean towards (2). The reason being that
>> this is a change where it is easy to write code compatible with previous
>> versions of the compiler (everything which compiles after this change also
>> compiles before this change). Also, there is a preference for removing the
>> relevant code sooner rather than later. But I'd like the opinion of the
>> committee.
>>
>> Best,
>> Arnaud
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20200121/ca19a54b/attachment.html>

From arnaud.spiwack at tweag.io  Tue Jan 21 07:48:39 2020
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Tue, 21 Jan 2020 08:48:39 +0100
Subject: [ghc-steering-committee] #285: -XNoImplicitForAll,
 recommendation: accept
In-Reply-To: <VI1PR8303MB0093BFB279014B358D24D486AD320@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
References: <33139f4fee8951fed22bc949d9f3e30c2bb752ba.camel@joachim-breitner.de>
 <CANsrgPLJ4HL=kOwcc5Gidu0pdeGZ1z9YJFckSrm-kVvmk12unA@mail.gmail.com>
 <CAH6fHQ=jqbovwGg_ZC3mDF-ErTa7O8QsACYJwq28zbbYA=c80A@mail.gmail.com>
 <CADRtjwaMa1Kpd8np0bvV=osGN_+Aji=MvryKWO4hV6OfbAxc4A@mail.gmail.com>
 <CANsrgPKrwPZepq9-oQA7xi9NOTho9tSiCheKzLp23gsebUeL=g@mail.gmail.com>
 <VI1PR8303MB0093BFB279014B358D24D486AD320@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
Message-ID: <CAH6fHQkeNibjyjL16pN3FF6F_oPmRLLfsqaQH98gB5qXR98Mfw@mail.gmail.com>

I'm still not convinced about the fact that there are two extensions for
this. Which seems more motivated by technical details of the
implementation, rather than by semantics. But it is not a hill that I'm
willing to die on… so if I'm alone in this, I'm not going to argue further.

/Arnaud

On Mon, Jan 20, 2020 at 4:46 PM Simon Peyton Jones via
ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:

> I support it.
>
>
> Simon
>
>
>
> *From:* ghc-steering-committee <ghc-steering-committee-bounces at haskell.org>
> *On Behalf Of *Simon Marlow
> *Sent:* 20 January 2020 08:37
> *To:* Sandy Maguire <sandy at sandymaguire.me>
> *Cc:* ghc-steering-committee at haskell.org; Joachim Breitner <
> mail at joachim-breitner.de>
> *Subject:* Re: [ghc-steering-committee] #285: -XNoImplicitForAll,
> recommendation: accept
>
>
>
> Dear committee:
>
>
>
> Proposal #285 is currently under consideration:
> https://github.com/ghc-proposals/ghc-proposals/pull/285
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F285&data=02%7C01%7Csimonpj%40microsoft.com%7C7b34ece5aaca4bf1061808d79d840b1c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637151062760511549&sdata=viFsM%2FAfs61mWTEzPUkQ48PLfj%2FBEbBoSXOUn1WPkwM%3D&reserved=0>
>
>
>
> I previously recommended acceptance, and there was some followup
> discussion on the GitHub thread where Simon PJ and Arnaud requested
> changes. The changes, namely clarifications and more examples, have all
> been implemented and those that requested changes have signed off.
>
>
>
> I think we can accept the proposal now. Any final concerns?
>
>
>
> Cheers
>
> Simon
>
>
>
>
>
> On Wed, 13 Nov 2019 at 01:18, Sandy Maguire <sandy at sandymaguire.me> wrote:
>
> I'm largely in agreement with Arnaud here.
>
>
>
> On Wed, Nov 13, 2019 at 1:59 AM Spiwack, Arnaud <arnaud.spiwack at tweag.io>
> wrote:
>
> I've left comments on the Github thread.
>
>
>
> I'm rather sympathetic to this idea. I personally think that the implicit
> binding rules that we have in place are a bit messy, so simply turning them
> off may be of help.
>
>
>
> My Github comments raise two points:
>
>
>
> - The proposal is a tad challenging to read, and I'd like some
> improvements before acceptance be considered
>
> - I'm questioning whether we really want two extensions for these two very
> related behaviours
>
>
>
> On Mon, Nov 11, 2019 at 10:44 AM Simon Marlow <marlowsd at gmail.com> wrote:
>
> Proposal #285:
>
>
>
> https://github.com/ghc-proposals/ghc-proposals/pull/285
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F285&data=02%7C01%7Csimonpj%40microsoft.com%7C7b34ece5aaca4bf1061808d79d840b1c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637151062760511549&sdata=viFsM%2FAfs61mWTEzPUkQ48PLfj%2FBEbBoSXOUn1WPkwM%3D&reserved=0>
>
>
>
> suggests two new LANGUAGE pragmas -XNoImplicitForall and
> -XNoPatternSignatureBinds.
>
>
>
> They have the effect of making a subset of existing programs illegal, and
> in that sense I don't think these are problematic. The intention is that
> these would be used with ExplicitForalls to enforce that all identifiers
> have explicit binding sites. I'm generally supportive of that.
>
>
>
> However I think we should be wary of the potential future direction,
> mentioned in the proposal:
>
>
>
> > As described in the motivation, this opens the door to other means to
> bind the previously implicitly bound variables.
>
>
>
> i.e. an unbound name in a type could refer to a type variable bound in an
> enclosing scope. This would be a language *change*, not merely an addition
> or subtraction, and hence potentially fork-like. So we would want to
> consider very carefully whether that's the direction we want to take the
> language.
>
>
>
> But since that isn't part of the current proposal, and the current
> proposal is merely an optional subtraction, I don't think it's
> controversial.
>
>
>
> Cheers
>
> Simon
>
>
>
> On Thu, 7 Nov 2019 at 09:29, Joachim Breitner <mail at joachim-breitner.de>
> wrote:
>
> Dear Committee,
>
> this is your secretary speaking:
>
> -XNoImplicitForAll
> has been proposed by John Ericson
> https://github.com/ghc-proposals/ghc-proposals/pull/285
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F285&data=02%7C01%7Csimonpj%40microsoft.com%7C7b34ece5aaca4bf1061808d79d840b1c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637151062760521544&sdata=ejc%2FJIQfLnuiBFjxOIWJlYeO8BeGZXowfE8x7T6zEaY%3D&reserved=0>
>
> https://github.com/Ericson2314/ghc-proposals/blob/no-implicit-forall/proposals/0000-no-implicit-forall.rst
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FEricson2314%2Fghc-proposals%2Fblob%2Fno-implicit-forall%2Fproposals%2F0000-no-implicit-forall.rst&data=02%7C01%7Csimonpj%40microsoft.com%7C7b34ece5aaca4bf1061808d79d840b1c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637151062760521544&sdata=iWi%2Bzg3qDTF6OMdAQS2Hri%2Br9pMjpKLdN4Ua2NpmPwE%3D&reserved=0>
>
> I propose Simon Marlow as the shepherd.
>
> Please reach consensus as described in
> https://github.com/ghc-proposals/ghc-proposals#committee-process
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%23committee-process&data=02%7C01%7Csimonpj%40microsoft.com%7C7b34ece5aaca4bf1061808d79d840b1c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637151062760531535&sdata=Gfhz1Ed37fTO9yPAa06MGi0xDwDm0eiHMXuvzKSt%2BhM%3D&reserved=0>
> I suggest you make a recommendation, in a new e-mail thread with the
> proposal number in the subject, about the decision, maybe point out
> debatable points, and assume that anyone who stays quiet agrees with
> you.
>
> Thanks,
> Joachim
> --
> Joachim Breitner
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C7b34ece5aaca4bf1061808d79d840b1c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637151062760531535&sdata=9D8Dc0ssSdOJQ%2BZeZDEGdH%2FblHCxGupgA%2FJSdYhufMQ%3D&reserved=0>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7C7b34ece5aaca4bf1061808d79d840b1c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637151062760531535&sdata=2a6%2FP1ED6XTXeQo0wZZAVTZtV29uQ9ODX0dBLh%2BvrFo%3D&reserved=0>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7C7b34ece5aaca4bf1061808d79d840b1c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637151062760541531&sdata=5%2Foe2KhonSKfa5jPmjVm8%2FCkWtSU5Qom534GWn%2Fb7LA%3D&reserved=0>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7C7b34ece5aaca4bf1061808d79d840b1c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637151062760541531&sdata=5%2Foe2KhonSKfa5jPmjVm8%2FCkWtSU5Qom534GWn%2Fb7LA%3D&reserved=0>
>
>
>
> --
>
> I'm currently travelling the world, sleeping on people's couches and doing
> full-time collaboration on Haskell projects. If this seems interesting to
> you, please consider signing up as a host!
> https://isovector.github.io/erdos/
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fisovector.github.io%2Ferdos%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C7b34ece5aaca4bf1061808d79d840b1c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637151062760551523&sdata=T5V%2FuhomK2C6trPiDNHxA4hb71jX%2BPT9NG%2FCxpEvqjY%3D&reserved=0>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20200121/bc9027f0/attachment-0001.html>

From arnaud.spiwack at tweag.io  Thu Jan 23 17:13:25 2020
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Thu, 23 Jan 2020 18:13:25 +0100
Subject: [ghc-steering-committee] #287: Simplify subsumption ,
 recommendation: accept
In-Reply-To: <CAH6fHQ=y1Lh9qWbLK2HKK5MksTBazxX-Jj-vqSW5-FL1_BK8Kg@mail.gmail.com>
References: <CAH6fHQmfkynT8V1GLWKprmVs6VgThdKniFMdq5PRQUVQ5bVR0g@mail.gmail.com>
 <CAGK9nurymCM=a6R5h6zL8XOxuz1q6_1pXYve25ZnR=_=g9NQ4Q@mail.gmail.com>
 <CAH6fHQ=y1Lh9qWbLK2HKK5MksTBazxX-Jj-vqSW5-FL1_BK8Kg@mail.gmail.com>
Message-ID: <CAH6fHQm36HBJkX1pWSmjNDr0F2Ag4ZjzWStPKE=5TMBvGtNobg@mail.gmail.com>

I've now marked the proposal as accepted.

On Tue, Jan 21, 2020 at 8:43 AM Spiwack, Arnaud <arnaud.spiwack at tweag.io>
wrote:

> Support seems unanimous so far. Barring any counter-argument by then, I'll
> mark the proposal as accepted, with the short path, on Thursday.
>
> /Arnaud
>
> On Mon, Jan 20, 2020 at 7:08 PM Iavor Diatchki <iavor.diatchki at gmail.com>
> wrote:
>
>> I am in support
>>
>> On Fri, Jan 17, 2020, 05:50 Spiwack, Arnaud <arnaud.spiwack at tweag.io>
>> wrote:
>>
>>> Dear all,
>>>
>>> As the shepherd for proposal #287 [
>>> https://github.com/ghc-proposals/ghc-proposals/pull/287 ], I recommend
>>> acceptance
>>>
>>> Summary
>>>
>>> The proposal is to remove a bunch of typing rules meant to make
>>> RankNTypes a bit more powerful (covariance and contravariance of the arrow
>>> constructor, as well as deep instantiation and deep skolemisation). The
>>> problem with these rules is that 1/ they complicate the type checker 2/
>>> They are implemented by performing eta-expansion during elaboration, which
>>> changes the semantics of program 3/ Dropping (some of) them is beneficial
>>> for the quick-look story (proposal currently on hold).
>>>
>>> The authors have tried this change on all of Stackage, and could come up
>>> with simple fixes (~300 lines of which) for all but 2 packages (namely,
>>> singleton, because of template haskell stuff, and labels for reason not
>>> well identified).
>>>
>>> Rationale
>>>
>>> The common point of all these features is that they jiggle the position
>>> of foralls around. Which sounds reasonable at first glance. But really,
>>> they tend to interact badly with other stuff (I don't remember the
>>> circumstances, but there was a discussion of deep instantiation and deep
>>> skolemisation in the context of linear types as well). Basically, they are
>>> rather fragile features, I'd rather we did without them.
>>>
>>> I think that 300 lines of simple fixes for all of Stackage is a very
>>> small number. So it is legitimate to consider this change to have low
>>> impact. Regarding the singleton, I'm sure Richard will be happy to fix it
>>> ;-) . Only labels remains. It shouldn't be a blocker.
>>>
>>> Remaining question
>>>
>>> There is one open question on the pull request thread. Namely, how to
>>> schedule the removal. Two paths are being discussed
>>>
>>>    1. Add a `-XLessSubsumption` flag, turn it off by default, then turn
>>>    it on by default in version n+1, then remove the subsumption rules
>>>    altogether in version n+3
>>>    2. Simply remove the code, preferably early in the release cycle,
>>>    communicate profusely.
>>>
>>> The thread participants seem to lean towards (2). The reason being that
>>> this is a change where it is easy to write code compatible with previous
>>> versions of the compiler (everything which compiles after this change also
>>> compiles before this change). Also, there is a preference for removing the
>>> relevant code sooner rather than later. But I'd like the opinion of the
>>> committee.
>>>
>>> Best,
>>> Arnaud
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at haskell.org
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20200123/a7a6b089/attachment.html>

From mail at joachim-breitner.de  Fri Jan 24 15:31:51 2020
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Fri, 24 Jan 2020 16:31:51 +0100
Subject: [ghc-steering-committee] The GHC Committee welcomes its new members
Message-ID: <ca1d78d9858037afb63b20ef539e1d4411bec8c3.camel@joachim-breitner.de>

Dear Haskell community,

the GHC Steering committee welcomes three new members, 

Alejandro Serrano Mena, Cale Gibbard and Tom Harding.

We are happy to see that there is continued interest in our work, and
are looking forward to having fresh insights and energy on the
committee.

They take the seat of Sandy Maguire, who we thank for this productive
work during his tenure.

As you might notice, we picked more candidates than we filled slots.
This is not because Sandy’s productivity need three people to fill. The
idea is that there is no reason to turn away a motivated contributor
just to stick to the arbitrary 10 members. Instead, we will aim at
“roughly 10”, and probably not call for new members until we have
dropped below that number again.


On behalf of the committee,
Joachim Breitner

PS: Alejandro, Cale and Tom, please send me your github handles and 
subscribe to the mailing list at
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

-- 
Joachim “nomeata” Breitner
  mail at joachim-breitner.de
  https://www.joachim-breitner.de/



From simonpj at microsoft.com  Tue Jan 28 11:07:18 2020
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 28 Jan 2020 11:07:18 +0000
Subject: [ghc-steering-committee] Record syntax
In-Reply-To: <VI1PR8303MB0093086905AE75AF5B287A89AD3F0@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
References: <VI1PR8303MB0093086905AE75AF5B287A89AD3F0@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
Message-ID: <VI1PR8303MB009340F27A36A5B7F09C2896AD0A0@VI1PR8303MB0093.EURPRD83.prod.outlook.com>

Friends
Sorry for dragging my feet here.
Only Joachim, Arnaud, Simon, and Eric responded to my message below.   If that means that the rest of you don't mind either way, that's fine. But if you have an opinion, please say so in the next 24 hrs.
No one seems keen on (1).
Everyone seems on the fence between (2) and (3).
Personally I prefer (2) over (3).  I'm very uncomfortable about an infix white-space operator that binds more tightly than function application.  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).  We can vote if need be, but I'd like to hear from anyone who thinks that's a wrong choice.  Clearly it's a judgement call.
Simon

From: Simon Peyton Jones <simonpj at microsoft.com>
Sent: 07 January 2020 11:29
To: ghc-steering-committee at haskell.org
Cc: Simon Peyton Jones <simonpj at microsoft.com>
Subject: Record syntax

Friends
I'd like to move our record-syntax discussion forward.  Link to proposal discussion<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F282&data=02%7C01%7Csimonpj%40microsoft.com%7Ca982a7a9c68f4a7b4a3808d79364cd25%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637139933453096241&sdata=ITgdpzLSfuPL9ZlqoPt6NQpiPNlXcJGRIkgBLkRD4hE%3D&reserved=0>, and December GHC steering committee debates<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fpipermail%2Fghc-steering-committee%2F2019-December%2Fthread.html%231387&data=02%7C01%7Csimonpj%40microsoft.com%7Ca982a7a9c68f4a7b4a3808d79364cd25%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637139933453106239&sdata=okRmErY9Rw0Y2tY4pPXPyuZtOCwj%2FG8BMqz9sxPtNOA%3D&reserved=0>.
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20200128/d12f883c/attachment.html>

From rae at richarde.dev  Tue Jan 28 11:24:01 2020
From: rae at richarde.dev (Richard Eisenberg)
Date: Tue, 28 Jan 2020 11:24:01 +0000
Subject: [ghc-steering-committee] Record syntax
In-Reply-To: <VI1PR8303MB009340F27A36A5B7F09C2896AD0A0@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
References: <VI1PR8303MB0093086905AE75AF5B287A89AD3F0@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
 <VI1PR8303MB009340F27A36A5B7F09C2896AD0A0@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
Message-ID: <DB59A0DC-E36E-407E-8491-0256D48F0200@richarde.dev>

I abstain, as I don't have a strong enough opinion to vote. Happy to have others decide.

Richard

> On Jan 28, 2020, at 11:07 AM, Simon Peyton Jones via ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:
> 
> Friends
> 
> Sorry for dragging my feet here.   
> 
> Only Joachim, Arnaud, Simon, and Eric responded to my message below.   If that means that the rest of you don’t mind either way, that’s fine. But if you have an opinion, please say so in the next 24 hrs.
> 
> No one seems keen on (1).
> 
> Everyone seems on the fence between (2) and (3).
> 
> Personally I prefer (2) over (3).  I’m very uncomfortable about an infix white-space operator that binds more tightly than function application.  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).  We can vote if need be, but I’d like to hear from anyone who thinks that’s a wrong choice.  Clearly it’s a judgement call.
> 
> Simon
> 
>  
> 
> From: Simon Peyton Jones <simonpj at microsoft.com> 
> Sent: 07 January 2020 11:29
> To: ghc-steering-committee at haskell.org
> Cc: Simon Peyton Jones <simonpj at microsoft.com>
> Subject: Record syntax
>  
> 
> Friends
> 
> I’d like to move our record-syntax discussion forward.  Link to proposal discussion <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F282&data=02%7C01%7Csimonpj%40microsoft.com%7Ca982a7a9c68f4a7b4a3808d79364cd25%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637139933453096241&sdata=ITgdpzLSfuPL9ZlqoPt6NQpiPNlXcJGRIkgBLkRD4hE%3D&reserved=0>, and December GHC steering committee debates <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fpipermail%2Fghc-steering-committee%2F2019-December%2Fthread.html%231387&data=02%7C01%7Csimonpj%40microsoft.com%7Ca982a7a9c68f4a7b4a3808d79364cd25%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637139933453106239&sdata=okRmErY9Rw0Y2tY4pPXPyuZtOCwj%2FG8BMqz9sxPtNOA%3D&reserved=0>.
> 
> 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:
> 
> It’s simply illegal.   This defers the choice;  perhaps later we will have more experience to go on.
> 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
> 
> 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 at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20200128/6279b2f6/attachment-0001.html>

From mail at joachim-breitner.de  Tue Jan 28 11:55:12 2020
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 28 Jan 2020 12:55:12 +0100
Subject: [ghc-steering-committee] Record syntax
In-Reply-To: <VI1PR8303MB009340F27A36A5B7F09C2896AD0A0@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
References: <VI1PR8303MB0093086905AE75AF5B287A89AD3F0@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
 <VI1PR8303MB009340F27A36A5B7F09C2896AD0A0@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
Message-ID: <2554645fa01b0a80f159fcc640bd016f1554e013.camel@joachim-breitner.de>

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 at joachim-breitner.de
  http://www.joachim-breitner.de/



From simonpj at microsoft.com  Tue Jan 28 11:58:34 2020
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 28 Jan 2020 11:58:34 +0000
Subject: [ghc-steering-committee] Record syntax
In-Reply-To: <2554645fa01b0a80f159fcc640bd016f1554e013.camel@joachim-breitner.de>
References: <VI1PR8303MB0093086905AE75AF5B287A89AD3F0@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
 <VI1PR8303MB009340F27A36A5B7F09C2896AD0A0@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
 <2554645fa01b0a80f159fcc640bd016f1554e013.camel@joachim-breitner.de>
Message-ID: <VI1PR8303MB00930101C8BAF9ADFF6BFF3FAD0A0@VI1PR8303MB0093.EURPRD83.prod.outlook.com>

|  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 <ghc-steering-committee-bounces at haskell.org>
|  On Behalf Of Joachim Breitner
|  Sent: 28 January 2020 11:55
|  To: ghc-steering-committee at 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 at joachim-breitner.de
|  
|  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joach
|  im-
|  breitner.de%2F&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C99dc94685bb34e
|  1f694a08d7a3e8faa2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6371580933
|  72311824&amp;sdata=N7iqz4VoL6oe4ICm3JIVVLW%2BBM%2BVIdGOeYa2obcjqdI%3D&amp;
|  reserved=0
|  
|  
|  _______________________________________________
|  ghc-steering-committee mailing list
|  ghc-steering-committee at haskell.org
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.has
|  kell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
|  committee&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C99dc94685bb34e1f694
|  a08d7a3e8faa2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637158093372311
|  824&amp;sdata=AnxNHulQCUqWkKaKYmEXYQMQwl3F1MDPYS64GIAnVhA%3D&amp;reserved=
|  0

From mail at joachim-breitner.de  Tue Jan 28 12:12:41 2020
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 28 Jan 2020 13:12:41 +0100
Subject: [ghc-steering-committee] Record syntax
In-Reply-To: <VI1PR8303MB00930101C8BAF9ADFF6BFF3FAD0A0@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
References: <VI1PR8303MB0093086905AE75AF5B287A89AD3F0@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
 <VI1PR8303MB009340F27A36A5B7F09C2896AD0A0@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
 <2554645fa01b0a80f159fcc640bd016f1554e013.camel@joachim-breitner.de>
 <VI1PR8303MB00930101C8BAF9ADFF6BFF3FAD0A0@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
Message-ID: <2A9B70E6-3FE3-4BBB-AED2-98F0CBBB0577@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 <simonpj at microsoft.com>:
>|  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
><ghc-steering-committee-bounces at haskell.org>
>|  On Behalf Of Joachim Breitner
>|  Sent: 28 January 2020 11:55
>|  To: ghc-steering-committee at 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 at joachim-breitner.de
>|  
>| 
>https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joach
>|  im-
>| 
>breitner.de%2F&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C99dc94685bb34e
>| 
>1f694a08d7a3e8faa2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6371580933
>| 
>72311824&amp;sdata=N7iqz4VoL6oe4ICm3JIVVLW%2BBM%2BVIdGOeYa2obcjqdI%3D&amp;
>|  reserved=0
>|  
>|  
>|  _______________________________________________
>|  ghc-steering-committee mailing list
>|  ghc-steering-committee at haskell.org
>| 
>https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.has
>|  kell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
>| 
>committee&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C99dc94685bb34e1f694
>| 
>a08d7a3e8faa2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637158093372311
>| 
>824&amp;sdata=AnxNHulQCUqWkKaKYmEXYQMQwl3F1MDPYS64GIAnVhA%3D&amp;reserved=
>|  0

From eric at seidel.io  Tue Jan 28 13:58:19 2020
From: eric at seidel.io (Eric Seidel)
Date: Tue, 28 Jan 2020 08:58:19 -0500
Subject: [ghc-steering-committee] Record syntax
In-Reply-To: <2A9B70E6-3FE3-4BBB-AED2-98F0CBBB0577@joachim-breitner.de>
References: <VI1PR8303MB0093086905AE75AF5B287A89AD3F0@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
 <VI1PR8303MB009340F27A36A5B7F09C2896AD0A0@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
 <2554645fa01b0a80f159fcc640bd016f1554e013.camel@joachim-breitner.de>
 <VI1PR8303MB00930101C8BAF9ADFF6BFF3FAD0A0@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
 <2A9B70E6-3FE3-4BBB-AED2-98F0CBBB0577@joachim-breitner.de>
Message-ID: <316820b7-8b2c-4d72-beed-941dd503ac23@www.fastmail.com>

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 
> <simonpj at microsoft.com>:
> >|  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
> ><ghc-steering-committee-bounces at haskell.org>
> >|  On Behalf Of Joachim Breitner
> >|  Sent: 28 January 2020 11:55
> >|  To: ghc-steering-committee at 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 at joachim-breitner.de
> >|  
> >| 
> >https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joach
> >|  im-
> >| 
> >breitner.de%2F&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C99dc94685bb34e
> >| 
> >1f694a08d7a3e8faa2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6371580933
> >| 
> >72311824&amp;sdata=N7iqz4VoL6oe4ICm3JIVVLW%2BBM%2BVIdGOeYa2obcjqdI%3D&amp;
> >|  reserved=0
> >|  
> >|  
> >|  _______________________________________________
> >|  ghc-steering-committee mailing list
> >|  ghc-steering-committee at haskell.org
> >| 
> >https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.has
> >|  kell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
> >| 
> >committee&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C99dc94685bb34e1f694
> >| 
> >a08d7a3e8faa2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637158093372311
> >| 
> >824&amp;sdata=AnxNHulQCUqWkKaKYmEXYQMQwl3F1MDPYS64GIAnVhA%3D&amp;reserved=
> >|  0
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>

From cgibbard at gmail.com  Tue Jan 28 14:04:17 2020
From: cgibbard at gmail.com (Cale Gibbard)
Date: Tue, 28 Jan 2020 09:04:17 -0500
Subject: [ghc-steering-committee] Record syntax
In-Reply-To: <316820b7-8b2c-4d72-beed-941dd503ac23@www.fastmail.com>
References: <VI1PR8303MB0093086905AE75AF5B287A89AD3F0@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
 <VI1PR8303MB009340F27A36A5B7F09C2896AD0A0@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
 <2554645fa01b0a80f159fcc640bd016f1554e013.camel@joachim-breitner.de>
 <VI1PR8303MB00930101C8BAF9ADFF6BFF3FAD0A0@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
 <2A9B70E6-3FE3-4BBB-AED2-98F0CBBB0577@joachim-breitner.de>
 <316820b7-8b2c-4d72-beed-941dd503ac23@www.fastmail.com>
Message-ID: <CAF3RzK8aVRUWT=P8pjnr6R=m+RfjekmuoGgnNCd2NGKsoALGpQ@mail.gmail.com>

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 <eric at seidel.io> 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
> > <simonpj at microsoft.com>:
> > >|  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
> > ><ghc-steering-committee-bounces at haskell.org>
> > >|  On Behalf Of Joachim Breitner
> > >|  Sent: 28 January 2020 11:55
> > >|  To: ghc-steering-committee at 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 at joachim-breitner.de
> > >|
> > >|
> > >https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joach
> > >|  im-
> > >|
> > >breitner.de%2F&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C99dc94685bb34e
> > >|
> > >1f694a08d7a3e8faa2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6371580933
> > >|
> > >72311824&amp;sdata=N7iqz4VoL6oe4ICm3JIVVLW%2BBM%2BVIdGOeYa2obcjqdI%3D&amp;
> > >|  reserved=0
> > >|
> > >|
> > >|  _______________________________________________
> > >|  ghc-steering-committee mailing list
> > >|  ghc-steering-committee at haskell.org
> > >|
> > >https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.has
> > >|  kell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
> > >|
> > >committee&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C99dc94685bb34e1f694
> > >|
> > >a08d7a3e8faa2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637158093372311
> > >|
> > >824&amp;sdata=AnxNHulQCUqWkKaKYmEXYQMQwl3F1MDPYS64GIAnVhA%3D&amp;reserved=
> > >|  0
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> >
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

From cma at bitemyapp.com  Tue Jan 28 14:18:11 2020
From: cma at bitemyapp.com (Christopher Allen)
Date: Tue, 28 Jan 2020 08:18:11 -0600
Subject: [ghc-steering-committee] Record syntax
In-Reply-To: <CAF3RzK8aVRUWT=P8pjnr6R=m+RfjekmuoGgnNCd2NGKsoALGpQ@mail.gmail.com>
References: <CAF3RzK8aVRUWT=P8pjnr6R=m+RfjekmuoGgnNCd2NGKsoALGpQ@mail.gmail.com>
Message-ID: <396D32D8-3BE8-4E66-BCF1-01B04F7C2B53@bitemyapp.com>

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 <cgibbard at gmail.com> 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 <eric at seidel.io> 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
>>> <simonpj at microsoft.com>:
>>>> |  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
>>>> <ghc-steering-committee-bounces at haskell.org>
>>>> |  On Behalf Of Joachim Breitner
>>>> |  Sent: 28 January 2020 11:55
>>>> |  To: ghc-steering-committee at 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 at joachim-breitner.de
>>>> |
>>>> |
>>>> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joach
>>>> |  im-
>>>> |
>>>> breitner.de%2F&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C99dc94685bb34e
>>>> |
>>>> 1f694a08d7a3e8faa2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6371580933
>>>> |
>>>> 72311824&amp;sdata=N7iqz4VoL6oe4ICm3JIVVLW%2BBM%2BVIdGOeYa2obcjqdI%3D&amp;
>>>> |  reserved=0
>>>> |
>>>> |
>>>> |  _______________________________________________
>>>> |  ghc-steering-committee mailing list
>>>> |  ghc-steering-committee at haskell.org
>>>> |
>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.has
>>>> |  kell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
>>>> |
>>>> committee&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C99dc94685bb34e1f694
>>>> |
>>>> a08d7a3e8faa2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637158093372311
>>>> |
>>>> 824&amp;sdata=AnxNHulQCUqWkKaKYmEXYQMQwl3F1MDPYS64GIAnVhA%3D&amp;reserved=
>>>> |  0
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at haskell.org
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>> 
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

From cgibbard at gmail.com  Tue Jan 28 14:21:10 2020
From: cgibbard at gmail.com (Cale Gibbard)
Date: Tue, 28 Jan 2020 09:21:10 -0500
Subject: [ghc-steering-committee] Record syntax
In-Reply-To: <CAF3RzK8aVRUWT=P8pjnr6R=m+RfjekmuoGgnNCd2NGKsoALGpQ@mail.gmail.com>
References: <VI1PR8303MB0093086905AE75AF5B287A89AD3F0@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
 <VI1PR8303MB009340F27A36A5B7F09C2896AD0A0@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
 <2554645fa01b0a80f159fcc640bd016f1554e013.camel@joachim-breitner.de>
 <VI1PR8303MB00930101C8BAF9ADFF6BFF3FAD0A0@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
 <2A9B70E6-3FE3-4BBB-AED2-98F0CBBB0577@joachim-breitner.de>
 <316820b7-8b2c-4d72-beed-941dd503ac23@www.fastmail.com>
 <CAF3RzK8aVRUWT=P8pjnr6R=m+RfjekmuoGgnNCd2NGKsoALGpQ@mail.gmail.com>
Message-ID: <CAF3RzK_MmPReU2iBXByAv4DpUp3NLYHh_4Zu=Fu3eGJemW=2Dg@mail.gmail.com>

Okay, found the proposal at
https://github.com/shayne-fletcher-da/ghc-proposals/blob/record-dot-syntax/proposals/0000-record-dot-syntax.md

My main question is whether this is really an improvement over just
defining an infix operator for carrying out this operation. I can
foresee having to untangle someone's code which was written with lots
of weird polymorphic naked field selectors at 3am under a deadline,
and not being very happy about this. Do we actually *want* people to
write code like the expression we're trying to disambiguate here? Is
it really too much to ask that they write f (getField @x) g (getField
@y) h (getField @z) or f (getField @x) (g (getField @y)) (h (getField
@z)) as appropriate to their situation?

On Tue, 28 Jan 2020 at 09:04, Cale Gibbard <cgibbard at gmail.com> 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 <eric at seidel.io> 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
> > > <simonpj at microsoft.com>:
> > > >|  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
> > > ><ghc-steering-committee-bounces at haskell.org>
> > > >|  On Behalf Of Joachim Breitner
> > > >|  Sent: 28 January 2020 11:55
> > > >|  To: ghc-steering-committee at 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 at joachim-breitner.de
> > > >|
> > > >|
> > > >https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joach
> > > >|  im-
> > > >|
> > > >breitner.de%2F&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C99dc94685bb34e
> > > >|
> > > >1f694a08d7a3e8faa2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6371580933
> > > >|
> > > >72311824&amp;sdata=N7iqz4VoL6oe4ICm3JIVVLW%2BBM%2BVIdGOeYa2obcjqdI%3D&amp;
> > > >|  reserved=0
> > > >|
> > > >|
> > > >|  _______________________________________________
> > > >|  ghc-steering-committee mailing list
> > > >|  ghc-steering-committee at haskell.org
> > > >|
> > > >https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.has
> > > >|  kell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
> > > >|
> > > >committee&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C99dc94685bb34e1f694
> > > >|
> > > >a08d7a3e8faa2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637158093372311
> > > >|
> > > >824&amp;sdata=AnxNHulQCUqWkKaKYmEXYQMQwl3F1MDPYS64GIAnVhA%3D&amp;reserved=
> > > >|  0
> > > _______________________________________________
> > > ghc-steering-committee mailing list
> > > ghc-steering-committee at haskell.org
> > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> > >
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

From simonpj at microsoft.com  Tue Jan 28 14:29:09 2020
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 28 Jan 2020 14:29:09 +0000
Subject: [ghc-steering-committee] Record syntax
In-Reply-To: <396D32D8-3BE8-4E66-BCF1-01B04F7C2B53@bitemyapp.com>
References: <CAF3RzK8aVRUWT=P8pjnr6R=m+RfjekmuoGgnNCd2NGKsoALGpQ@mail.gmail.com>
 <396D32D8-3BE8-4E66-BCF1-01B04F7C2B53@bitemyapp.com>
Message-ID: <AM5PR8303MB00822300045DECEDD9FF391DAD0A0@AM5PR8303MB0082.EURPRD83.prod.outlook.com>

|  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 <ghc-steering-committee-bounces at haskell.org>
|  On Behalf Of Christopher Allen
|  Sent: 28 January 2020 14:18
|  To: Cale Gibbard <cgibbard at gmail.com>
|  Cc: ghc-steering-committee at 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 <cgibbard at gmail.com> 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 <eric at seidel.io> 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
|  >>> <simonpj at microsoft.com>:
|  >>>> |  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
|  >>>> <ghc-steering-committee-bounces at haskell.org>
|  >>>> |  On Behalf Of Joachim Breitner
|  >>>> |  Sent: 28 January 2020 11:55
|  >>>> |  To: ghc-steering-committee at 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 at joachim-breitner.de
|  >>>> |
|  >>>> |
|  >>>>
|  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joach
|  >>>> |  im-
|  >>>> |
|  >>>>
|  breitner.de%2F&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C99dc94685bb34e
|  >>>> |
|  >>>>
|  1f694a08d7a3e8faa2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6371580933
|  >>>> |
|  >>>>
|  72311824&amp;sdata=N7iqz4VoL6oe4ICm3JIVVLW%2BBM%2BVIdGOeYa2obcjqdI%3D&amp;
|  >>>> |  reserved=0
|  >>>> |
|  >>>> |
|  >>>> |  _______________________________________________
|  >>>> |  ghc-steering-committee mailing list
|  >>>> |  ghc-steering-committee at haskell.org
|  >>>> |
|  >>>>
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.has
|  >>>> |  kell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
|  >>>> |
|  >>>>
|  committee&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C99dc94685bb34e1f694
|  >>>> |
|  >>>>
|  a08d7a3e8faa2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637158093372311
|  >>>> |
|  >>>>
|  824&amp;sdata=AnxNHulQCUqWkKaKYmEXYQMQwl3F1MDPYS64GIAnVhA%3D&amp;reserved=
|  >>>> |  0
|  >>> _______________________________________________
|  >>> ghc-steering-committee mailing list
|  >>> ghc-steering-committee at haskell.org
|  >>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-
|  committee
|  >>>
|  >> _______________________________________________
|  >> ghc-steering-committee mailing list
|  >> ghc-steering-committee at haskell.org
|  >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-
|  committee
|  > _______________________________________________
|  > ghc-steering-committee mailing list
|  > ghc-steering-committee at haskell.org
|  > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
|  _______________________________________________
|  ghc-steering-committee mailing list
|  ghc-steering-committee at haskell.org
|  https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

From cgibbard at gmail.com  Tue Jan 28 14:42:56 2020
From: cgibbard at gmail.com (Cale Gibbard)
Date: Tue, 28 Jan 2020 09:42:56 -0500
Subject: [ghc-steering-committee] Record syntax
In-Reply-To: <AM5PR8303MB00822300045DECEDD9FF391DAD0A0@AM5PR8303MB0082.EURPRD83.prod.outlook.com>
References: <CAF3RzK8aVRUWT=P8pjnr6R=m+RfjekmuoGgnNCd2NGKsoALGpQ@mail.gmail.com>
 <396D32D8-3BE8-4E66-BCF1-01B04F7C2B53@bitemyapp.com>
 <AM5PR8303MB00822300045DECEDD9FF391DAD0A0@AM5PR8303MB0082.EURPRD83.prod.outlook.com>
Message-ID: <CAF3RzK_t=Ju21_atu+AySiSRiQyZMVER_R1SPqAX4NgLQtXtpA@mail.gmail.com>

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 <simonpj at microsoft.com> 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 <ghc-steering-committee-bounces at haskell.org>
> |  On Behalf Of Christopher Allen
> |  Sent: 28 January 2020 14:18
> |  To: Cale Gibbard <cgibbard at gmail.com>
> |  Cc: ghc-steering-committee at 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 <cgibbard at gmail.com> 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 <eric at seidel.io> 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
> |  >>> <simonpj at microsoft.com>:
> |  >>>> |  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
> |  >>>> <ghc-steering-committee-bounces at haskell.org>
> |  >>>> |  On Behalf Of Joachim Breitner
> |  >>>> |  Sent: 28 January 2020 11:55
> |  >>>> |  To: ghc-steering-committee at 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 at joachim-breitner.de
> |  >>>> |
> |  >>>> |
> |  >>>>
> |  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joach
> |  >>>> |  im-
> |  >>>> |
> |  >>>>
> |  breitner.de%2F&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C99dc94685bb34e
> |  >>>> |
> |  >>>>
> |  1f694a08d7a3e8faa2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6371580933
> |  >>>> |
> |  >>>>
> |  72311824&amp;sdata=N7iqz4VoL6oe4ICm3JIVVLW%2BBM%2BVIdGOeYa2obcjqdI%3D&amp;
> |  >>>> |  reserved=0
> |  >>>> |
> |  >>>> |
> |  >>>> |  _______________________________________________
> |  >>>> |  ghc-steering-committee mailing list
> |  >>>> |  ghc-steering-committee at haskell.org
> |  >>>> |
> |  >>>>
> |  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.has
> |  >>>> |  kell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
> |  >>>> |
> |  >>>>
> |  committee&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C99dc94685bb34e1f694
> |  >>>> |
> |  >>>>
> |  a08d7a3e8faa2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637158093372311
> |  >>>> |
> |  >>>>
> |  824&amp;sdata=AnxNHulQCUqWkKaKYmEXYQMQwl3F1MDPYS64GIAnVhA%3D&amp;reserved=
> |  >>>> |  0
> |  >>> _______________________________________________
> |  >>> ghc-steering-committee mailing list
> |  >>> ghc-steering-committee at haskell.org
> |  >>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-
> |  committee
> |  >>>
> |  >> _______________________________________________
> |  >> ghc-steering-committee mailing list
> |  >> ghc-steering-committee at haskell.org
> |  >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-
> |  committee
> |  > _______________________________________________
> |  > ghc-steering-committee mailing list
> |  > ghc-steering-committee at haskell.org
> |  > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> |  _______________________________________________
> |  ghc-steering-committee mailing list
> |  ghc-steering-committee at haskell.org
> |  https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

From cma at bitemyapp.com  Tue Jan 28 18:06:43 2020
From: cma at bitemyapp.com (Christopher Allen)
Date: Tue, 28 Jan 2020 12:06:43 -0600
Subject: [ghc-steering-committee] Record syntax
In-Reply-To: <CAF3RzK_t=Ju21_atu+AySiSRiQyZMVER_R1SPqAX4NgLQtXtpA@mail.gmail.com>
References: <CAF3RzK8aVRUWT=P8pjnr6R=m+RfjekmuoGgnNCd2NGKsoALGpQ@mail.gmail.com>
 <396D32D8-3BE8-4E66-BCF1-01B04F7C2B53@bitemyapp.com>
 <AM5PR8303MB00822300045DECEDD9FF391DAD0A0@AM5PR8303MB0082.EURPRD83.prod.outlook.com>
 <CAF3RzK_t=Ju21_atu+AySiSRiQyZMVER_R1SPqAX4NgLQtXtpA@mail.gmail.com>
Message-ID: <CADnndOq=8H2ujW_ARndH+M_awhBUVSobvOd+kGb-EizqdCyb2g@mail.gmail.com>

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 <cgibbard at gmail.com> 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 <simonpj at microsoft.com> 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 <ghc-steering-committee-bounces at haskell.org>
> > |  On Behalf Of Christopher Allen
> > |  Sent: 28 January 2020 14:18
> > |  To: Cale Gibbard <cgibbard at gmail.com>
> > |  Cc: ghc-steering-committee at 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 <cgibbard at gmail.com> 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 <eric at seidel.io> 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
> > |  >>> <simonpj at microsoft.com>:
> > |  >>>> |  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
> > |  >>>> <ghc-steering-committee-bounces at haskell.org>
> > |  >>>> |  On Behalf Of Joachim Breitner
> > |  >>>> |  Sent: 28 January 2020 11:55
> > |  >>>> |  To: ghc-steering-committee at 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 at joachim-breitner.de
> > |  >>>> |
> > |  >>>> |
> > |  >>>>
> > |  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joach
> > |  >>>> |  im-
> > |  >>>> |
> > |  >>>>
> > |  breitner.de%2F&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C99dc94685bb34e
> > |  >>>> |
> > |  >>>>
> > |  1f694a08d7a3e8faa2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6371580933
> > |  >>>> |
> > |  >>>>
> > |  72311824&amp;sdata=N7iqz4VoL6oe4ICm3JIVVLW%2BBM%2BVIdGOeYa2obcjqdI%3D&amp;
> > |  >>>> |  reserved=0
> > |  >>>> |
> > |  >>>> |
> > |  >>>> |  _______________________________________________
> > |  >>>> |  ghc-steering-committee mailing list
> > |  >>>> |  ghc-steering-committee at haskell.org
> > |  >>>> |
> > |  >>>>
> > |  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.has
> > |  >>>> |  kell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
> > |  >>>> |
> > |  >>>>
> > |  committee&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C99dc94685bb34e1f694
> > |  >>>> |
> > |  >>>>
> > |  a08d7a3e8faa2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637158093372311
> > |  >>>> |
> > |  >>>>
> > |  824&amp;sdata=AnxNHulQCUqWkKaKYmEXYQMQwl3F1MDPYS64GIAnVhA%3D&amp;reserved=
> > |  >>>> |  0
> > |  >>> _______________________________________________
> > |  >>> ghc-steering-committee mailing list
> > |  >>> ghc-steering-committee at haskell.org
> > |  >>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-
> > |  committee
> > |  >>>
> > |  >> _______________________________________________
> > |  >> ghc-steering-committee mailing list
> > |  >> ghc-steering-committee at haskell.org
> > |  >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-
> > |  committee
> > |  > _______________________________________________
> > |  > ghc-steering-committee mailing list
> > |  > ghc-steering-committee at haskell.org
> > |  > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> > |  _______________________________________________
> > |  ghc-steering-committee mailing list
> > |  ghc-steering-committee at haskell.org
> > |  https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee



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

From marlowsd at gmail.com  Thu Jan 30 08:52:14 2020
From: marlowsd at gmail.com (Simon Marlow)
Date: Thu, 30 Jan 2020 08:52:14 +0000
Subject: [ghc-steering-committee] [EXTERNAL] #265: Unlifted Datatypes,
 recommendation: accept
In-Reply-To: <01B33891-B077-4A35-914D-94A0C6B50F1F@richarde.dev>
References: <832fb9c5c2c9084a44e47afc19cb302fefe28e59.camel@joachim-breitner.de>
 <CANsrgP+2N4_VtvWT+k-3TtstWUm8LF3oZk3KyVx4Sj2uf7xDJw@mail.gmail.com>
 <VI1PR8303MB00938E74F445A5609780E9D9AD5C0@VI1PR8303MB0093.EURPRD83.prod.outlook.com>
 <CAH6fHQmKsp2+2iY31OLQkQCqRuhqRpbmYHujYtyAd8-DJjK+wg@mail.gmail.com>
 <CANsrgPKF5yGQew6SHz5BWe7Vod+vkQeYeyT9430vLXHakO+JCQ@mail.gmail.com>
 <01B33891-B077-4A35-914D-94A0C6B50F1F@richarde.dev>
Message-ID: <CANsrgP+tiEh5non4qJDVqRBK2tXE9kowVj3x9d_RwHhWYAJqHg@mail.gmail.com>

Following a round of suggestions and revisions, I've now marked this
proposal as accepted.

On Mon, 9 Dec 2019 at 10:24, Richard Eisenberg <rae at richarde.dev> wrote:

> I think that is our stated policy, yes.
>
> On Dec 9, 2019, at 7:58 AM, Simon Marlow <marlowsd at gmail.com> wrote:
>
> Shall we put the proposal back into the needs revision state while this is
> discussed and the proposal updated?
>
> On Mon, 9 Dec 2019 at 07:42, Spiwack, Arnaud <arnaud.spiwack at tweag.io>
> wrote:
>
>> There is a bit of a discussion on the thread (which I only got time to
>> briefly skim) about whether the proposal should mark unlifted newtypes with
>> a special keyword, or simply by fixing the return kind of the type
>> constructor to `TYPE 'UnliftedRep`. I'm rather on the side of using the
>> return kind, it makes more sense to me. SImon PJ also brings a pretty
>> strong argument in support of this view:
>> https://github.com/ghc-proposals/ghc-proposals/pull/265#issuecomment-562125048
>> .
>>
>> Either way, The proposal should at least discuss this view in the
>> alternatives before it gets to be accepted or not.
>>
>> But aside from that, I am absolutely in support of the general idea, and
>> the proposal itself is good.
>>
>>
>> On Thu, Dec 5, 2019 at 2:20 PM Simon Peyton Jones via
>> ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:
>>
>>> I’m in support here.  I’ve commented on the discussion thread.
>>>
>>>
>>>
>>> Simon
>>>
>>>
>>>
>>> *From:* ghc-steering-committee <
>>> ghc-steering-committee-bounces at haskell.org> *On Behalf Of *Simon Marlow
>>> *Sent:* 02 December 2019 10:06
>>> *To:* Joachim Breitner <mail at joachim-breitner.de>
>>> *Cc:* ghc-steering-committee at haskell.org
>>> *Subject:* [EXTERNAL] [ghc-steering-committee] #265: Unlifted
>>> Datatypes, recommendation: accept
>>>
>>>
>>>
>>> I recommend that we *accept* proposal #265 (Unlifted Datatypes)
>>>
>>>
>>>
>>> https://github.com/ghc-proposals/ghc-proposals/pull/265
>>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F265&data=02%7C01%7Csimonpj%40microsoft.com%7Cbebbb53672104f8804a408d7770f544a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637108780029253857&sdata=aEWC0cJAxCRJ973miRTP%2F6JtGVp%2F4FG6qqmKjjfKywE%3D&reserved=0>
>>>
>>>
>>> https://github.com/sgraf812/ghc-proposals/blob/unlifted-data/proposals/0000-unlifted-datatypes.rst
>>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fsgraf812%2Fghc-proposals%2Fblob%2Funlifted-data%2Fproposals%2F0000-unlifted-datatypes.rst&data=02%7C01%7Csimonpj%40microsoft.com%7Cbebbb53672104f8804a408d7770f544a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637108780029263813&sdata=JCfBIUeVfDO0f6CElwzpmPY9xyYj7pp%2FoojID59kkCo%3D&reserved=0>
>>>
>>>
>>>
>>> It's a fairly conservative extension: the kind TYPE 'UnliftedRep
>>> already exists with the required functionality, the only addition here is
>>> to allow user-defined types to be declared with that kind. The semantics
>>> are clear, and there already exists a prototype patch to implement it.
>>>
>>>
>>>
>>> There are considerable performance benefits to be had for
>>> performance-critical code, for instance the containers package.
>>>
>>>
>>>
>>> A couple of minor issues remain:
>>>
>>>    - Without special support, the type data unlifted Strict a = Force !a
>>>    comes with an associated box, so this type isn't as useful as it could be.
>>>    - It isn't possible to define values of kind TYPE 'UnlifedRep at the
>>>    top level, which might be a surprising restriction to the programmer.
>>>    (However, there's a reasonable workaround). Relatedly, GHC cannot lift
>>>    expressions of kind TYPE 'UnlifedRep to the top level in the
>>>    optimiser, which can lead to surprising performance behaviour. See
>>>    https://gitlab.haskell.org/ghc/ghc/issues/17521
>>>    <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2Fissues%2F17521&data=02%7C01%7Csimonpj%40microsoft.com%7Cbebbb53672104f8804a408d7770f544a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637108780029263813&sdata=dgDbIe9AhhI%2FIsnPDPxX7EAoVVkjaKthu%2FNGcyEBOTU%3D&reserved=0>
>>>
>>> Nevertheless, we shouldn't let the perfect be the enemy of the good, and
>>> Unlifted Datatypes is a clearly useful addition in my view.
>>>
>>>
>>>
>>> Cheers
>>>
>>> Simon
>>>
>>>
>>>
>>>
>>>
>>> On Thu, 28 Nov 2019 at 10:06, Joachim Breitner <mail at joachim-breitner.de>
>>> wrote:
>>>
>>> Dear Committee,
>>>
>>> this is your secretary speaking:
>>>
>>> Unlifed Datatypes
>>> has been proposed by Sebastian Graf
>>> https://github.com/ghc-proposals/ghc-proposals/pull/265
>>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F265&data=02%7C01%7Csimonpj%40microsoft.com%7Cbebbb53672104f8804a408d7770f544a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637108780029263813&sdata=sbtvm3eM43ihY%2FPoTeS4Sp%2BDE2AJUBSqgGOv6HymoKg%3D&reserved=0>
>>>
>>> https://github.com/sgraf812/ghc-proposals/blob/unlifted-data/proposals/0000-unlifted-datatypes.rst
>>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fsgraf812%2Fghc-proposals%2Fblob%2Funlifted-data%2Fproposals%2F0000-unlifted-datatypes.rst&data=02%7C01%7Csimonpj%40microsoft.com%7Cbebbb53672104f8804a408d7770f544a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637108780029273768&sdata=PeFWonpeS4vYeanypRBMEWgLFy9CgVeue3OhHrZa7aM%3D&reserved=0>
>>>
>>> I propose Simon Marlow as the shepherd, as the expert on low-level stuff.
>>>
>>> Please reach consensus as described in
>>> https://github.com/ghc-proposals/ghc-proposals#committee-process
>>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%23committee-process&data=02%7C01%7Csimonpj%40microsoft.com%7Cbebbb53672104f8804a408d7770f544a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637108780029273768&sdata=9V5KT%2F6kDmUNU5xMMKByR4egiSf61TMdq6yoHMviGcg%3D&reserved=0>
>>> I suggest you make a recommendation, in a new e-mail thread with the
>>> proposal number in the subject, about the decision, maybe point out
>>> debatable points, and assume that anyone who stays quiet agrees with
>>> you.
>>>
>>> Thanks,
>>> Joachim
>>> --
>>> Joachim Breitner
>>>   mail at joachim-breitner.de
>>>   http://www.joachim-breitner.de/
>>> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cbebbb53672104f8804a408d7770f544a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637108780029283726&sdata=CSR%2BQeNk7k5o6bjo%2Fv2Ke5Yu6h2hEwqR2gIcu0XMU5U%3D&reserved=0>
>>>
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at haskell.org
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7Cbebbb53672104f8804a408d7770f544a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637108780029283726&sdata=taRsN3Xgue2y426KtNoZGzYtwdviS2%2BwyKmnww8yEAs%3D&reserved=0>
>>>
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at haskell.org
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>
>> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20200130/f902b4bb/attachment.html>