From marlowsd at gmail.com  Tue Sep  5 12:29:56 2017
From: marlowsd at gmail.com (Simon Marlow)
Date: Tue, 5 Sep 2017 13:29:56 +0100
Subject: [ghc-steering-committee] Explicit foralls
In-Reply-To: <AM4PR83MB0033B83176413B2337AA0D27AD9B0@AM4PR83MB0033.EURPRD83.prod.outlook.com>
References: <AM4PR83MB0033B83176413B2337AA0D27AD9B0@AM4PR83MB0033.EURPRD83.prod.outlook.com>
Message-ID: <CANsrgPJ1CED4bqOp5=j_UvRa1whYRoxP94ZMVLo=c5ch0WS7bA@mail.gmail.com>

Looks good to me.

On 25 August 2017 at 15:15, Simon Peyton Jones <simonpj at microsoft.com>
wrote:

> Friends
>
> I propose that we accept the Explicit Foralls proposal.
>
>    - No one objected
>    - It makes the language more expressive and uniform
>    - It fixes a long-standing ticket #2600
>
> The only bump in the road is the double forall in RULES (see the Examples
> in the proposal).  But that’s not Ricahrd’s fault, and the proposed
> solution seems reasonable.
>
> I move to accept.
>
> 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/20170905/4cf2cda9/attachment.html>

From mail at joachim-breitner.de  Fri Sep  8 15:32:33 2017
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Fri, 08 Sep 2017 16:32:33 +0100
Subject: [ghc-steering-committee] Status
Message-ID: <1504884753.9424.1.camel@joachim-breitner.de>

Hi,

off the floor at the Haskell Symposium, the current status. I think
many of us are here in Oxford. I guess we could try to meet in person
and work off the backlog simply by quick real-live discussion – but
maybe people have better things to do, and not all of us are here. So
let’s just carry on as usual.

Since the last status update one new proposals has come up for
deliberation, and one proposals was accepted.

Open at the moment are:

NOUNPACK on function arguments
https://github.com/ghc-proposals/ghc-proposals/pull/46
Shepherd: Simon Marlow
Status: There was more discussion on GitHub, and @treeowl will have a
look if the proposal text is reflecting all that discussion.
(Still waiting on @treeowl.)

Lazy unboxed tuples
https://github.com/ghc-proposals/ghc-proposals/pull/35
Shepherd: Ryan Newton
Status: Still waiting for Ryan to make a recommendation.

Explicit foralls proposal
https://github.com/ghc-proposals/ghc-proposals/pull/55
Shepherd: Simon Peyton Jones
Status: Simon recommended to accept this, and we see silent consensus
emerging.

Mutable constructor fields
https://github.com/ghc-proposals/ghc-proposals/pull/8
Shepherd: Ryan Newton
Status: Waiting for Ryan to make a recommendation.

Or Patterns
https://github.com/ghc-proposals/ghc-proposals/pull/43
Shepherd: Manuel Chakravarty
Status: Waiting for Manuel to make a recommendation.

Type fixity
https://github.com/ghc-proposals/ghc-proposals/pull/65
Shepherd: Joachim Breitner
Status: Rejection recommended, but met with different opinions here. We
need to either continue debating or *gasp* actually vote.


Besides these, there are some proposals actively under discussion. You
can always check them out at
https://github.com/ghc-proposals/ghc-proposals/pulls?q=is%3Aopen+is%3Apr+no%3Alabel


Greetings,
Joachim


-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20170908/601c4a5a/attachment.sig>

From mail at joachim-breitner.de  Mon Sep 18 02:58:47 2017
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sun, 17 Sep 2017 22:58:47 -0400
Subject: [ghc-steering-committee] Explicit foralls
In-Reply-To: <CANsrgPJ1CED4bqOp5=j_UvRa1whYRoxP94ZMVLo=c5ch0WS7bA@mail.gmail.com>
References: <AM4PR83MB0033B83176413B2337AA0D27AD9B0@AM4PR83MB0033.EURPRD83.prod.outlook.com>
 <CANsrgPJ1CED4bqOp5=j_UvRa1whYRoxP94ZMVLo=c5ch0WS7bA@mail.gmail.com>
Message-ID: <1505703527.4631.3.camel@joachim-breitner.de>

Hi,

this proposal received plenty of silent support. Unless someone objects
very soon, I will mark this accepted.

Joachim

Am Dienstag, den 05.09.2017, 13:29 +0100 schrieb Simon Marlow:
> Looks good to me.
> 
> On 25 August 2017 at 15:15, Simon Peyton Jones <simonpj at microsoft.com
> > wrote:
> > Friends
> > I propose that we accept the Explicit Foralls proposal.
> > No one objected
> > It makes the language more expressive and uniform
> > It fixes a long-standing ticket #2600
> > The only bump in the road is the double forall in RULES (see the
> > Examples in the proposal).  But that’s not Ricahrd’s fault, and the
> > proposed solution seems reasonable.
> > I move to accept.
> > Simon
> > 
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-comm
> > ittee
> > 
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-commit
> tee
-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20170917/645959be/attachment.sig>

From mail at joachim-breitner.de  Wed Sep 20 13:29:17 2017
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 20 Sep 2017 09:29:17 -0400
Subject: [ghc-steering-committee] Explicit foralls
In-Reply-To: <1505703527.4631.3.camel@joachim-breitner.de>
References: <AM4PR83MB0033B83176413B2337AA0D27AD9B0@AM4PR83MB0033.EURPRD83.prod.outlook.com>
 <CANsrgPJ1CED4bqOp5=j_UvRa1whYRoxP94ZMVLo=c5ch0WS7bA@mail.gmail.com>
 <1505703527.4631.3.camel@joachim-breitner.de>
Message-ID: <1505914157.963.2.camel@joachim-breitner.de>

Hi,

marked as accepted!

Greetings,
Joachim

Am Sonntag, den 17.09.2017, 22:58 -0400 schrieb Joachim Breitner:
> Hi,
> 
> this proposal received plenty of silent support. Unless someone
> objects
> very soon, I will mark this accepted.
> 
> Joachim
> 
> Am Dienstag, den 05.09.2017, 13:29 +0100 schrieb Simon Marlow:
> > Looks good to me.
> > 
> > On 25 August 2017 at 15:15, Simon Peyton Jones <simonpj at microsoft.c
> > om
> > > wrote:
> > > Friends
> > > I propose that we accept the Explicit Foralls proposal.
> > > No one objected
> > > It makes the language more expressive and uniform
> > > It fixes a long-standing ticket #2600
> > > The only bump in the road is the double forall in RULES (see the
> > > Examples in the proposal).  But that’s not Ricahrd’s fault, and
> > > the
> > > proposed solution seems reasonable.
> > > I move to accept.
> > > Simon
> > > 
> > > _______________________________________________
> > > ghc-steering-committee mailing list
> > > ghc-steering-committee at haskell.org
> > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-co
> > > mm
> > > ittee
> > > 
> > 
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-comm
> > it
> > tee
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-commit
> tee
-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20170920/8b2bce42/attachment.sig>

From mail at joachim-breitner.de  Wed Sep 20 16:23:51 2017
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 20 Sep 2017 12:23:51 -0400
Subject: [ghc-steering-committee] Proposal: Type Fixity (#65),
 Recommendation: Reject
In-Reply-To: <1503857788.4643.2.camel@joachim-breitner.de>
References: <1503857788.4643.2.camel@joachim-breitner.de>
Message-ID: <1505924631.5913.14.camel@joachim-breitner.de>

Hi,

the type fixity proposal
(https://github.com/ghc-proposals/ghc-proposals/pull/65)
was met with mixed reactions.

 * I recommended rejection and Manuel strongly agrees with me.
 * SPJ does not have strong opinions either way.
 * Richard is in favor, and Iavor agrees.


Our process says “If consensus is elusive, then we vote, with the
Simons retaining veto power.” It looks like this might be such a case.
Should we go ahead and vote, or is more discussion likely to sway some
of us?

(I guess I can be swayed towards acceptance, especially if this
proposal re-uses existing syntactic idioms from export lists with
ExplicitNamespaces on.)

Greetings,
Joachim



Am Sonntag, den 27.08.2017, 20:16 +0200 schrieb Joachim Breitner:
> Dear Committee,
> 
> Ryan Scott’s proposal to allow fixity declaration to explicitly target
> values or types has been brought before us:
> https://github.com/RyanGlScott/ghc-proposals/blob/type-infix/0000-type-infix.rst
> https://github.com/ghc-proposals/ghc-proposals/pull/65
> 
> I (the secretary) nominates myself as the shepherd, so I can right away
> continue giving a recommendation.
> 
> I propose to reject this proposal. The main reasons are:
>  * it is not clear if there is a real use case for this. Has anyone
>    ever complained about the status quo?
>    The proposal does not motivate the need for a change well enough.
>    (There is a related bug in TH, but that bug can probably simply be 
>    fixed.)
>  * The status quo can be sold as a feature, rather than a short-coming.
>    Namely that an operator has a fixed fixity, no matter what namespace
>    it lives in.
>    This matches morally what other languages do: In Gallina, fixity
>    is assigned to names independent of their definition, AFAIK.
>  * There is a non-trivial implementation and education overhead, a
>    weight that is not pulled by the gains.
> 
> If we’d design Haskell from scratch, my verdict might possibly be
> different (but maybe we wouldn’t even allow types and values to share
> names then…)
> 
> 
> Please contradict me or indicate consensus by staying silent.
> 
> 
> Greetings,
> Joachim
> 
> _______________________________________________
> 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/

-- 
Joachim “nomeata” Breitner
  mail at joachim-breitner.de
  https://www.joachim-breitner.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20170920/1b75d9b4/attachment.sig>

From cma at bitemyapp.com  Wed Sep 20 16:31:43 2017
From: cma at bitemyapp.com (Christopher Allen)
Date: Wed, 20 Sep 2017 11:31:43 -0500
Subject: [ghc-steering-committee] Proposal: Type Fixity (#65),
 Recommendation: Reject
In-Reply-To: <1505924631.5913.14.camel@joachim-breitner.de>
References: <1503857788.4643.2.camel@joachim-breitner.de>
 <1505924631.5913.14.camel@joachim-breitner.de>
Message-ID: <CADnndOqGckSJHCzDb0HuHE5HPL3jDUsfwF2TSAHoE_yVbFREpw@mail.gmail.com>

I concur with Manuel and Joachim's reasons for rejection, if we're
headed to a vote.

On Wed, Sep 20, 2017 at 11:23 AM, Joachim Breitner
<mail at joachim-breitner.de> wrote:
> Hi,
>
> the type fixity proposal
> (https://github.com/ghc-proposals/ghc-proposals/pull/65)
> was met with mixed reactions.
>
>  * I recommended rejection and Manuel strongly agrees with me.
>  * SPJ does not have strong opinions either way.
>  * Richard is in favor, and Iavor agrees.
>
>
> Our process says “If consensus is elusive, then we vote, with the
> Simons retaining veto power.” It looks like this might be such a case.
> Should we go ahead and vote, or is more discussion likely to sway some
> of us?
>
> (I guess I can be swayed towards acceptance, especially if this
> proposal re-uses existing syntactic idioms from export lists with
> ExplicitNamespaces on.)
>
> Greetings,
> Joachim
>
>
>
> Am Sonntag, den 27.08.2017, 20:16 +0200 schrieb Joachim Breitner:
>> Dear Committee,
>>
>> Ryan Scott’s proposal to allow fixity declaration to explicitly target
>> values or types has been brought before us:
>> https://github.com/RyanGlScott/ghc-proposals/blob/type-infix/0000-type-infix.rst
>> https://github.com/ghc-proposals/ghc-proposals/pull/65
>>
>> I (the secretary) nominates myself as the shepherd, so I can right away
>> continue giving a recommendation.
>>
>> I propose to reject this proposal. The main reasons are:
>>  * it is not clear if there is a real use case for this. Has anyone
>>    ever complained about the status quo?
>>    The proposal does not motivate the need for a change well enough.
>>    (There is a related bug in TH, but that bug can probably simply be
>>    fixed.)
>>  * The status quo can be sold as a feature, rather than a short-coming.
>>    Namely that an operator has a fixed fixity, no matter what namespace
>>    it lives in.
>>    This matches morally what other languages do: In Gallina, fixity
>>    is assigned to names independent of their definition, AFAIK.
>>  * There is a non-trivial implementation and education overhead, a
>>    weight that is not pulled by the gains.
>>
>> If we’d design Haskell from scratch, my verdict might possibly be
>> different (but maybe we wouldn’t even allow types and values to share
>> names then…)
>>
>>
>> Please contradict me or indicate consensus by staying silent.
>>
>>
>> Greetings,
>> Joachim
>>
>> _______________________________________________
>> 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/
>
> --
> Joachim “nomeata” Breitner
>   mail at joachim-breitner.de
>   https://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 iavor.diatchki at gmail.com  Wed Sep 20 17:42:20 2017
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Wed, 20 Sep 2017 17:42:20 +0000
Subject: [ghc-steering-committee] Proposal: Type Fixity (#65),
 Recommendation: Reject
In-Reply-To: <CADnndOqGckSJHCzDb0HuHE5HPL3jDUsfwF2TSAHoE_yVbFREpw@mail.gmail.com>
References: <1503857788.4643.2.camel@joachim-breitner.de>
 <1505924631.5913.14.camel@joachim-breitner.de>
 <CADnndOqGckSJHCzDb0HuHE5HPL3jDUsfwF2TSAHoE_yVbFREpw@mail.gmail.com>
Message-ID: <CAGK9nuqLzv=m9ZANmjRVNm-m2WRv5SxvfpxyaWa9Ep59ymNmYw@mail.gmail.com>

Could someone summarize the reason for the rejection? I do agree that this
is a fairly corner case situation, but to me it clearly looks like a wart
in the language---it is the only place in the language (I can think of)
where we are conflating names from different namespaces.

It also seems quite surprising that this would have a significant
implementation overhead, but I have not looked at what the issue might be.

-Iavor







On Wed, Sep 20, 2017 at 9:32 AM Christopher Allen <cma at bitemyapp.com> wrote:

> I concur with Manuel and Joachim's reasons for rejection, if we're
> headed to a vote.
>
> On Wed, Sep 20, 2017 at 11:23 AM, Joachim Breitner
> <mail at joachim-breitner.de> wrote:
> > Hi,
> >
> > the type fixity proposal
> > (https://github.com/ghc-proposals/ghc-proposals/pull/65)
> > was met with mixed reactions.
> >
> >  * I recommended rejection and Manuel strongly agrees with me.
> >  * SPJ does not have strong opinions either way.
> >  * Richard is in favor, and Iavor agrees.
> >
> >
> > Our process says “If consensus is elusive, then we vote, with the
> > Simons retaining veto power.” It looks like this might be such a case.
> > Should we go ahead and vote, or is more discussion likely to sway some
> > of us?
> >
> > (I guess I can be swayed towards acceptance, especially if this
> > proposal re-uses existing syntactic idioms from export lists with
> > ExplicitNamespaces on.)
> >
> > Greetings,
> > Joachim
> >
> >
> >
> > Am Sonntag, den 27.08.2017, 20:16 +0200 schrieb Joachim Breitner:
> >> Dear Committee,
> >>
> >> Ryan Scott’s proposal to allow fixity declaration to explicitly target
> >> values or types has been brought before us:
> >>
> https://github.com/RyanGlScott/ghc-proposals/blob/type-infix/0000-type-infix.rst
> >> https://github.com/ghc-proposals/ghc-proposals/pull/65
> >>
> >> I (the secretary) nominates myself as the shepherd, so I can right away
> >> continue giving a recommendation.
> >>
> >> I propose to reject this proposal. The main reasons are:
> >>  * it is not clear if there is a real use case for this. Has anyone
> >>    ever complained about the status quo?
> >>    The proposal does not motivate the need for a change well enough.
> >>    (There is a related bug in TH, but that bug can probably simply be
> >>    fixed.)
> >>  * The status quo can be sold as a feature, rather than a short-coming.
> >>    Namely that an operator has a fixed fixity, no matter what namespace
> >>    it lives in.
> >>    This matches morally what other languages do: In Gallina, fixity
> >>    is assigned to names independent of their definition, AFAIK.
> >>  * There is a non-trivial implementation and education overhead, a
> >>    weight that is not pulled by the gains.
> >>
> >> If we’d design Haskell from scratch, my verdict might possibly be
> >> different (but maybe we wouldn’t even allow types and values to share
> >> names then…)
> >>
> >>
> >> Please contradict me or indicate consensus by staying silent.
> >>
> >>
> >> Greetings,
> >> Joachim
> >>
> >> _______________________________________________
> >> 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/
> >
> > --
> > Joachim “nomeata” Breitner
> >   mail at joachim-breitner.de
> >   https://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
> _______________________________________________
> 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/20170920/a944aebf/attachment-0001.html>

From mail at joachim-breitner.de  Wed Sep 20 20:11:23 2017
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 20 Sep 2017 16:11:23 -0400
Subject: [ghc-steering-committee] Proposal: Type Fixity (#65),
 Recommendation: Reject
In-Reply-To: <CAGK9nuqLzv=m9ZANmjRVNm-m2WRv5SxvfpxyaWa9Ep59ymNmYw@mail.gmail.com>
References: <1503857788.4643.2.camel@joachim-breitner.de>
 <1505924631.5913.14.camel@joachim-breitner.de>
 <CADnndOqGckSJHCzDb0HuHE5HPL3jDUsfwF2TSAHoE_yVbFREpw@mail.gmail.com>
 <CAGK9nuqLzv=m9ZANmjRVNm-m2WRv5SxvfpxyaWa9Ep59ymNmYw@mail.gmail.com>
Message-ID: <1505938283.1534.3.camel@joachim-breitner.de>

Hi,

the two reasons mentioned are:
 * Implementation and complexity overhead for a fringe wart.
 * It is an anti-feature if mentally parsing the structure of an
   expression "a + b * c" is not possible without knowing whether this
   is a term or a type. It is possible now, but only with serious
   effort (multiple modules).


Greetings,
Joachim


Am Mittwoch, den 20.09.2017, 17:42 +0000 schrieb Iavor Diatchki:
> Could someone summarize the reason for the rejection? I do agree that
> this is a fairly corner case situation, but to me it clearly looks
> like a wart in the language---it is the only place in the language (I
> can think of) where we are conflating names from different
> namespaces.
> 
> It also seems quite surprising that this would have a significant
> implementation overhead, but I have not looked at what the issue
> might be.
> 
> -Iavor
> 
> 
> 
> 
> 
> 
> 
> On Wed, Sep 20, 2017 at 9:32 AM Christopher Allen <cma at bitemyapp.com>
> wrote:
> > I concur with Manuel and Joachim's reasons for rejection, if we're
> > headed to a vote.
> > 
> > On Wed, Sep 20, 2017 at 11:23 AM, Joachim Breitner
> > <mail at joachim-breitner.de> wrote:
> > > Hi,
> > >
> > > the type fixity proposal
> > > (https://github.com/ghc-proposals/ghc-proposals/pull/65)
> > > was met with mixed reactions.
> > >
> > >  * I recommended rejection and Manuel strongly agrees with me.
> > >  * SPJ does not have strong opinions either way.
> > >  * Richard is in favor, and Iavor agrees.
> > >
> > >
> > > Our process says “If consensus is elusive, then we vote, with the
> > > Simons retaining veto power.” It looks like this might be such a
> > case.
> > > Should we go ahead and vote, or is more discussion likely to sway
> > some
> > > of us?
> > >
> > > (I guess I can be swayed towards acceptance, especially if this
> > > proposal re-uses existing syntactic idioms from export lists with
> > > ExplicitNamespaces on.)
> > >
> > > Greetings,
> > > Joachim
> > >
> > >
> > >
> > > Am Sonntag, den 27.08.2017, 20:16 +0200 schrieb Joachim Breitner:
> > >> Dear Committee,
> > >>
> > >> Ryan Scott’s proposal to allow fixity declaration to explicitly
> > target
> > >> values or types has been brought before us:
> > >> https://github.com/RyanGlScott/ghc-proposals/blob/type-infix/000
> > 0-type-infix.rst
> > >> https://github.com/ghc-proposals/ghc-proposals/pull/65
> > >>
> > >> I (the secretary) nominates myself as the shepherd, so I can
> > right away
> > >> continue giving a recommendation.
> > >>
> > >> I propose to reject this proposal. The main reasons are:
> > >>  * it is not clear if there is a real use case for this. Has
> > anyone
> > >>    ever complained about the status quo?
> > >>    The proposal does not motivate the need for a change well
> > enough.
> > >>    (There is a related bug in TH, but that bug can probably
> > simply be
> > >>    fixed.)
> > >>  * The status quo can be sold as a feature, rather than a short-
> > coming.
> > >>    Namely that an operator has a fixed fixity, no matter what
> > namespace
> > >>    it lives in.
> > >>    This matches morally what other languages do: In Gallina,
> > fixity
> > >>    is assigned to names independent of their definition, AFAIK.
> > >>  * There is a non-trivial implementation and education overhead,
> > a
> > >>    weight that is not pulled by the gains.
> > >>
> > >> If we’d design Haskell from scratch, my verdict might possibly
> > be
> > >> different (but maybe we wouldn’t even allow types and values to
> > share
> > >> names then…)
> > >>
> > >>
> > >> Please contradict me or indicate consensus by staying silent.
> > >>
> > >>
> > >> Greetings,
> > >> Joachim
> > >>
> > >> _______________________________________________
> > >> ghc-steering-committee mailing list
> > >> ghc-steering-committee at haskell.org
> > >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c
> > ommittee
> > > --
> > > Joachim Breitner
> > >   mail at joachim-breitner.de
> > >   http://www.joachim-breitner.de/
> > >
> > > --
> > > Joachim “nomeata” Breitner
> > >   mail at joachim-breitner.de
> > >   https://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-co
> > mmittee
> > >
> > 
> > 
> > 
> > --
> > Chris Allen
> > Currently working on http://haskellbook.com
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-comm
> > ittee
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-commit
> tee
-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20170920/c0431055/attachment.sig>

From rae at cs.brynmawr.edu  Wed Sep 20 22:43:19 2017
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Wed, 20 Sep 2017 18:43:19 -0400
Subject: [ghc-steering-committee] Proposal: Type Fixity (#65),
	Recommendation: Reject
In-Reply-To: <CADnndOqGckSJHCzDb0HuHE5HPL3jDUsfwF2TSAHoE_yVbFREpw@mail.gmail.com>
References: <1503857788.4643.2.camel@joachim-breitner.de>
 <1505924631.5913.14.camel@joachim-breitner.de>
 <CADnndOqGckSJHCzDb0HuHE5HPL3jDUsfwF2TSAHoE_yVbFREpw@mail.gmail.com>
Message-ID: <421D9D51-3688-4656-807F-1738E748267B@cs.brynmawr.edu>

I remain in favor of this proposal and currently feel unlikely to be swayed. (But I will continue to read and seriously consider dissenting viewpoints, of course.)

In an attempt to convince others of my stance, let me address directly the reasons against that have been brought forth here:

Joachim writes:
> * it is not clear if there is a real use case for this. Has anyone
>   ever complained about the status quo?

I have found this jarring for years. But I'm not sure I'm enough of a Real User to count. (where "this" = one Haskell construct which, in opposition to all others, considers the similar spelling of a type-level name and a term-level name to have an effect on the meaning of a program)

>   The proposal does not motivate the need for a change well enough.
>   (There is a related bug in TH, but that bug can probably simply be 
>   fixed.)

Agreed that the TH bug could be fixed without this proposal.

> * The status quo can be sold as a feature, rather than a short-coming.
>   Namely that an operator has a fixed fixity, no matter what namespace
>   it lives in.

I'm not sure exactly what this means. The type-level (*) and the term-level (*) are different operators. Perhaps you mean "Namely that all operators that have the same spelling have a fixed fixity, ...", but then we're back to the construct giving a semantics to the similar spelling of two definitions.

>   This matches morally what other languages do: In Gallina, fixity
>   is assigned to names independent of their definition, AFAIK.

I don't think this issue has a counterpart in, e.g., Gallina. This is because Gallina just has one namespace, so the set of all operators that have the same spelling has at most one element.

> * There is a non-trivial implementation and education overhead, a
>   weight that is not pulled by the gains.

I argue that the education overhead is in explaining the status quo, and the proposal reduces the education overhead. Anecdote: a student in my Haskell class last semester asked, unbidden, how it was that one fixity declaration affects two separate definitions, and I had to explain this very conundrum.

Manuel writes:
> I am strongly against this proposal. User-defined fixities are already a feature that needs to be used with care, carrying the danger that the user of an API with ample operators with custom fixities needs to memorise many, often somewhat arbitrary numbers (i.e., precedence levels).

I agree here -- fixities are possible to abuse horribly and are difficult to work with.

> Using different fixity declarations for the same operator name on the value and type level seems a sure way to increase confusion.

Yet here I disagree: I reject the notion of the "same operator". A definition (data a :*: b = a :*: b) defines two operators that have the same spelling, just like (data T a b = T a b) defines two identifiers spelled "T". Note that the two (:*:)s have different types, just like the two `T`s. I don't sit comfortably calling two things with different types the "same". :)

Could this new feature proposed be abused? Absolutely. But I don't think the potential for abuse should stop us, given that library-writers already have abused everything in sight -- and sometimes to good effect! (For example, the original HList is an abuse of functional dependencies but has spawned an entire cottage industry of type-level shenanigans.)

I should also address why I care about this: Since its inception, Haskell has had the ability to use the same name in types as in terms. I think for much of this time, the type/term boundary wasn't seen so much as a pair of namespaces as essentially two different languages. Some set of constructs was available in terms, and a different set was available in types. Because they were separate languages, it was natural for them to have separate namespaces. And it might even be reasonable to talk about the "same" construct existing in both. After all, of course the constructs aren't *really* the same, as they exist in different languages. (Much like when we say that () is the same as C's void... but of course they're not *really* the same.)

Now, however, with the advent of DataKinds and TypeInType, we are actively blurring the separation between the languages. Yet we still allow constructs like "data T = T". So we need a new way of thinking about such declarations to stop us from getting confused -- and my approach is to consider that Haskell simply has two namespaces. (Actually, it has more than that, given that lower-case names live apart from upper-case ones. But I digress.) Namespaces are a relatively ubiquitous concept in programming, and so the situation can be easily explained and learned. I have been pushing my model of namespaces in talking about the ' used to write data constructors in types as a namespace selection operator, not a "promotion" operator.

The current status quo of fixity declarations pierces a hole in this model of Haskell's namespaces. And so I find it quite distasteful and wish to patch the hole.

(I hope I don't need to say that, of course, I'll go along with a majority vote on the matter and move on to those other raw fish, should my little manifesto here not win the day.)

Thanks for reading,
Richard


> 
> 
> On Sep 20, 2017, at 12:31 PM, Christopher Allen <cma at bitemyapp.com> wrote:
> 
> I concur with Manuel and Joachim's reasons for rejection, if we're
> headed to a vote.
> 
> On Wed, Sep 20, 2017 at 11:23 AM, Joachim Breitner
> <mail at joachim-breitner.de> wrote:
>> Hi,
>> 
>> the type fixity proposal
>> (https://github.com/ghc-proposals/ghc-proposals/pull/65)
>> was met with mixed reactions.
>> 
>> * I recommended rejection and Manuel strongly agrees with me.
>> * SPJ does not have strong opinions either way.
>> * Richard is in favor, and Iavor agrees.
>> 
>> 
>> Our process says “If consensus is elusive, then we vote, with the
>> Simons retaining veto power.” It looks like this might be such a case.
>> Should we go ahead and vote, or is more discussion likely to sway some
>> of us?
>> 
>> (I guess I can be swayed towards acceptance, especially if this
>> proposal re-uses existing syntactic idioms from export lists with
>> ExplicitNamespaces on.)
>> 
>> Greetings,
>> Joachim
>> 
>> 
>> 
>> Am Sonntag, den 27.08.2017, 20:16 +0200 schrieb Joachim Breitner:
>>> Dear Committee,
>>> 
>>> Ryan Scott’s proposal to allow fixity declaration to explicitly target
>>> values or types has been brought before us:
>>> https://github.com/RyanGlScott/ghc-proposals/blob/type-infix/0000-type-infix.rst
>>> https://github.com/ghc-proposals/ghc-proposals/pull/65
>>> 
>>> I (the secretary) nominates myself as the shepherd, so I can right away
>>> continue giving a recommendation.
>>> 
>>> I propose to reject this proposal. The main reasons are:
>>> * it is not clear if there is a real use case for this. Has anyone
>>>   ever complained about the status quo?
>>>   The proposal does not motivate the need for a change well enough.
>>>   (There is a related bug in TH, but that bug can probably simply be
>>>   fixed.)
>>> * The status quo can be sold as a feature, rather than a short-coming.
>>>   Namely that an operator has a fixed fixity, no matter what namespace
>>>   it lives in.
>>>   This matches morally what other languages do: In Gallina, fixity
>>>   is assigned to names independent of their definition, AFAIK.
>>> * There is a non-trivial implementation and education overhead, a
>>>   weight that is not pulled by the gains.
>>> 
>>> If we’d design Haskell from scratch, my verdict might possibly be
>>> different (but maybe we wouldn’t even allow types and values to share
>>> names then…)
>>> 
>>> 
>>> Please contradict me or indicate consensus by staying silent.
>>> 
>>> 
>>> Greetings,
>>> Joachim
>>> 
>>> _______________________________________________
>>> 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/
>> 
>> --
>> Joachim “nomeata” Breitner
>>  mail at joachim-breitner.de
>>  https://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
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee


From rleshchinskiy at gmail.com  Thu Sep 21 06:13:03 2017
From: rleshchinskiy at gmail.com (Roman Leschinskiy)
Date: Thu, 21 Sep 2017 07:13:03 +0100
Subject: [ghc-steering-committee] Proposal: Type Fixity (#65),
	Recommendation: Reject
In-Reply-To: <421D9D51-3688-4656-807F-1738E748267B@cs.brynmawr.edu>
References: <1503857788.4643.2.camel@joachim-breitner.de>
 <1505924631.5913.14.camel@joachim-breitner.de>
 <CADnndOqGckSJHCzDb0HuHE5HPL3jDUsfwF2TSAHoE_yVbFREpw@mail.gmail.com>
 <421D9D51-3688-4656-807F-1738E748267B@cs.brynmawr.edu>
Message-ID: <E7EB02AF-2C2A-44D1-AF7C-DAC283B5385C@gmail.com>

I'm quite ambivalent about this but would vote yes if it came to that. It does fix a little wart, people seem to want it strongly and I wouldn't ban it from our code base.

Thanks,

Roman

> On 20 Sep 2017, at 23:43, Richard Eisenberg <rae at cs.brynmawr.edu> wrote:
> 
> I remain in favor of this proposal and currently feel unlikely to be swayed. (But I will continue to read and seriously consider dissenting viewpoints, of course.)
> 
> In an attempt to convince others of my stance, let me address directly the reasons against that have been brought forth here:
> 
> Joachim writes:
>> * it is not clear if there is a real use case for this. Has anyone
>>  ever complained about the status quo?
> 
> I have found this jarring for years. But I'm not sure I'm enough of a Real User to count. (where "this" = one Haskell construct which, in opposition to all others, considers the similar spelling of a type-level name and a term-level name to have an effect on the meaning of a program)
> 
>>  The proposal does not motivate the need for a change well enough.
>>  (There is a related bug in TH, but that bug can probably simply be 
>>  fixed.)
> 
> Agreed that the TH bug could be fixed without this proposal.
> 
>> * The status quo can be sold as a feature, rather than a short-coming.
>>  Namely that an operator has a fixed fixity, no matter what namespace
>>  it lives in.
> 
> I'm not sure exactly what this means. The type-level (*) and the term-level (*) are different operators. Perhaps you mean "Namely that all operators that have the same spelling have a fixed fixity, ...", but then we're back to the construct giving a semantics to the similar spelling of two definitions.
> 
>>  This matches morally what other languages do: In Gallina, fixity
>>  is assigned to names independent of their definition, AFAIK.
> 
> I don't think this issue has a counterpart in, e.g., Gallina. This is because Gallina just has one namespace, so the set of all operators that have the same spelling has at most one element.
> 
>> * There is a non-trivial implementation and education overhead, a
>>  weight that is not pulled by the gains.
> 
> I argue that the education overhead is in explaining the status quo, and the proposal reduces the education overhead. Anecdote: a student in my Haskell class last semester asked, unbidden, how it was that one fixity declaration affects two separate definitions, and I had to explain this very conundrum.
> 
> Manuel writes:
>> I am strongly against this proposal. User-defined fixities are already a feature that needs to be used with care, carrying the danger that the user of an API with ample operators with custom fixities needs to memorise many, often somewhat arbitrary numbers (i.e., precedence levels).
> 
> I agree here -- fixities are possible to abuse horribly and are difficult to work with.
> 
>> Using different fixity declarations for the same operator name on the value and type level seems a sure way to increase confusion.
> 
> Yet here I disagree: I reject the notion of the "same operator". A definition (data a :*: b = a :*: b) defines two operators that have the same spelling, just like (data T a b = T a b) defines two identifiers spelled "T". Note that the two (:*:)s have different types, just like the two `T`s. I don't sit comfortably calling two things with different types the "same". :)
> 
> Could this new feature proposed be abused? Absolutely. But I don't think the potential for abuse should stop us, given that library-writers already have abused everything in sight -- and sometimes to good effect! (For example, the original HList is an abuse of functional dependencies but has spawned an entire cottage industry of type-level shenanigans.)
> 
> I should also address why I care about this: Since its inception, Haskell has had the ability to use the same name in types as in terms. I think for much of this time, the type/term boundary wasn't seen so much as a pair of namespaces as essentially two different languages. Some set of constructs was available in terms, and a different set was available in types. Because they were separate languages, it was natural for them to have separate namespaces. And it might even be reasonable to talk about the "same" construct existing in both. After all, of course the constructs aren't *really* the same, as they exist in different languages. (Much like when we say that () is the same as C's void... but of course they're not *really* the same.)
> 
> Now, however, with the advent of DataKinds and TypeInType, we are actively blurring the separation between the languages. Yet we still allow constructs like "data T = T". So we need a new way of thinking about such declarations to stop us from getting confused -- and my approach is to consider that Haskell simply has two namespaces. (Actually, it has more than that, given that lower-case names live apart from upper-case ones. But I digress.) Namespaces are a relatively ubiquitous concept in programming, and so the situation can be easily explained and learned. I have been pushing my model of namespaces in talking about the ' used to write data constructors in types as a namespace selection operator, not a "promotion" operator.
> 
> The current status quo of fixity declarations pierces a hole in this model of Haskell's namespaces. And so I find it quite distasteful and wish to patch the hole.
> 
> (I hope I don't need to say that, of course, I'll go along with a majority vote on the matter and move on to those other raw fish, should my little manifesto here not win the day.)
> 
> Thanks for reading,
> Richard
> 
> 
>> 
>> 
>> On Sep 20, 2017, at 12:31 PM, Christopher Allen <cma at bitemyapp.com> wrote:
>> 
>> I concur with Manuel and Joachim's reasons for rejection, if we're
>> headed to a vote.
>> 
>> On Wed, Sep 20, 2017 at 11:23 AM, Joachim Breitner
>> <mail at joachim-breitner.de> wrote:
>>> Hi,
>>> 
>>> the type fixity proposal
>>> (https://github.com/ghc-proposals/ghc-proposals/pull/65)
>>> was met with mixed reactions.
>>> 
>>> * I recommended rejection and Manuel strongly agrees with me.
>>> * SPJ does not have strong opinions either way.
>>> * Richard is in favor, and Iavor agrees.
>>> 
>>> 
>>> Our process says “If consensus is elusive, then we vote, with the
>>> Simons retaining veto power.” It looks like this might be such a case.
>>> Should we go ahead and vote, or is more discussion likely to sway some
>>> of us?
>>> 
>>> (I guess I can be swayed towards acceptance, especially if this
>>> proposal re-uses existing syntactic idioms from export lists with
>>> ExplicitNamespaces on.)
>>> 
>>> Greetings,
>>> Joachim
>>> 
>>> 
>>> 
>>> Am Sonntag, den 27.08.2017, 20:16 +0200 schrieb Joachim Breitner:
>>>> Dear Committee,
>>>> 
>>>> Ryan Scott’s proposal to allow fixity declaration to explicitly target
>>>> values or types has been brought before us:
>>>> https://github.com/RyanGlScott/ghc-proposals/blob/type-infix/0000-type-infix.rst
>>>> https://github.com/ghc-proposals/ghc-proposals/pull/65
>>>> 
>>>> I (the secretary) nominates myself as the shepherd, so I can right away
>>>> continue giving a recommendation.
>>>> 
>>>> I propose to reject this proposal. The main reasons are:
>>>> * it is not clear if there is a real use case for this. Has anyone
>>>>  ever complained about the status quo?
>>>>  The proposal does not motivate the need for a change well enough.
>>>>  (There is a related bug in TH, but that bug can probably simply be
>>>>  fixed.)
>>>> * The status quo can be sold as a feature, rather than a short-coming.
>>>>  Namely that an operator has a fixed fixity, no matter what namespace
>>>>  it lives in.
>>>>  This matches morally what other languages do: In Gallina, fixity
>>>>  is assigned to names independent of their definition, AFAIK.
>>>> * There is a non-trivial implementation and education overhead, a
>>>>  weight that is not pulled by the gains.
>>>> 
>>>> If we’d design Haskell from scratch, my verdict might possibly be
>>>> different (but maybe we wouldn’t even allow types and values to share
>>>> names then…)
>>>> 
>>>> 
>>>> Please contradict me or indicate consensus by staying silent.
>>>> 
>>>> 
>>>> Greetings,
>>>> Joachim
>>>> 
>>>> _______________________________________________
>>>> 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/
>>> 
>>> --
>>> Joachim “nomeata” Breitner
>>> mail at joachim-breitner.de
>>> https://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
>> _______________________________________________
>> 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 marlowsd at gmail.com  Thu Sep 21 07:46:14 2017
From: marlowsd at gmail.com (Simon Marlow)
Date: Thu, 21 Sep 2017 08:46:14 +0100
Subject: [ghc-steering-committee] Proposal: Type Fixity (#65),
 Recommendation: Reject
In-Reply-To: <1505924631.5913.14.camel@joachim-breitner.de>
References: <1503857788.4643.2.camel@joachim-breitner.de>
 <1505924631.5913.14.camel@joachim-breitner.de>
Message-ID: <CANsrgPJgsXyosBwyOJY3K7py7=U56dfJ80QT5O-7cOajMePDXA@mail.gmail.com>

I don't have strong opinions on this proposal, but I suppose I'm weakly in
favour because there's no reason to expect that the natural fixity for an
operator used at the type level should be the same as the operator used at
the value level.  On the other hand, it seems like a fix for a very narrow
problem, so I agree with Joachim's point that the motivation to make a
change here seems weak.

However, if we do accept the proposal, it should have its own extension
rather than being part of ExplicitNamespaces, for the reasons discussed
earlier: code needs a way to declare that it is using a new extension, so
that it can properly be rejected by older versions of the compiler that
don't support the extension.

Cheers
Simon

On 20 September 2017 at 17:23, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Hi,
>
> the type fixity proposal
> (https://github.com/ghc-proposals/ghc-proposals/pull/65)
> was met with mixed reactions.
>
>  * I recommended rejection and Manuel strongly agrees with me.
>  * SPJ does not have strong opinions either way.
>  * Richard is in favor, and Iavor agrees.
>
>
> Our process says “If consensus is elusive, then we vote, with the
> Simons retaining veto power.” It looks like this might be such a case.
> Should we go ahead and vote, or is more discussion likely to sway some
> of us?
>
> (I guess I can be swayed towards acceptance, especially if this
> proposal re-uses existing syntactic idioms from export lists with
> ExplicitNamespaces on.)
>
> Greetings,
> Joachim
>
>
>
> Am Sonntag, den 27.08.2017, 20:16 +0200 schrieb Joachim Breitner:
> > Dear Committee,
> >
> > Ryan Scott’s proposal to allow fixity declaration to explicitly target
> > values or types has been brought before us:
> > https://github.com/RyanGlScott/ghc-proposals/blob/type-infix/0000-type-
> infix.rst
> > https://github.com/ghc-proposals/ghc-proposals/pull/65
> >
> > I (the secretary) nominates myself as the shepherd, so I can right away
> > continue giving a recommendation.
> >
> > I propose to reject this proposal. The main reasons are:
> >  * it is not clear if there is a real use case for this. Has anyone
> >    ever complained about the status quo?
> >    The proposal does not motivate the need for a change well enough.
> >    (There is a related bug in TH, but that bug can probably simply be
> >    fixed.)
> >  * The status quo can be sold as a feature, rather than a short-coming.
> >    Namely that an operator has a fixed fixity, no matter what namespace
> >    it lives in.
> >    This matches morally what other languages do: In Gallina, fixity
> >    is assigned to names independent of their definition, AFAIK.
> >  * There is a non-trivial implementation and education overhead, a
> >    weight that is not pulled by the gains.
> >
> > If we’d design Haskell from scratch, my verdict might possibly be
> > different (but maybe we wouldn’t even allow types and values to share
> > names then…)
> >
> >
> > Please contradict me or indicate consensus by staying silent.
> >
> >
> > Greetings,
> > Joachim
> >
> > _______________________________________________
> > 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/
>
> --
> Joachim “nomeata” Breitner
>   mail at joachim-breitner.de
>   https://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/20170921/1a66d980/attachment.html>

From simonpj at microsoft.com  Thu Sep 21 09:00:58 2017
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 21 Sep 2017 09:00:58 +0000
Subject: [ghc-steering-committee] Proposal: Type Fixity (#65),
 Recommendation: Reject
In-Reply-To: <1505924631.5913.14.camel@joachim-breitner.de>
References: <1503857788.4643.2.camel@joachim-breitner.de>
 <1505924631.5913.14.camel@joachim-breitner.de>
Message-ID: <HE1PR83MB00423249C1BAC8056DAC32D1AD660@HE1PR83MB0042.EURPRD83.prod.outlook.com>

If you see my comment
https://github.com/ghc-proposals/ghc-proposals/pull/65#issuecomment-325301080
you'll see that I finally realised that GHC (and indeed H98) /already/ allows different fixities for term and type level.

So now I'm more supportive: it's become /solely/ a question of whether we supply concrete syntax to allow us to do something on one module that we can /already/ do (perhaps inconveniently) with two.

So I'm now mildly in favour.

Simon

|  -----Original Message-----
|  From: ghc-steering-committee [mailto:ghc-steering-committee-
|  bounces at haskell.org] On Behalf Of Joachim Breitner
|  Sent: 20 September 2017 17:24
|  To: ghc-steering-committee at haskell.org
|  Subject: Re: [ghc-steering-committee] Proposal: Type Fixity (#65),
|  Recommendation: Reject
|  
|  Hi,
|  
|  the type fixity proposal
|  (https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com
|  %2Fghc-proposals%2Fghc-
|  proposals%2Fpull%2F65&data=02%7C01%7Csimonpj%40microsoft.com%7Cc0583aed4fbd4
|  f37a40a08d500441d81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63641521490
|  8671210&sdata=%2F9oJkejSngjz%2FGy12Q%2FJlPOzzFdT%2FHD9SslPffMcA60%3D&reserve
|  d=0)
|  was met with mixed reactions.
|  
|   * I recommended rejection and Manuel strongly agrees with me.
|   * SPJ does not have strong opinions either way.
|   * Richard is in favor, and Iavor agrees.
|  
|  
|  Our process says “If consensus is elusive, then we vote, with the Simons
|  retaining veto power.” It looks like this might be such a case.
|  Should we go ahead and vote, or is more discussion likely to sway some of
|  us?
|  
|  (I guess I can be swayed towards acceptance, especially if this proposal re-
|  uses existing syntactic idioms from export lists with ExplicitNamespaces
|  on.)
|  
|  Greetings,
|  Joachim
|  
|  
|  
|  Am Sonntag, den 27.08.2017, 20:16 +0200 schrieb Joachim Breitner:
|  > Dear Committee,
|  >
|  > Ryan Scott’s proposal to allow fixity declaration to explicitly target
|  > values or types has been brought before us:
|  > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu
|  > b.com%2FRyanGlScott%2Fghc-proposals%2Fblob%2Ftype-infix%2F0000-type-in
|  > fix.rst&data=02%7C01%7Csimonpj%40microsoft.com%7Cc0583aed4fbd4f37a40a0
|  > 8d500441d81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6364152149086
|  > 71210&sdata=1qRrPKmHWYpB9XRFOHwiJT2Kwc%2B%2BOtf0vm0ibOWuTQI%3D&reserve
|  > d=0
|  > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu
|  > b.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F65&data=02%7C01%7Csimon
|  > pj%40microsoft.com%7Cc0583aed4fbd4f37a40a08d500441d81%7C72f988bf86f141
|  > af91ab2d7cd011db47%7C1%7C0%7C636415214908671210&sdata=%2F9oJkejSngjz%2
|  > FGy12Q%2FJlPOzzFdT%2FHD9SslPffMcA60%3D&reserved=0
|  >
|  > I (the secretary) nominates myself as the shepherd, so I can right
|  > away continue giving a recommendation.
|  >
|  > I propose to reject this proposal. The main reasons are:
|  >  * it is not clear if there is a real use case for this. Has anyone
|  >    ever complained about the status quo?
|  >    The proposal does not motivate the need for a change well enough.
|  >    (There is a related bug in TH, but that bug can probably simply be
|  >    fixed.)
|  >  * The status quo can be sold as a feature, rather than a short-coming.
|  >    Namely that an operator has a fixed fixity, no matter what namespace
|  >    it lives in.
|  >    This matches morally what other languages do: In Gallina, fixity
|  >    is assigned to names independent of their definition, AFAIK.
|  >  * There is a non-trivial implementation and education overhead, a
|  >    weight that is not pulled by the gains.
|  >
|  > If we’d design Haskell from scratch, my verdict might possibly be
|  > different (but maybe we wouldn’t even allow types and values to share
|  > names then…)
|  >
|  >
|  > Please contradict me or indicate consensus by staying silent.
|  >
|  >
|  > Greetings,
|  > Joachim
|  >
|  > _______________________________________________
|  > ghc-steering-committee mailing list
|  > ghc-steering-committee at haskell.org
|  > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committ
|  > ee
|  --
|  Joachim Breitner
|    mail at joachim-breitner.de
|  
|  https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-
|  breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cc0583aed4fbd4f37a40a
|  08d500441d81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636415214908671210
|  &sdata=73MgFmM8BOaWVRs4%2BMi3iLBpNcDip7g2DLVsEesYbuw%3D&reserved=0
|  
|  --
|  Joachim “nomeata” Breitner
|    mail at joachim-breitner.de
|  
|  https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.joachim
|  -
|  breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cc0583aed4fbd4f37a40a
|  08d500441d81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636415214908671210
|  &sdata=5nSTzp%2FXxt7bGfgRTY0r4qlMn83jTfv1hkTetc34ihg%3D&reserved=0

From mail at joachim-breitner.de  Thu Sep 21 13:28:20 2017
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 21 Sep 2017 09:28:20 -0400
Subject: [ghc-steering-committee] Proposal: Type Fixity (#65),
 Recommendation: Reject
In-Reply-To: <CANsrgPJgsXyosBwyOJY3K7py7=U56dfJ80QT5O-7cOajMePDXA@mail.gmail.com>
References: <1503857788.4643.2.camel@joachim-breitner.de>
 <1505924631.5913.14.camel@joachim-breitner.de>
 <CANsrgPJgsXyosBwyOJY3K7py7=U56dfJ80QT5O-7cOajMePDXA@mail.gmail.com>
Message-ID: <1506000500.973.5.camel@joachim-breitner.de>

Hi,

the vote seems to indicate acceptance so far; fine with me.

Am Donnerstag, den 21.09.2017, 08:46 +0100 schrieb Simon Marlow:
> However, if we do accept the proposal, it should have its own
> extension rather than being part of ExplicitNamespaces, for the
> reasons discussed earlier: code needs a way to declare that it is
> using a new extension, so that it can properly be rejected by older
> versions of the compiler that don't support the extension.

Earlier we discussed the question of whether we want to allow minor
changes to unextendd Haskell without extensions (and the consensus was
no). This does not imply that we forbid ourselves from extending the
range of existing GHC language pragmas.

From a user point of view, having “ExplicitNamespaces” allow me to
explicitly name the namespaces of an identifier in identifier lists
such as export, import and fixity lists is very natural. It would be
strange if I need “ExplicitNamespaces” for export and import lists, but
“ExplicitNamespacesFixities” in fixitiy lists.

I am sure others can give concrete examples where the syntax of
language extensions has evolved without introducing a wealth of new
extensions (and having to support all combinations). TemplateHaskell
splices maybe? RebindableSyntax maybe?

So is there a sensible way we can avoid fringe language extension
pragma proliferation?

Joachim

-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20170921/2c8b7b46/attachment.sig>

From marlowsd at gmail.com  Tue Sep 26 19:10:44 2017
From: marlowsd at gmail.com (Simon Marlow)
Date: Tue, 26 Sep 2017 20:10:44 +0100
Subject: [ghc-steering-committee] Proposal: Type Fixity (#65),
 Recommendation: Reject
In-Reply-To: <1506000500.973.5.camel@joachim-breitner.de>
References: <1503857788.4643.2.camel@joachim-breitner.de>
 <1505924631.5913.14.camel@joachim-breitner.de>
 <CANsrgPJgsXyosBwyOJY3K7py7=U56dfJ80QT5O-7cOajMePDXA@mail.gmail.com>
 <1506000500.973.5.camel@joachim-breitner.de>
Message-ID: <CANsrgP+4ERKvEWL-aAqVweiVNszU5FJsoi_E9nAMULK66SqLkw@mail.gmail.com>

On 21 September 2017 at 14:28, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Hi,
>
> the vote seems to indicate acceptance so far; fine with me.
>
> Am Donnerstag, den 21.09.2017, 08:46 +0100 schrieb Simon Marlow:
> > However, if we do accept the proposal, it should have its own
> > extension rather than being part of ExplicitNamespaces, for the
> > reasons discussed earlier: code needs a way to declare that it is
> > using a new extension, so that it can properly be rejected by older
> > versions of the compiler that don't support the extension.
>
> Earlier we discussed the question of whether we want to allow minor
> changes to unextendd Haskell without extensions (and the consensus was
> no). This does not imply that we forbid ourselves from extending the
> range of existing GHC language pragmas.
>
> From a user point of view, having “ExplicitNamespaces” allow me to
> explicitly name the namespaces of an identifier in identifier lists
> such as export, import and fixity lists is very natural. It would be
> strange if I need “ExplicitNamespaces” for export and import lists, but
> “ExplicitNamespacesFixities” in fixitiy lists.
>
> I am sure others can give concrete examples where the syntax of
> language extensions has evolved without introducing a wealth of new
> extensions (and having to support all combinations). TemplateHaskell
> splices maybe? RebindableSyntax maybe?
>

It's a tradeoff and we could go either way, but I'll argue for being strict
here. Suppose we have some code that uses the new extension and I compile
it with GHC 8.2. The choice is between:

* without a new extension flag, GHC says "Parse error"
* with a new extension flag, GHC says "Extension not supported", and in
fact we might not even get that far because our tooling might tell us that
we can't compile this code before we even try. Or Cabal could choose a
different (and supported) version of the package instead.

It's a choice between having metadata and a bit of extra work, vs. having
no metadata and things sometimes failing.


> So is there a sensible way we can avoid fringe language extension
> pragma proliferation?
>

yes there is, it's called Haskell Prime :)

Cheers
Simon


> 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/20170926/4ce0b033/attachment.html>

From mail at joachim-breitner.de  Tue Sep 26 23:22:31 2017
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 26 Sep 2017 19:22:31 -0400
Subject: [ghc-steering-committee] Proposal: Type Fixity (#65),
 Recommendation: Reject
In-Reply-To: <CANsrgP+4ERKvEWL-aAqVweiVNszU5FJsoi_E9nAMULK66SqLkw@mail.gmail.com>
References: <1503857788.4643.2.camel@joachim-breitner.de>
 <1505924631.5913.14.camel@joachim-breitner.de>
 <CANsrgPJgsXyosBwyOJY3K7py7=U56dfJ80QT5O-7cOajMePDXA@mail.gmail.com>
 <1506000500.973.5.camel@joachim-breitner.de>
 <CANsrgP+4ERKvEWL-aAqVweiVNszU5FJsoi_E9nAMULK66SqLkw@mail.gmail.com>
Message-ID: <1506468151.8579.3.camel@joachim-breitner.de>

Hi,

Am Dienstag, den 26.09.2017, 20:10 +0100 schrieb Simon Marlow:
> It's a tradeoff and we could go either way, but I'll argue for being
> strict here. Suppose we have some code that uses the new extension
> and I compile it with GHC 8.2. The choice is between:
> 
> * without a new extension flag, GHC says "Parse error"
> * with a new extension flag, GHC says "Extension not supported", and in fact we might not even get that far because our tooling might tell us that we can't compile this code before we even try. Or Cabal could choose a different (and supported) version of the package instead.
> 
> It's a choice between having metadata and a bit of extra work, vs.
> having no metadata and things sometimes failing.

it is also a choice between

* extensions are testbeds and playgrounds for language extensions
* extensions are what people build their products with

I guess at some point, the former was true, and it was so successful
that the second became true.

I’d be sad if this leads to language extensions having to live up to
the expectations to be perfect right from the start, and not be allowed
to improve over a few releases. But I see the benefit of stability. Is
it feasible to communicate their stability somehow?

Joachim


-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20170926/4d11fca1/attachment.sig>

From rae at cs.brynmawr.edu  Wed Sep 27 19:06:50 2017
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Wed, 27 Sep 2017 15:06:50 -0400
Subject: [ghc-steering-committee] Proposal: Type Fixity (#65),
	Recommendation: Reject
In-Reply-To: <1506468151.8579.3.camel@joachim-breitner.de>
References: <1503857788.4643.2.camel@joachim-breitner.de>
 <1505924631.5913.14.camel@joachim-breitner.de>
 <CANsrgPJgsXyosBwyOJY3K7py7=U56dfJ80QT5O-7cOajMePDXA@mail.gmail.com>
 <1506000500.973.5.camel@joachim-breitner.de>
 <CANsrgP+4ERKvEWL-aAqVweiVNszU5FJsoi_E9nAMULK66SqLkw@mail.gmail.com>
 <1506468151.8579.3.camel@joachim-breitner.de>
Message-ID: <D3028695-B6C9-4AC7-BCC4-CD84F5A81D28@cs.brynmawr.edu>

What if extensions had an optional version number? This would be feature supported only in cabal, not really in GHC. For example, a cabal file could include

  other-extensions: TypeOperators >= 2

to say that it needs version 2 of the TypeOperators extension. GHC would need a way of telling cabal which versions of which extension it supports, but that’s it. (In other words, users couldn’t say “-XTypeOperators-1” as separate from “-XTypeOperators-2” or anything.)

That would seem to solve the problem in a way that’s unobtrusive to most users and yet convenient enough for people who want fine-grained control. Is it too heavy, though?

Richard

> On Sep 26, 2017, at 7:22 PM, Joachim Breitner <mail at joachim-breitner.de> wrote:
> 
> Hi,
> 
> Am Dienstag, den 26.09.2017, 20:10 +0100 schrieb Simon Marlow:
>> It's a tradeoff and we could go either way, but I'll argue for being
>> strict here. Suppose we have some code that uses the new extension
>> and I compile it with GHC 8.2. The choice is between:
>> 
>> * without a new extension flag, GHC says "Parse error"
>> * with a new extension flag, GHC says "Extension not supported", and in fact we might not even get that far because our tooling might tell us that we can't compile this code before we even try. Or Cabal could choose a different (and supported) version of the package instead.
>> 
>> It's a choice between having metadata and a bit of extra work, vs.
>> having no metadata and things sometimes failing.
> 
> it is also a choice between
> 
> * extensions are testbeds and playgrounds for language extensions
> * extensions are what people build their products with
> 
> I guess at some point, the former was true, and it was so successful
> that the second became true.
> 
> I’d be sad if this leads to language extensions having to live up to
> the expectations to be perfect right from the start, and not be allowed
> to improve over a few releases. But I see the benefit of stability. Is
> it feasible to communicate their stability somehow?
> 
> 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