From mail at joachim-breitner.de  Sat May  6 21:57:12 2017
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sat, 06 May 2017 17:57:12 -0400
Subject: [ghc-steering-committee] Status
Message-ID: <1494107832.25085.5.camel@joachim-breitner.de>

[Please do not reply to this mail discussing individual proposals.
Instead, reply to the appropriate thread, or start a new one.]

Hi,

currently under discussion are:

Eval class
https://github.com/ghc-proposals/ghc-proposals/pull/27
Shepherd: Richard
Status: This came back after being sent to the author for revision.
We are waiting for Richard to make a new decision suggestion.

Force Instance
https://github.com/ghc-proposals/ghc-proposals/pull/23
Shepherd: Manuel
Status: Manuel suggests rejection, which is generally agreed by the
committee.
Manuel, I believe you can go ahead and reject the proposal, ideally
with a short rationale.

UNPACK on function arguments
https://github.com/ghc-proposals/ghc-proposals/pull/46
Shepherd: Simon Marlow
Status: Awaiting a recommendation from Simon


Also still TODO (for Ben):

Add @rleshchinskiy to the GitHub organization and remove @atzedijkstra
https://github.com/orgs/ghc-proposals/people
(or make me an owner there).

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/20170506/f9d63535/attachment.sig>

From ben at well-typed.com  Sat May  6 22:56:43 2017
From: ben at well-typed.com (Ben Gamari)
Date: Sat, 06 May 2017 18:56:43 -0400
Subject: [ghc-steering-committee] Status
In-Reply-To: <1494107832.25085.5.camel@joachim-breitner.de>
References: <1494107832.25085.5.camel@joachim-breitner.de>
Message-ID: <87y3u9iogk.fsf@ben-laptop.smart-cactus.org>

Joachim Breitner <mail at joachim-breitner.de> writes:

> [Please do not reply to this mail discussing individual proposals.
> Instead, reply to the appropriate thread, or start a new one.]
>
> Hi,
>
> currently under discussion are:
>
> Eval class
> https://github.com/ghc-proposals/ghc-proposals/pull/27
> Shepherd: Richard
> Status: This came back after being sent to the author for revision.
> We are waiting for Richard to make a new decision suggestion.
>
> Force Instance
> https://github.com/ghc-proposals/ghc-proposals/pull/23
> Shepherd: Manuel
> Status: Manuel suggests rejection, which is generally agreed by the
> committee.
> Manuel, I believe you can go ahead and reject the proposal, ideally
> with a short rationale.
>
> UNPACK on function arguments
> https://github.com/ghc-proposals/ghc-proposals/pull/46
> Shepherd: Simon Marlow
> Status: Awaiting a recommendation from Simon
>
>
> Also still TODO (for Ben):
>
> Add @rleshchinskiy to the GitHub organization and remove @atzedijkstra
> https://github.com/orgs/ghc-proposals/people
> (or make me an owner there).
>
Done. Thanks for the reminder, Joachim!

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20170506/d9c3ffd9/attachment.sig>

From marlowsd at gmail.com  Mon May  8 08:51:33 2017
From: marlowsd at gmail.com (Simon Marlow)
Date: Mon, 8 May 2017 09:51:33 +0100
Subject: [ghc-steering-committee] Proposal #46: NOUNPACK pragmas for
	function arguments
Message-ID: <CANsrgPJdUbqxLOuSebW94NWKRZOObQyLW5+oPW_HR-AnuD2vJg@mail.gmail.com>

https://github.com/ghc-proposals/ghc-proposals/pull/46

I tentatively propose that we accept this proposal.

Briefly, the proposal is to allow a NOUNPACK pragma in a *type signature*
to indicate that a value should not be unpacked by the worker-wrapper
transformation, e.g.:

insertR :: Ord k => {-# NOUNPACK #-} k -> v -> Map k v -> Map k v
insertR k v m = go k k v m
  where
    go :: Ord k => {-# NOUNPACK #-} k -> k -> v -> Map k v -> Map k v
    go kp k v m = ...

The idea is that sometimes unpacking a strict argument leads to worse code
because the repacking doesn't get simplified away, and it's hard for
worker-wrapper to tell that up front. It's quite difficult for the
programmer to avoid this problem currently - the one trick we have
available is the `lazy` pseudo-function, but that's difficult to use for
this purpose because you have to ensure that *all* uses of the argument are
made lazy, and there can be collateral damage.  It's the wrong tool to
solve this problem, but it's the only tool we have.

I've had this issue personally, and I've worked around it with `lazy`, but
it's an ugly and brittle workaround, and something better is needed.

If we assume that NOUNPACK can only occur on the left of an arrow (rather
like UNPACK/NOUNPACK in a GADT signature), then it's a fairly
straightforward extension, and just requires plumbing the information
through to the demand analyser / worker-wrapper.

The dual UNPACK annotation also makes sense, I think, although it's not
part of this proposal.  I can imagine it being a future extension.

Drawbacks I see:
- It doesn't let you say anything more detailed than just "no", e.g. you
can't say "don't unpack the first field of the record"
- It requires a type signature, which you wouldn't otherwise need.  I
suppose you could use PartialTypeSignatures.
- It doesn't let you say anything about strictness, only unpacking.  If a
NOUNPACK argument is inferred by the demand analyser to be strict, callers
can use call-by-value.

Overall I don't see any fatal flaws and there are benefits. It's not a
beautiful extension by any means, but I don't think it's expensive or
complicated to implement.  I suggest we accept it.  Thoughts?

Cheers
Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20170508/372793c6/attachment.html>

From simonpj at microsoft.com  Mon May  8 12:21:16 2017
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 8 May 2017 12:21:16 +0000
Subject: [ghc-steering-committee] Proposal #46: NOUNPACK pragmas
	for	function arguments
In-Reply-To: <CANsrgPJdUbqxLOuSebW94NWKRZOObQyLW5+oPW_HR-AnuD2vJg@mail.gmail.com>
References: <CANsrgPJdUbqxLOuSebW94NWKRZOObQyLW5+oPW_HR-AnuD2vJg@mail.gmail.com>
Message-ID: <DM2PR21MB0028063485D259430B516B40ADEE0@DM2PR21MB0028.namprd21.prod.outlook.com>

I’m mildly against.  I see the motivation but I’m doubtful that this is the way to achieve it.  See my comment on the ticket.

Simon

From: ghc-steering-committee [mailto:ghc-steering-committee-bounces at haskell.org] On Behalf Of Simon Marlow
Sent: 08 May 2017 09:52
To: ghc-steering-committee at haskell.org
Subject: [ghc-steering-committee] Proposal #46: NOUNPACK pragmas for function arguments

https://github.com/ghc-proposals/ghc-proposals/pull/46<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F46&data=02%7C01%7Csimonpj%40microsoft.com%7C09b74fabee624f440e5308d495efb547%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636298304152679025&sdata=SbVC4Kd2xTK%2F%2BNtlC5w5JBTWKJSKzTD79Kttde0OjM4%3D&reserved=0>

I tentatively propose that we accept this proposal.

Briefly, the proposal is to allow a NOUNPACK pragma in a *type signature* to indicate that a value should not be unpacked by the worker-wrapper transformation, e.g.:

insertR :: Ord k => {-# NOUNPACK #-} k -> v -> Map k v -> Map k v
insertR k v m = go k k v m
  where
    go :: Ord k => {-# NOUNPACK #-} k -> k -> v -> Map k v -> Map k v
    go kp k v m = ...

The idea is that sometimes unpacking a strict argument leads to worse code because the repacking doesn't get simplified away, and it's hard for worker-wrapper to tell that up front. It's quite difficult for the programmer to avoid this problem currently - the one trick we have available is the `lazy` pseudo-function, but that's difficult to use for this purpose because you have to ensure that *all* uses of the argument are made lazy, and there can be collateral damage.  It's the wrong tool to solve this problem, but it's the only tool we have.

I've had this issue personally, and I've worked around it with `lazy`, but it's an ugly and brittle workaround, and something better is needed.

If we assume that NOUNPACK can only occur on the left of an arrow (rather like UNPACK/NOUNPACK in a GADT signature), then it's a fairly straightforward extension, and just requires plumbing the information through to the demand analyser / worker-wrapper.

The dual UNPACK annotation also makes sense, I think, although it's not part of this proposal.  I can imagine it being a future extension.

Drawbacks I see:
- It doesn't let you say anything more detailed than just "no", e.g. you can't say "don't unpack the first field of the record"
- It requires a type signature, which you wouldn't otherwise need.  I suppose you could use PartialTypeSignatures.
- It doesn't let you say anything about strictness, only unpacking.  If a NOUNPACK argument is inferred by the demand analyser to be strict, callers can use call-by-value.

Overall I don't see any fatal flaws and there are benefits. It's not a beautiful extension by any means, but I don't think it's expensive or complicated to implement.  I suggest we accept it.  Thoughts?

Cheers
Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20170508/684b0016/attachment-0001.html>

From iavor.diatchki at gmail.com  Tue May 16 17:19:32 2017
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Tue, 16 May 2017 10:19:32 -0700
Subject: [ghc-steering-committee] Proposal: Reject #44 NoIfThenElse
Message-ID: <CAGK9nuoBcU3+dr5SNBBeE7ZKH922WJgB=ScOaWTVe7CTvX5peQ@mail.gmail.com>

Hello,

I'd like to propose that we reject that NoIfThenElse proposal (#44).   In
short, it suggests that we remove the syntactic sugar for `if-then-else`
and leave to programmers to define their own version as a function.

I think that this has virtually no benefits and many draw-backs, including
breaking existing code, and making programs more difficult to read.

Would there be any objections if I was to mark this as rejected, and close
the request?

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

From iavor.diatchki at gmail.com  Tue May 16 17:19:32 2017
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Tue, 16 May 2017 10:19:32 -0700
Subject: [ghc-steering-committee] Proposal: Reject #44 NoIfThenElse
Message-ID: <CAGK9nuoBcU3+dr5SNBBeE7ZKH922WJgB=ScOaWTVe7CTvX5peQ@mail.gmail.com>

Hello,

I'd like to propose that we reject that NoIfThenElse proposal (#44).   In
short, it suggests that we remove the syntactic sugar for `if-then-else`
and leave to programmers to define their own version as a function.

I think that this has virtually no benefits and many draw-backs, including
breaking existing code, and making programs more difficult to read.

Would there be any objections if I was to mark this as rejected, and close
the request?

-Iavor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20170516/7e85feb3/attachment-0001.html>

From cma at bitemyapp.com  Tue May 16 17:21:28 2017
From: cma at bitemyapp.com (Christopher Allen)
Date: Tue, 16 May 2017 12:21:28 -0500
Subject: [ghc-steering-committee] Proposal: Reject #44 NoIfThenElse
In-Reply-To: <CAGK9nuoBcU3+dr5SNBBeE7ZKH922WJgB=ScOaWTVe7CTvX5peQ@mail.gmail.com>
References: <CAGK9nuoBcU3+dr5SNBBeE7ZKH922WJgB=ScOaWTVe7CTvX5peQ@mail.gmail.com>
Message-ID: <CADnndOrKEo_C2ra41cuJZ93KmFKZ4NiBwBL=ZQVsy6E7qz+1DA@mail.gmail.com>

No objections, I believe it should be rejected too.

On Tue, May 16, 2017 at 12:19 PM, Iavor Diatchki
<iavor.diatchki at gmail.com> wrote:
> Hello,
>
> I'd like to propose that we reject that NoIfThenElse proposal (#44).   In
> short, it suggests that we remove the syntactic sugar for `if-then-else` and
> leave to programmers to define their own version as a function.
>
> I think that this has virtually no benefits and many draw-backs, including
> breaking existing code, and making programs more difficult to read.
>
> Would there be any objections if I was to mark this as rejected, and close
> the request?
>
> -Iavor
>
> _______________________________________________
> 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  Tue May 16 18:21:53 2017
From: marlowsd at gmail.com (Simon Marlow)
Date: Tue, 16 May 2017 19:21:53 +0100
Subject: [ghc-steering-committee] Proposal: Reject #44 NoIfThenElse
In-Reply-To: <CAGK9nuoBcU3+dr5SNBBeE7ZKH922WJgB=ScOaWTVe7CTvX5peQ@mail.gmail.com>
References: <CAGK9nuoBcU3+dr5SNBBeE7ZKH922WJgB=ScOaWTVe7CTvX5peQ@mail.gmail.com>
Message-ID: <CANsrgPKyhLSDE4nKQTXroGEwDRtkAEgceCdF0_keCL5RDN1k=g@mail.gmail.com>

Agreed.

On 16 May 2017 at 18:19, Iavor Diatchki <iavor.diatchki at gmail.com> wrote:

> Hello,
>
> I'd like to propose that we reject that NoIfThenElse proposal (#44).   In
> short, it suggests that we remove the syntactic sugar for `if-then-else`
> and leave to programmers to define their own version as a function.
>
> I think that this has virtually no benefits and many draw-backs, including
> breaking existing code, and making programs more difficult to read.
>
> Would there be any objections if I was to mark this as rejected, and close
> the request?
>
> -Iavor
>
> _______________________________________________
> 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/20170516/7ce2953c/attachment.html>

From chak at justtesting.org  Tue May 16 23:01:22 2017
From: chak at justtesting.org (Manuel M T Chakravarty)
Date: Wed, 17 May 2017 09:01:22 +1000
Subject: [ghc-steering-committee] Proposal: Reject #44 NoIfThenElse
In-Reply-To: <CAGK9nuoBcU3+dr5SNBBeE7ZKH922WJgB=ScOaWTVe7CTvX5peQ@mail.gmail.com>
References: <CAGK9nuoBcU3+dr5SNBBeE7ZKH922WJgB=ScOaWTVe7CTvX5peQ@mail.gmail.com>
Message-ID: <5E19F5D8-4F3E-4A28-AC20-29C2A5043D13@justtesting.org>

Completely agree.

Manuel

> Iavor Diatchki <iavor.diatchki at gmail.com>:
> 
> Hello,
> 
> I'd like to propose that we reject that NoIfThenElse proposal (#44).   In short, it suggests that we remove the syntactic sugar for `if-then-else` and leave to programmers to define their own version as a function.
> 
> I think that this has virtually no benefits and many draw-backs, including breaking existing code, and making programs more difficult to read.
> 
> Would there be any objections if I was to mark this as rejected, and close the request?
> 
> -Iavor
> _______________________________________________
> 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  Tue May 16 23:14:56 2017
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 16 May 2017 19:14:56 -0400
Subject: [ghc-steering-committee] Proposal: Reject #44 NoIfThenElse
In-Reply-To: <CAGK9nuoBcU3+dr5SNBBeE7ZKH922WJgB=ScOaWTVe7CTvX5peQ@mail.gmail.com>
References: <CAGK9nuoBcU3+dr5SNBBeE7ZKH922WJgB=ScOaWTVe7CTvX5peQ@mail.gmail.com>
Message-ID: <1494976496.12525.1.camel@joachim-breitner.de>

Hi,

Am Dienstag, den 16.05.2017, 10:19 -0700 schrieb Iavor Diatchki:
> I'd like to propose that we reject that NoIfThenElse proposal (#44).

proceduraly, this is not required. This proposal never made it out of
the discussion phase, and is actually “dormant” right now (together
with plenty of other proposals that never made it out of the discussion
procedure). While everyone is free to voice their opinions on such
proposals, the comment section on the pull request is more appropriate
for that. Likely, the author might eventually withdraws the proposal.

Note that dormant proposals do not even show up in the
“List of proposals under discussion” linked from 
https://github.com/ghc-proposals/ghc-proposals.

If you are curious what actually is on the committee’s plate right now,
this would be the following.

Eval class
https://github.com/ghc-proposals/ghc-proposals/pull/27
Shepherd: Richard
Status: This came back after being sent to the author for revision.
We are waiting for Richard to make a new decision suggestion.

Force Instance
https://github.com/ghc-proposals/ghc-proposals/pull/23
Shepherd: Manuel
Status: Manuel suggests rejection, which is generally agreed by the
committee.
Manuel, I believe you can go ahead and reject the proposal, ideally
with a short rationale.

UNPACK on function arguments
https://github.com/ghc-proposals/ghc-proposals/pull/46
Shepherd: Simon Marlow
Status: Awaiting a recommendation from Simon


Greetings,
Joachim

-- 
Joachim “nomeata” Breitner
  mail at joachim-breitner.de • https://www.joachim-breitner.de/
  XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F
  Debian Developer: nomeata at debian.org
-------------- 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/20170516/27a5ae55/attachment.sig>

From iavor.diatchki at gmail.com  Tue May 16 23:46:11 2017
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Tue, 16 May 2017 16:46:11 -0700
Subject: [ghc-steering-committee] Proposal: Reject #44 NoIfThenElse
In-Reply-To: <1494976496.12525.1.camel@joachim-breitner.de>
References: <CAGK9nuoBcU3+dr5SNBBeE7ZKH922WJgB=ScOaWTVe7CTvX5peQ@mail.gmail.com>
 <1494976496.12525.1.camel@joachim-breitner.de>
Message-ID: <CAGK9nuq5oTd0-L40pWcZaTABFmNH_VCWnB-=6C_tDKN0TdgLnw@mail.gmail.com>

Ah, good to know, sorry for the noise.   Usually, when I want to look at
the proposals I just go to the "Pull requests" tab, and I was noticing that
we are accumulating a bunch of proposals that seem to be going nowhere, so
I was thinking we could close some of them.




On Tue, May 16, 2017 at 4:14 PM, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Hi,
>
> Am Dienstag, den 16.05.2017, 10:19 -0700 schrieb Iavor Diatchki:
> > I'd like to propose that we reject that NoIfThenElse proposal (#44).
>
> proceduraly, this is not required. This proposal never made it out of
> the discussion phase, and is actually “dormant” right now (together
> with plenty of other proposals that never made it out of the discussion
> procedure). While everyone is free to voice their opinions on such
> proposals, the comment section on the pull request is more appropriate
> for that. Likely, the author might eventually withdraws the proposal.
>
> Note that dormant proposals do not even show up in the
> “List of proposals under discussion” linked from
> https://github.com/ghc-proposals/ghc-proposals.
>
> If you are curious what actually is on the committee’s plate right now,
> this would be the following.
>
> Eval class
> https://github.com/ghc-proposals/ghc-proposals/pull/27
> Shepherd: Richard
> Status: This came back after being sent to the author for revision.
> We are waiting for Richard to make a new decision suggestion.
>
> Force Instance
> https://github.com/ghc-proposals/ghc-proposals/pull/23
> Shepherd: Manuel
> Status: Manuel suggests rejection, which is generally agreed by the
> committee.
> Manuel, I believe you can go ahead and reject the proposal, ideally
> with a short rationale.
>
> UNPACK on function arguments
> https://github.com/ghc-proposals/ghc-proposals/pull/46
> Shepherd: Simon Marlow
> Status: Awaiting a recommendation from Simon
>
>
> Greetings,
> Joachim
>
> --
> Joachim “nomeata” Breitner
>   mail at joachim-breitner.de • https://www.joachim-breitner.de/
>   XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F
>   Debian Developer: nomeata at debian.org
> _______________________________________________
> 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/20170516/e6a48cdb/attachment-0001.html>

From mail at joachim-breitner.de  Tue May 16 23:54:09 2017
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 16 May 2017 19:54:09 -0400
Subject: [ghc-steering-committee] Proposal: Reject #44 NoIfThenElse
In-Reply-To: <CAGK9nuq5oTd0-L40pWcZaTABFmNH_VCWnB-=6C_tDKN0TdgLnw@mail.gmail.com>
References: <CAGK9nuoBcU3+dr5SNBBeE7ZKH922WJgB=ScOaWTVe7CTvX5peQ@mail.gmail.com>
 <1494976496.12525.1.camel@joachim-breitner.de>
 <CAGK9nuq5oTd0-L40pWcZaTABFmNH_VCWnB-=6C_tDKN0TdgLnw@mail.gmail.com>
Message-ID: <1494978849.12525.3.camel@joachim-breitner.de>

Hi,

Am Dienstag, den 16.05.2017, 16:46 -0700 schrieb Iavor Diatchki:
> Ah, good to know, sorry for the noise.   Usually, when I want to look
> at the proposals I just go to the "Pull requests" tab, and I was
> noticing that we are accumulating a bunch of proposals that seem to
> be going nowhere, so I was thinking we could close some of them.

I understand that urge. I occasionally ask authors to close their PRs
if they are dormant, and I now marked them as dormant. I avoid simply
closing the PRs for reasons of superficial friendliness.

Feel free to simply ignore anything marked dormant, or Needs Revision.

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/20170516/3ee9487e/attachment.sig>

From chak at justtesting.org  Thu May 25 00:08:29 2017
From: chak at justtesting.org (Manuel M T Chakravarty)
Date: Thu, 25 May 2017 10:08:29 +1000
Subject: [ghc-steering-committee] Proposal #23: instance force: rejected
Message-ID: <EE8F984D-AFA1-444F-8D15-5B765D6BC42D@justtesting.org>

Based on the feedback received on the ”instance force” proposal

 https://github.com/ghc-proposals/ghc-proposals/pull/23

I conclude that the committee has decided to reject that proposal in its current form.

In summary, we agree that the proposal tries to address a real problem, namely

(1) to add additional constraints to simplify diagnostics and type queries (especially for teaching) as well as

(2) specify a local default for classes like ’IsString’.

However, we don’t think that the proposed mechanism is the right one to address this problem, and we should try to find a better solution. In summary the power-to-weight ratio of the proposal is not sufficient; specifically,

* Problem (1) might be solved better outside of the language (e.g., with a compiler option or similar);

* Problem (2) only seems to be solved partially; and

* there remain questions about details concerning the type system and import/exports.

Manuel


From mail at joachim-breitner.de  Thu May 25 02:15:14 2017
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 24 May 2017 22:15:14 -0400
Subject: [ghc-steering-committee] Status
Message-ID: <1495678514.16457.3.camel@joachim-breitner.de>

[Please do not reply to this mail discussing individual proposals.
Instead, reply to the appropriate thread, or start a new one.]

Hi,

just another status update:

We just rejected the instance force proposal.

Open at the moment are:

Eval class
https://github.com/ghc-proposals/ghc-proposals/pull/27
Shepherd: Richard
Status: This came back after being sent to the author for revision.
We are waiting for Richard to make a new decision suggestion.

UNPACK on function arguments
https://github.com/ghc-proposals/ghc-proposals/pull/46
Shepherd: Simon Marlow
Status: Awaiting a recommendation from Simon


Greetings,
Joachim

-- 
Joachim “nomeata” Breitner
  mail at joachim-breitner.de • https://www.joachim-breitner.de/
  XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F
  Debian Developer: nomeata at debian.org
-------------- 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/20170524/937e492f/attachment.sig>

From david.feuer at gmail.com  Thu May 25 05:27:42 2017
From: david.feuer at gmail.com (David Feuer)
Date: Thu, 25 May 2017 01:27:42 -0400
Subject: [ghc-steering-committee] GHC proposal #5
Message-ID: <CAMgWh9v5u8ExGYsF-9zWEspR1OydrJGLVoYZw8JwCF5=GH8uaQ@mail.gmail.com>

GHC proposal  #5 [*], which I drafted, was recently merged. I was
asked to modify the proposal to restrict the type signatures of
patterns and builders to be the same, except for their contexts. I
would like to make one last plea to remove this restriction, unless
there are fundamental reasons it cannot be done. The reasons are as
follows.

1. Despite the restriction, it remains possible, at least in many
cases, to achieve exactly the same effect, albeit in a manner that is
considerably more difficult to read. For example, one could write the
following (ill-advised) pattern:

pattern Ha :: a ~ Int => Word -> a
pattern Ha x <- (fromIntegral -> x)
  where
    Ha :: a ~ (Word -> Word) => Word -> a
    Ha x = (x +)

which, after more thinking than one might wish to apply, turns out to mean

pattern Ha :: Word -> Int
pattern Ha x <- (fromIntegral -> x)
  where
    Ha :: Word -> Word -> Word
    Ha x = (x +)

2. It would be *extremely unpleasant* to make this trick work with
RankNTypes, where such mismatched signatures seem likely to have the
most practical value. For example, suppose I want to write

import Control.Lens
import Control.Lens.Reified

pattern Package :: Lens s t a b -> ReifiedLens s t a b
pattern Package f <- Lens f
  where
    Package :: ALens s t a b -> ReifiedLens s t a b
    Package f = Lens $ cloneLens f

This convenience pattern would pack up an ALens into a ReifiedLens;
when unpacked, I'd get back a full Lens (The type Lens s t a b
subsumes the type ALens s t a b). Without being able to use those
different type signatures, I'd have to write something like this
monstrosity:

import Control.Lens.Internal.Context -- additionally

pattern Package :: c ~ Functor
               => (forall f. c f => LensLike f s t a b)
               -> ReifiedLens s t a b
pattern Package f <- Lens f
  where
    Package :: c ~ ((~) (Pretext (->) a b))
           => (forall f. c f => LensLike f s t a b)
           -> ReifiedLens s t a b
    Package f = Lens $ cloneLens f

I pity the poor soul who has to try to reverse engineer what those
signatures are supposed to mean!

While it's certainly possible to implement the restricted version now
and expand it later, that would add *yet another* PatternSynonyms
change for users to hack around with CPP. I hope you'll reconsider
that decision in light of these examples.

Thank you for your time,
David Feuer


[*] https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0005-bidir-constr-sigs.rst

From simonpj at microsoft.com  Thu May 25 21:57:14 2017
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 25 May 2017 21:57:14 +0000
Subject: [ghc-steering-committee] GHC proposal #5
In-Reply-To: <CAMgWh9v5u8ExGYsF-9zWEspR1OydrJGLVoYZw8JwCF5=GH8uaQ@mail.gmail.com>
References: <CAMgWh9v5u8ExGYsF-9zWEspR1OydrJGLVoYZw8JwCF5=GH8uaQ@mail.gmail.com>
Message-ID: <DM2PR21MB0028F9BAA28FF0BFE84E3B96ADFF0@DM2PR21MB0028.namprd21.prod.outlook.com>

So what do you propose?  The current rendered proposal has many alternatives, so I don't know what you propose.

Moreover, all the example you give in the proposal /do/ obey the restriction; and all the /motivation/ in the proposal concerns variations in the constraints due to extra constraints required for pattern matching.

So:

* What proposal do you advocate? In particular...
* What restrictions -- if any! -- must the two type signatures satisfy
* What examples motivate whatever extra flexibility you advocate?

Simon

| -----Original Message-----
| From: ghc-steering-committee [mailto:ghc-steering-committee-
| bounces at haskell.org] On Behalf Of David Feuer
| Sent: 25 May 2017 06:28
| To: ghc-steering-committee at haskell.org
| Subject: [ghc-steering-committee] GHC proposal #5
| 
| GHC proposal  #5 [*], which I drafted, was recently merged. I was asked
| to modify the proposal to restrict the type signatures of patterns and
| builders to be the same, except for their contexts. I would like to make
| one last plea to remove this restriction, unless there are fundamental
| reasons it cannot be done. The reasons are as follows.
| 
| 1. Despite the restriction, it remains possible, at least in many cases,
| to achieve exactly the same effect, albeit in a manner that is
| considerably more difficult to read. For example, one could write the
| following (ill-advised) pattern:
| 
| pattern Ha :: a ~ Int => Word -> a
| pattern Ha x <- (fromIntegral -> x)
|   where
|     Ha :: a ~ (Word -> Word) => Word -> a
|     Ha x = (x +)
| 
| which, after more thinking than one might wish to apply, turns out to
| mean
| 
| pattern Ha :: Word -> Int
| pattern Ha x <- (fromIntegral -> x)
|   where
|     Ha :: Word -> Word -> Word
|     Ha x = (x +)
| 
| 2. It would be *extremely unpleasant* to make this trick work with
| RankNTypes, where such mismatched signatures seem likely to have the most
| practical value. For example, suppose I want to write
| 
| import Control.Lens
| import Control.Lens.Reified
| 
| pattern Package :: Lens s t a b -> ReifiedLens s t a b pattern Package f
| <- Lens f
|   where
|     Package :: ALens s t a b -> ReifiedLens s t a b
|     Package f = Lens $ cloneLens f
| 
| This convenience pattern would pack up an ALens into a ReifiedLens; when
| unpacked, I'd get back a full Lens (The type Lens s t a b subsumes the
| type ALens s t a b). Without being able to use those different type
| signatures, I'd have to write something like this
| monstrosity:
| 
| import Control.Lens.Internal.Context -- additionally
| 
| pattern Package :: c ~ Functor
|                => (forall f. c f => LensLike f s t a b)
|                -> ReifiedLens s t a b
| pattern Package f <- Lens f
|   where
|     Package :: c ~ ((~) (Pretext (->) a b))
|            => (forall f. c f => LensLike f s t a b)
|            -> ReifiedLens s t a b
|     Package f = Lens $ cloneLens f
| 
| I pity the poor soul who has to try to reverse engineer what those
| signatures are supposed to mean!
| 
| While it's certainly possible to implement the restricted version now and
| expand it later, that would add *yet another* PatternSynonyms change for
| users to hack around with CPP. I hope you'll reconsider that decision in
| light of these examples.
| 
| Thank you for your time,
| David Feuer
| 
| 
| [*]
| https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c
| om%2Fghc-proposals%2Fghc-proposals%2Fblob%2Fmaster%2Fproposals%2F0005-
| bidir-constr-
| sigs.rst&data=02%7C01%7Csimonpj%40microsoft.com%7C8f0f0cb282eb4990ce1308d
| 4a3b0fa63%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636313427896469235
| &sdata=pbr9v2OY4hhg5qmZNA9rEOBnbO5ttZG%2BDtvzbEUSNnI%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

From simonpj at microsoft.com  Fri May 26 12:54:22 2017
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 26 May 2017 12:54:22 +0000
Subject: [ghc-steering-committee] GHC proposal #5
In-Reply-To: <CAMgWh9vUuw1SWv+qBo6xhF8L9UoCEzD41An_ViE67w6Hj5R6ww@mail.gmail.com>
References: <CAMgWh9v5u8ExGYsF-9zWEspR1OydrJGLVoYZw8JwCF5=GH8uaQ@mail.gmail.com>
 <DM2PR21MB0028F9BAA28FF0BFE84E3B96ADFF0@DM2PR21MB0028.namprd21.prod.outlook.com>
 <CAMgWh9vUuw1SWv+qBo6xhF8L9UoCEzD41An_ViE67w6Hj5R6ww@mail.gmail.com>
Message-ID: <DM2PR21MB00288226B76104A5498C6A6CADFC0@DM2PR21MB0028.namprd21.prod.outlook.com>

Are you really advocating NO restrictions?  Eg

pattern P :: Int -> Maybe Int
pattern P x = Just w
  where
     P :: Char -> Int
     P x = ord x

This seems deeply peculiar to me.  No value produced by an expression using P can be consumed by a pattern matching on P.

My instinct is always to accept /fewer/ programs to start with, and expand in response to demand, rather than the reverse. 

I don't feel qualified to judge how convincing the lens example is.


|  Pattern synonyms are fundamentally about *syntax*. While particular
|  use cases provide the motivation to have them, users are free to do
|  with them as they will. I tend to think that a pattern synonym should

I don't agree.  A pattern synonym introduces an abstraction, and so far as possible we should be able to reason about it without looking inside it. We can't check that matching and construction are mutually inverse, but usually they should be.  Familiar laws should hold, so that
   case P e of P y -> rhs
means the same as
   let y=e in rhs
It's hard to enforce that, but I'd like to nudge programmers firmly in that direction.
So I'm not convinced.  What about others.

Simon


|  -----Original Message-----
|  From: David Feuer [mailto:david.feuer at gmail.com]
|  Sent: 26 May 2017 00:08
|  To: Simon Peyton Jones <simonpj at microsoft.com>
|  Cc: ghc-steering-committee at haskell.org
|  Subject: Re: [ghc-steering-committee] GHC proposal #5
|  
|  The reason I did not include the lens example in the original proposal
|  is that I hadn't thought of it by then.
|  I had the nagging feeling that I (or someone else) would eventually
|  find a motivating example, but I didn't manage to come up with a
|  sufficiently realistic one until last night.
|  I'm sorry about that. As for your
|  questions:
|  
|  1. As I stated in the original pull request, before I was asked to
|  modify it, I believe that the type signatures should not have any
|  restrictions whatsoever. As the first example in my last email
|  demonstrates, it seems impossible to actually preclude "unreasonable"
|  pairs of signatures while still accomplishing the basic objectives. I
|  don't think mismatched signatures are likely ever to be common, but I
|  don't think making them harder to write and harder to read serves any
|  obvious purpose. In the case of DefaultSignatures, there was
|  apparently a compelling reason to impose a similar restriction to make
|  correct implementation feasible.
|  I am not aware of any similar reason in this case. Should one arise, I
|  will certainly accept the restriction.
|  
|  2. The ALens/Lens -> ReifiedLens pattern in my last email strikes me
|  as a decent example: it may reasonable in some cases for pattern
|  matching to provide a value with a type that subsumes the type
|  required to apply the builder.
|  
|  I imagine it might sometimes be useful to go in the opposite
|  direction, but I haven't been able to find a good example of that yet.
|  Intuitively, one possible direction an example might take would be a
|  builder that requires its argument to be polymorphic in order to make
|  some guarantee by parametricity, with an efficient monomorphic
|  representation that can only provide a monomorphic pattern.
|  
|  A final thought, for now:
|  
|  Pattern synonyms are fundamentally about *syntax*. While particular
|  use cases provide the motivation to have them, users are free to do
|  with them as they will. I tend to think that a pattern synonym should
|  always be cheap, both when building and when matching. Others
|  disagree. I would be very much opposed to any attempt to restrict
|  pattern synonyms to cheap operations, as a matter of principle. I
|  similarly believe that building and matching should never throw
|  exceptions or fail to terminate when given non-bottom input, but would
|  oppose attempts to enforce such a law. In the present instance, I ask
|  you to set aside how you think pattern synonyms and builders *should*
|  relate in type, and to consider instead whether they really must.
|  
|  Thanks,
|  David
|  
|  On Thu, May 25, 2017 at 5:57 PM, Simon Peyton Jones
|  <simonpj at microsoft.com> wrote:
|  > So what do you propose?  The current rendered proposal has many
|  alternatives, so I don't know what you propose.
|  >
|  > Moreover, all the example you give in the proposal /do/ obey the
|  restriction; and all the /motivation/ in the proposal concerns
|  variations in the constraints due to extra constraints required for
|  pattern matching.
|  >
|  > So:
|  >
|  > * What proposal do you advocate? In particular...
|  > * What restrictions -- if any! -- must the two type signatures
|  satisfy
|  > * What examples motivate whatever extra flexibility you advocate?
|  >
|  > Simon
|  >
|  > | -----Original Message-----
|  > | From: ghc-steering-committee [mailto:ghc-steering-committee-
|  > | bounces at haskell.org] On Behalf Of David Feuer
|  > | Sent: 25 May 2017 06:28
|  > | To: ghc-steering-committee at haskell.org
|  > | Subject: [ghc-steering-committee] GHC proposal #5
|  > |
|  > | GHC proposal  #5 [*], which I drafted, was recently merged. I was
|  > | asked to modify the proposal to restrict the type signatures of
|  > | patterns and builders to be the same, except for their contexts. I
|  > | would like to make one last plea to remove this restriction,
|  unless
|  > | there are fundamental reasons it cannot be done. The reasons are
|  as follows.
|  > |
|  > | 1. Despite the restriction, it remains possible, at least in many
|  > | cases, to achieve exactly the same effect, albeit in a manner that
|  > | is considerably more difficult to read. For example, one could
|  write
|  > | the following (ill-advised) pattern:
|  > |
|  > | pattern Ha :: a ~ Int => Word -> a
|  > | pattern Ha x <- (fromIntegral -> x)
|  > |   where
|  > |     Ha :: a ~ (Word -> Word) => Word -> a
|  > |     Ha x = (x +)
|  > |
|  > | which, after more thinking than one might wish to apply, turns out
|  > | to mean
|  > |
|  > | pattern Ha :: Word -> Int
|  > | pattern Ha x <- (fromIntegral -> x)
|  > |   where
|  > |     Ha :: Word -> Word -> Word
|  > |     Ha x = (x +)
|  > |
|  > | 2. It would be *extremely unpleasant* to make this trick work with
|  > | RankNTypes, where such mismatched signatures seem likely to have
|  the
|  > | most practical value. For example, suppose I want to write
|  > |
|  > | import Control.Lens
|  > | import Control.Lens.Reified
|  > |
|  > | pattern Package :: Lens s t a b -> ReifiedLens s t a b pattern
|  > | Package f
|  > | <- Lens f
|  > |   where
|  > |     Package :: ALens s t a b -> ReifiedLens s t a b
|  > |     Package f = Lens $ cloneLens f
|  > |
|  > | This convenience pattern would pack up an ALens into a
|  ReifiedLens;
|  > | when unpacked, I'd get back a full Lens (The type Lens s t a b
|  > | subsumes the type ALens s t a b). Without being able to use those
|  > | different type signatures, I'd have to write something like this
|  > | monstrosity:
|  > |
|  > | import Control.Lens.Internal.Context -- additionally
|  > |
|  > | pattern Package :: c ~ Functor
|  > |                => (forall f. c f => LensLike f s t a b)
|  > |                -> ReifiedLens s t a b pattern Package f <- Lens f
|  > |   where
|  > |     Package :: c ~ ((~) (Pretext (->) a b))
|  > |            => (forall f. c f => LensLike f s t a b)
|  > |            -> ReifiedLens s t a b
|  > |     Package f = Lens $ cloneLens f
|  > |
|  > | I pity the poor soul who has to try to reverse engineer what those
|  > | signatures are supposed to mean!
|  > |
|  > | While it's certainly possible to implement the restricted version
|  > | now and expand it later, that would add *yet another*
|  > | PatternSynonyms change for users to hack around with CPP. I hope
|  > | you'll reconsider that decision in light of these examples.
|  > |
|  > | Thank you for your time,
|  > | David Feuer
|  > |
|  > |
|  > | [*]
|  > |
|  https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit
|  > | hub.c
|  > | om%2Fghc-proposals%2Fghc-
|  proposals%2Fblob%2Fmaster%2Fproposals%2F000
|  > | 5-
|  > | bidir-constr-
|  > |
|  sigs.rst&data=02%7C01%7Csimonpj%40microsoft.com%7C8f0f0cb282eb4990ce
|  > | 1308d
|  > |
|  4a3b0fa63%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6363134278964
|  > | 69235
|  > | &sdata=pbr9v2OY4hhg5qmZNA9rEOBnbO5ttZG%2BDtvzbEUSNnI%3D&reserved=0
|  > | _______________________________________________
|  > | ghc-steering-committee mailing list
|  > | ghc-steering-committee at haskell.org
|  > | https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-
|  commi
|  > | ttee

From david.feuer at gmail.com  Thu May 25 23:07:51 2017
From: david.feuer at gmail.com (David Feuer)
Date: Thu, 25 May 2017 19:07:51 -0400
Subject: [ghc-steering-committee] GHC proposal #5
In-Reply-To: <DM2PR21MB0028F9BAA28FF0BFE84E3B96ADFF0@DM2PR21MB0028.namprd21.prod.outlook.com>
References: <CAMgWh9v5u8ExGYsF-9zWEspR1OydrJGLVoYZw8JwCF5=GH8uaQ@mail.gmail.com>
 <DM2PR21MB0028F9BAA28FF0BFE84E3B96ADFF0@DM2PR21MB0028.namprd21.prod.outlook.com>
Message-ID: <CAMgWh9vUuw1SWv+qBo6xhF8L9UoCEzD41An_ViE67w6Hj5R6ww@mail.gmail.com>

The reason I did not include the lens example in the original proposal
is that I hadn't thought of it by then.
I had the nagging feeling that I (or someone else) would eventually
find a motivating example, but I didn't
manage to come up with a sufficiently realistic one until last night.
I'm sorry about that. As for your
questions:

1. As I stated in the original pull request, before I was asked to
modify it, I believe that the type signatures
should not have any restrictions whatsoever. As the first example in
my last email demonstrates, it seems
impossible to actually preclude "unreasonable" pairs of signatures
while still accomplishing the basic
objectives. I don't think mismatched signatures are likely ever to be
common, but I don't think making them
harder to write and harder to read serves any obvious purpose. In the
case of DefaultSignatures, there
was apparently a compelling reason to impose a similar restriction to
make correct implementation feasible.
I am not aware of any similar reason in this case. Should one arise, I
will certainly accept the restriction.

2. The ALens/Lens -> ReifiedLens pattern in my last email strikes me
as a decent example: it may reasonable
in some cases for pattern matching to provide a value with a type that
subsumes the type required to apply
the builder.

I imagine it might sometimes be useful to go in the opposite
direction, but I haven't been able to find a
good example of that yet. Intuitively, one possible direction an
example might take would be a builder that
requires its argument to be polymorphic in order to make some
guarantee by parametricity, with an
efficient monomorphic representation that can only provide a
monomorphic pattern.

A final thought, for now:

Pattern synonyms are fundamentally about *syntax*. While particular
use cases provide the motivation
to have them, users are free to do with them as they will. I tend to
think that a pattern synonym should
always be cheap, both when building and when matching. Others
disagree. I would be very much opposed
to any attempt to restrict pattern synonyms to cheap operations, as a
matter of principle. I similarly believe
that building and matching should never throw exceptions or fail to
terminate when given non-bottom input,
but would oppose attempts to enforce such a law. In the present
instance, I ask you to set aside how you
think pattern synonyms and builders *should* relate in type, and to
consider instead whether they really
must.

Thanks,
David

On Thu, May 25, 2017 at 5:57 PM, Simon Peyton Jones
<simonpj at microsoft.com> wrote:
> So what do you propose?  The current rendered proposal has many alternatives, so I don't know what you propose.
>
> Moreover, all the example you give in the proposal /do/ obey the restriction; and all the /motivation/ in the proposal concerns variations in the constraints due to extra constraints required for pattern matching.
>
> So:
>
> * What proposal do you advocate? In particular...
> * What restrictions -- if any! -- must the two type signatures satisfy
> * What examples motivate whatever extra flexibility you advocate?
>
> Simon
>
> | -----Original Message-----
> | From: ghc-steering-committee [mailto:ghc-steering-committee-
> | bounces at haskell.org] On Behalf Of David Feuer
> | Sent: 25 May 2017 06:28
> | To: ghc-steering-committee at haskell.org
> | Subject: [ghc-steering-committee] GHC proposal #5
> |
> | GHC proposal  #5 [*], which I drafted, was recently merged. I was asked
> | to modify the proposal to restrict the type signatures of patterns and
> | builders to be the same, except for their contexts. I would like to make
> | one last plea to remove this restriction, unless there are fundamental
> | reasons it cannot be done. The reasons are as follows.
> |
> | 1. Despite the restriction, it remains possible, at least in many cases,
> | to achieve exactly the same effect, albeit in a manner that is
> | considerably more difficult to read. For example, one could write the
> | following (ill-advised) pattern:
> |
> | pattern Ha :: a ~ Int => Word -> a
> | pattern Ha x <- (fromIntegral -> x)
> |   where
> |     Ha :: a ~ (Word -> Word) => Word -> a
> |     Ha x = (x +)
> |
> | which, after more thinking than one might wish to apply, turns out to
> | mean
> |
> | pattern Ha :: Word -> Int
> | pattern Ha x <- (fromIntegral -> x)
> |   where
> |     Ha :: Word -> Word -> Word
> |     Ha x = (x +)
> |
> | 2. It would be *extremely unpleasant* to make this trick work with
> | RankNTypes, where such mismatched signatures seem likely to have the most
> | practical value. For example, suppose I want to write
> |
> | import Control.Lens
> | import Control.Lens.Reified
> |
> | pattern Package :: Lens s t a b -> ReifiedLens s t a b pattern Package f
> | <- Lens f
> |   where
> |     Package :: ALens s t a b -> ReifiedLens s t a b
> |     Package f = Lens $ cloneLens f
> |
> | This convenience pattern would pack up an ALens into a ReifiedLens; when
> | unpacked, I'd get back a full Lens (The type Lens s t a b subsumes the
> | type ALens s t a b). Without being able to use those different type
> | signatures, I'd have to write something like this
> | monstrosity:
> |
> | import Control.Lens.Internal.Context -- additionally
> |
> | pattern Package :: c ~ Functor
> |                => (forall f. c f => LensLike f s t a b)
> |                -> ReifiedLens s t a b
> | pattern Package f <- Lens f
> |   where
> |     Package :: c ~ ((~) (Pretext (->) a b))
> |            => (forall f. c f => LensLike f s t a b)
> |            -> ReifiedLens s t a b
> |     Package f = Lens $ cloneLens f
> |
> | I pity the poor soul who has to try to reverse engineer what those
> | signatures are supposed to mean!
> |
> | While it's certainly possible to implement the restricted version now and
> | expand it later, that would add *yet another* PatternSynonyms change for
> | users to hack around with CPP. I hope you'll reconsider that decision in
> | light of these examples.
> |
> | Thank you for your time,
> | David Feuer
> |
> |
> | [*]
> | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c
> | om%2Fghc-proposals%2Fghc-proposals%2Fblob%2Fmaster%2Fproposals%2F0005-
> | bidir-constr-
> | sigs.rst&data=02%7C01%7Csimonpj%40microsoft.com%7C8f0f0cb282eb4990ce1308d
> | 4a3b0fa63%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636313427896469235
> | &sdata=pbr9v2OY4hhg5qmZNA9rEOBnbO5ttZG%2BDtvzbEUSNnI%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

From david.feuer at gmail.com  Fri May 26 13:10:50 2017
From: david.feuer at gmail.com (David Feuer)
Date: Fri, 26 May 2017 09:10:50 -0400
Subject: [ghc-steering-committee] GHC proposal #5
In-Reply-To: <DM2PR21MB00288226B76104A5498C6A6CADFC0@DM2PR21MB0028.namprd21.prod.outlook.com>
References: <CAMgWh9v5u8ExGYsF-9zWEspR1OydrJGLVoYZw8JwCF5=GH8uaQ@mail.gmail.com>
 <DM2PR21MB0028F9BAA28FF0BFE84E3B96ADFF0@DM2PR21MB0028.namprd21.prod.outlook.com>
 <CAMgWh9vUuw1SWv+qBo6xhF8L9UoCEzD41An_ViE67w6Hj5R6ww@mail.gmail.com>
 <DM2PR21MB00288226B76104A5498C6A6CADFC0@DM2PR21MB0028.namprd21.prod.outlook.com>
Message-ID: <CAMgWh9sPSF=vRVX+vgcwppNE2530y4SFYg7AAD-1e1S7kLPbHA@mail.gmail.com>

I really am advocating allowing that, although I don't believe any library
writer should write such a ridiculous pattern. Here's my reasoning. The
proposal, even with the restriction, fundamentally adds expressiveness to
the pattern synonym extension. This is a good thing, because it allows
people to write substantially more useful patterns than they can today. As
soon as you add expressiveness, I think it makes sense to see just how much
you've added. As I've demonstrated, it seems that the restricted proposal
adds enough power to allow effectively unrelated pattern and builder
signatures. That is, the restriction doesn't really seem to restrict! So it
seems primarily to serve to punish anyone who wants to do something too
weird by making weird things inconvenient and ugly, which doesn't seem very
valuable to me.

Note: I really want this proposal to go through, even if restricted; I just
don't see the wisdom of the restriction.

David

On May 26, 2017 8:54 AM, "Simon Peyton Jones" <simonpj at microsoft.com> wrote:

Are you really advocating NO restrictions?  Eg

pattern P :: Int -> Maybe Int
pattern P x = Just w
  where
     P :: Char -> Int
     P x = ord x

This seems deeply peculiar to me.  No value produced by an expression using
P can be consumed by a pattern matching on P.

My instinct is always to accept /fewer/ programs to start with, and expand
in response to demand, rather than the reverse.

I don't feel qualified to judge how convincing the lens example is.


|  Pattern synonyms are fundamentally about *syntax*. While particular
|  use cases provide the motivation to have them, users are free to do
|  with them as they will. I tend to think that a pattern synonym should

I don't agree.  A pattern synonym introduces an abstraction, and so far as
possible we should be able to reason about it without looking inside it. We
can't check that matching and construction are mutually inverse, but
usually they should be.  Familiar laws should hold, so that
   case P e of P y -> rhs
means the same as
   let y=e in rhs
It's hard to enforce that, but I'd like to nudge programmers firmly in that
direction.
So I'm not convinced.  What about others.

Simon


|  -----Original Message-----
|  From: David Feuer [mailto:david.feuer at gmail.com]
|  Sent: 26 May 2017 00:08
|  To: Simon Peyton Jones <simonpj at microsoft.com>
|  Cc: ghc-steering-committee at haskell.org
|  Subject: Re: [ghc-steering-committee] GHC proposal #5
|
|  The reason I did not include the lens example in the original proposal
|  is that I hadn't thought of it by then.
|  I had the nagging feeling that I (or someone else) would eventually
|  find a motivating example, but I didn't manage to come up with a
|  sufficiently realistic one until last night.
|  I'm sorry about that. As for your
|  questions:
|
|  1. As I stated in the original pull request, before I was asked to
|  modify it, I believe that the type signatures should not have any
|  restrictions whatsoever. As the first example in my last email
|  demonstrates, it seems impossible to actually preclude "unreasonable"
|  pairs of signatures while still accomplishing the basic objectives. I
|  don't think mismatched signatures are likely ever to be common, but I
|  don't think making them harder to write and harder to read serves any
|  obvious purpose. In the case of DefaultSignatures, there was
|  apparently a compelling reason to impose a similar restriction to make
|  correct implementation feasible.
|  I am not aware of any similar reason in this case. Should one arise, I
|  will certainly accept the restriction.
|
|  2. The ALens/Lens -> ReifiedLens pattern in my last email strikes me
|  as a decent example: it may reasonable in some cases for pattern
|  matching to provide a value with a type that subsumes the type
|  required to apply the builder.
|
|  I imagine it might sometimes be useful to go in the opposite
|  direction, but I haven't been able to find a good example of that yet.
|  Intuitively, one possible direction an example might take would be a
|  builder that requires its argument to be polymorphic in order to make
|  some guarantee by parametricity, with an efficient monomorphic
|  representation that can only provide a monomorphic pattern.
|
|  A final thought, for now:
|
|  Pattern synonyms are fundamentally about *syntax*. While particular
|  use cases provide the motivation to have them, users are free to do
|  with them as they will. I tend to think that a pattern synonym should
|  always be cheap, both when building and when matching. Others
|  disagree. I would be very much opposed to any attempt to restrict
|  pattern synonyms to cheap operations, as a matter of principle. I
|  similarly believe that building and matching should never throw
|  exceptions or fail to terminate when given non-bottom input, but would
|  oppose attempts to enforce such a law. In the present instance, I ask
|  you to set aside how you think pattern synonyms and builders *should*
|  relate in type, and to consider instead whether they really must.
|
|  Thanks,
|  David
|
|  On Thu, May 25, 2017 at 5:57 PM, Simon Peyton Jones
|  <simonpj at microsoft.com> wrote:
|  > So what do you propose?  The current rendered proposal has many
|  alternatives, so I don't know what you propose.
|  >
|  > Moreover, all the example you give in the proposal /do/ obey the
|  restriction; and all the /motivation/ in the proposal concerns
|  variations in the constraints due to extra constraints required for
|  pattern matching.
|  >
|  > So:
|  >
|  > * What proposal do you advocate? In particular...
|  > * What restrictions -- if any! -- must the two type signatures
|  satisfy
|  > * What examples motivate whatever extra flexibility you advocate?
|  >
|  > Simon
|  >
|  > | -----Original Message-----
|  > | From: ghc-steering-committee [mailto:ghc-steering-committee-
|  > | bounces at haskell.org] On Behalf Of David Feuer
|  > | Sent: 25 May 2017 06:28
|  > | To: ghc-steering-committee at haskell.org
|  > | Subject: [ghc-steering-committee] GHC proposal #5
|  > |
|  > | GHC proposal  #5 [*], which I drafted, was recently merged. I was
|  > | asked to modify the proposal to restrict the type signatures of
|  > | patterns and builders to be the same, except for their contexts. I
|  > | would like to make one last plea to remove this restriction,
|  unless
|  > | there are fundamental reasons it cannot be done. The reasons are
|  as follows.
|  > |
|  > | 1. Despite the restriction, it remains possible, at least in many
|  > | cases, to achieve exactly the same effect, albeit in a manner that
|  > | is considerably more difficult to read. For example, one could
|  write
|  > | the following (ill-advised) pattern:
|  > |
|  > | pattern Ha :: a ~ Int => Word -> a
|  > | pattern Ha x <- (fromIntegral -> x)
|  > |   where
|  > |     Ha :: a ~ (Word -> Word) => Word -> a
|  > |     Ha x = (x +)
|  > |
|  > | which, after more thinking than one might wish to apply, turns out
|  > | to mean
|  > |
|  > | pattern Ha :: Word -> Int
|  > | pattern Ha x <- (fromIntegral -> x)
|  > |   where
|  > |     Ha :: Word -> Word -> Word
|  > |     Ha x = (x +)
|  > |
|  > | 2. It would be *extremely unpleasant* to make this trick work with
|  > | RankNTypes, where such mismatched signatures seem likely to have
|  the
|  > | most practical value. For example, suppose I want to write
|  > |
|  > | import Control.Lens
|  > | import Control.Lens.Reified
|  > |
|  > | pattern Package :: Lens s t a b -> ReifiedLens s t a b pattern
|  > | Package f
|  > | <- Lens f
|  > |   where
|  > |     Package :: ALens s t a b -> ReifiedLens s t a b
|  > |     Package f = Lens $ cloneLens f
|  > |
|  > | This convenience pattern would pack up an ALens into a
|  ReifiedLens;
|  > | when unpacked, I'd get back a full Lens (The type Lens s t a b
|  > | subsumes the type ALens s t a b). Without being able to use those
|  > | different type signatures, I'd have to write something like this
|  > | monstrosity:
|  > |
|  > | import Control.Lens.Internal.Context -- additionally
|  > |
|  > | pattern Package :: c ~ Functor
|  > |                => (forall f. c f => LensLike f s t a b)
|  > |                -> ReifiedLens s t a b pattern Package f <- Lens f
|  > |   where
|  > |     Package :: c ~ ((~) (Pretext (->) a b))
|  > |            => (forall f. c f => LensLike f s t a b)
|  > |            -> ReifiedLens s t a b
|  > |     Package f = Lens $ cloneLens f
|  > |
|  > | I pity the poor soul who has to try to reverse engineer what those
|  > | signatures are supposed to mean!
|  > |
|  > | While it's certainly possible to implement the restricted version
|  > | now and expand it later, that would add *yet another*
|  > | PatternSynonyms change for users to hack around with CPP. I hope
|  > | you'll reconsider that decision in light of these examples.
|  > |
|  > | Thank you for your time,
|  > | David Feuer
|  > |
|  > |
|  > | [*]
|  > |
|  https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit
|  > | hub.c
|  > | om%2Fghc-proposals%2Fghc-
|  proposals%2Fblob%2Fmaster%2Fproposals%2F000
|  > | 5-
|  > | bidir-constr-
|  > |
|  sigs.rst&data=02%7C01%7Csimonpj%40microsoft.com%7C8f0f0cb282eb4990ce
|  > | 1308d
|  > |
|  4a3b0fa63%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6363134278964
|  > | 69235
|  > | &sdata=pbr9v2OY4hhg5qmZNA9rEOBnbO5ttZG%2BDtvzbEUSNnI%3D&reserved=0
|  > | _______________________________________________
|  > | ghc-steering-committee mailing list
|  > | ghc-steering-committee at haskell.org
|  > | https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-
|  commi
|  > | ttee
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20170526/0e9302ee/attachment-0001.html>

From david.feuer at gmail.com  Fri May 26 18:58:21 2017
From: david.feuer at gmail.com (David Feuer)
Date: Fri, 26 May 2017 14:58:21 -0400
Subject: [ghc-steering-committee] GHC proposal #5
In-Reply-To: <CAMgWh9sPSF=vRVX+vgcwppNE2530y4SFYg7AAD-1e1S7kLPbHA@mail.gmail.com>
References: <CAMgWh9v5u8ExGYsF-9zWEspR1OydrJGLVoYZw8JwCF5=GH8uaQ@mail.gmail.com>
 <DM2PR21MB0028F9BAA28FF0BFE84E3B96ADFF0@DM2PR21MB0028.namprd21.prod.outlook.com>
 <CAMgWh9vUuw1SWv+qBo6xhF8L9UoCEzD41An_ViE67w6Hj5R6ww@mail.gmail.com>
 <DM2PR21MB00288226B76104A5498C6A6CADFC0@DM2PR21MB0028.namprd21.prod.outlook.com>
 <CAMgWh9sPSF=vRVX+vgcwppNE2530y4SFYg7AAD-1e1S7kLPbHA@mail.gmail.com>
Message-ID: <CAMgWh9tLRuzesbg=Q+GAvUnXx09Q9CVdrDFtr-oU6km3zoqXaw@mail.gmail.com>

I thought of something that coops be a good compromise. You could require
the signatures to be the same, modulo constraints, unless another extension
allowed equality constraints. So using just PatternSynonyms, only
"sensible" types would occur, but adding GADTs or TypeFamilies would let
the signatures be totally wild.

On May 26, 2017 9:10 AM, "David Feuer" <david.feuer at gmail.com> wrote:

> I really am advocating allowing that, although I don't believe any library
> writer should write such a ridiculous pattern. Here's my reasoning. The
> proposal, even with the restriction, fundamentally adds expressiveness to
> the pattern synonym extension. This is a good thing, because it allows
> people to write substantially more useful patterns than they can today. As
> soon as you add expressiveness, I think it makes sense to see just how much
> you've added. As I've demonstrated, it seems that the restricted proposal
> adds enough power to allow effectively unrelated pattern and builder
> signatures. That is, the restriction doesn't really seem to restrict! So it
> seems primarily to serve to punish anyone who wants to do something too
> weird by making weird things inconvenient and ugly, which doesn't seem very
> valuable to me.
>
> Note: I really want this proposal to go through, even if restricted; I
> just don't see the wisdom of the restriction.
>
> David
>
> On May 26, 2017 8:54 AM, "Simon Peyton Jones" <simonpj at microsoft.com>
> wrote:
>
> Are you really advocating NO restrictions?  Eg
>
> pattern P :: Int -> Maybe Int
> pattern P x = Just w
>   where
>      P :: Char -> Int
>      P x = ord x
>
> This seems deeply peculiar to me.  No value produced by an expression
> using P can be consumed by a pattern matching on P.
>
> My instinct is always to accept /fewer/ programs to start with, and expand
> in response to demand, rather than the reverse.
>
> I don't feel qualified to judge how convincing the lens example is.
>
>
> |  Pattern synonyms are fundamentally about *syntax*. While particular
> |  use cases provide the motivation to have them, users are free to do
> |  with them as they will. I tend to think that a pattern synonym should
>
> I don't agree.  A pattern synonym introduces an abstraction, and so far as
> possible we should be able to reason about it without looking inside it. We
> can't check that matching and construction are mutually inverse, but
> usually they should be.  Familiar laws should hold, so that
>    case P e of P y -> rhs
> means the same as
>    let y=e in rhs
> It's hard to enforce that, but I'd like to nudge programmers firmly in
> that direction.
> So I'm not convinced.  What about others.
>
> Simon
>
>
> |  -----Original Message-----
> |  From: David Feuer [mailto:david.feuer at gmail.com]
> |  Sent: 26 May 2017 00:08
> |  To: Simon Peyton Jones <simonpj at microsoft.com>
> |  Cc: ghc-steering-committee at haskell.org
> |  Subject: Re: [ghc-steering-committee] GHC proposal #5
> |
> |  The reason I did not include the lens example in the original proposal
> |  is that I hadn't thought of it by then.
> |  I had the nagging feeling that I (or someone else) would eventually
> |  find a motivating example, but I didn't manage to come up with a
> |  sufficiently realistic one until last night.
> |  I'm sorry about that. As for your
> |  questions:
> |
> |  1. As I stated in the original pull request, before I was asked to
> |  modify it, I believe that the type signatures should not have any
> |  restrictions whatsoever. As the first example in my last email
> |  demonstrates, it seems impossible to actually preclude "unreasonable"
> |  pairs of signatures while still accomplishing the basic objectives. I
> |  don't think mismatched signatures are likely ever to be common, but I
> |  don't think making them harder to write and harder to read serves any
> |  obvious purpose. In the case of DefaultSignatures, there was
> |  apparently a compelling reason to impose a similar restriction to make
> |  correct implementation feasible.
> |  I am not aware of any similar reason in this case. Should one arise, I
> |  will certainly accept the restriction.
> |
> |  2. The ALens/Lens -> ReifiedLens pattern in my last email strikes me
> |  as a decent example: it may reasonable in some cases for pattern
> |  matching to provide a value with a type that subsumes the type
> |  required to apply the builder.
> |
> |  I imagine it might sometimes be useful to go in the opposite
> |  direction, but I haven't been able to find a good example of that yet.
> |  Intuitively, one possible direction an example might take would be a
> |  builder that requires its argument to be polymorphic in order to make
> |  some guarantee by parametricity, with an efficient monomorphic
> |  representation that can only provide a monomorphic pattern.
> |
> |  A final thought, for now:
> |
> |  Pattern synonyms are fundamentally about *syntax*. While particular
> |  use cases provide the motivation to have them, users are free to do
> |  with them as they will. I tend to think that a pattern synonym should
> |  always be cheap, both when building and when matching. Others
> |  disagree. I would be very much opposed to any attempt to restrict
> |  pattern synonyms to cheap operations, as a matter of principle. I
> |  similarly believe that building and matching should never throw
> |  exceptions or fail to terminate when given non-bottom input, but would
> |  oppose attempts to enforce such a law. In the present instance, I ask
> |  you to set aside how you think pattern synonyms and builders *should*
> |  relate in type, and to consider instead whether they really must.
> |
> |  Thanks,
> |  David
> |
> |  On Thu, May 25, 2017 at 5:57 PM, Simon Peyton Jones
> |  <simonpj at microsoft.com> wrote:
> |  > So what do you propose?  The current rendered proposal has many
> |  alternatives, so I don't know what you propose.
> |  >
> |  > Moreover, all the example you give in the proposal /do/ obey the
> |  restriction; and all the /motivation/ in the proposal concerns
> |  variations in the constraints due to extra constraints required for
> |  pattern matching.
> |  >
> |  > So:
> |  >
> |  > * What proposal do you advocate? In particular...
> |  > * What restrictions -- if any! -- must the two type signatures
> |  satisfy
> |  > * What examples motivate whatever extra flexibility you advocate?
> |  >
> |  > Simon
> |  >
> |  > | -----Original Message-----
> |  > | From: ghc-steering-committee [mailto:ghc-steering-committee-
> |  > | bounces at haskell.org] On Behalf Of David Feuer
> |  > | Sent: 25 May 2017 06:28
> |  > | To: ghc-steering-committee at haskell.org
> |  > | Subject: [ghc-steering-committee] GHC proposal #5
> |  > |
> |  > | GHC proposal  #5 [*], which I drafted, was recently merged. I was
> |  > | asked to modify the proposal to restrict the type signatures of
> |  > | patterns and builders to be the same, except for their contexts. I
> |  > | would like to make one last plea to remove this restriction,
> |  unless
> |  > | there are fundamental reasons it cannot be done. The reasons are
> |  as follows.
> |  > |
> |  > | 1. Despite the restriction, it remains possible, at least in many
> |  > | cases, to achieve exactly the same effect, albeit in a manner that
> |  > | is considerably more difficult to read. For example, one could
> |  write
> |  > | the following (ill-advised) pattern:
> |  > |
> |  > | pattern Ha :: a ~ Int => Word -> a
> |  > | pattern Ha x <- (fromIntegral -> x)
> |  > |   where
> |  > |     Ha :: a ~ (Word -> Word) => Word -> a
> |  > |     Ha x = (x +)
> |  > |
> |  > | which, after more thinking than one might wish to apply, turns out
> |  > | to mean
> |  > |
> |  > | pattern Ha :: Word -> Int
> |  > | pattern Ha x <- (fromIntegral -> x)
> |  > |   where
> |  > |     Ha :: Word -> Word -> Word
> |  > |     Ha x = (x +)
> |  > |
> |  > | 2. It would be *extremely unpleasant* to make this trick work with
> |  > | RankNTypes, where such mismatched signatures seem likely to have
> |  the
> |  > | most practical value. For example, suppose I want to write
> |  > |
> |  > | import Control.Lens
> |  > | import Control.Lens.Reified
> |  > |
> |  > | pattern Package :: Lens s t a b -> ReifiedLens s t a b pattern
> |  > | Package f
> |  > | <- Lens f
> |  > |   where
> |  > |     Package :: ALens s t a b -> ReifiedLens s t a b
> |  > |     Package f = Lens $ cloneLens f
> |  > |
> |  > | This convenience pattern would pack up an ALens into a
> |  ReifiedLens;
> |  > | when unpacked, I'd get back a full Lens (The type Lens s t a b
> |  > | subsumes the type ALens s t a b). Without being able to use those
> |  > | different type signatures, I'd have to write something like this
> |  > | monstrosity:
> |  > |
> |  > | import Control.Lens.Internal.Context -- additionally
> |  > |
> |  > | pattern Package :: c ~ Functor
> |  > |                => (forall f. c f => LensLike f s t a b)
> |  > |                -> ReifiedLens s t a b pattern Package f <- Lens f
> |  > |   where
> |  > |     Package :: c ~ ((~) (Pretext (->) a b))
> |  > |            => (forall f. c f => LensLike f s t a b)
> |  > |            -> ReifiedLens s t a b
> |  > |     Package f = Lens $ cloneLens f
> |  > |
> |  > | I pity the poor soul who has to try to reverse engineer what those
> |  > | signatures are supposed to mean!
> |  > |
> |  > | While it's certainly possible to implement the restricted version
> |  > | now and expand it later, that would add *yet another*
> |  > | PatternSynonyms change for users to hack around with CPP. I hope
> |  > | you'll reconsider that decision in light of these examples.
> |  > |
> |  > | Thank you for your time,
> |  > | David Feuer
> |  > |
> |  > |
> |  > | [*]
> |  > |
> |  https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit
> |  > | hub.c
> |  > | om%2Fghc-proposals%2Fghc-
> |  proposals%2Fblob%2Fmaster%2Fproposals%2F000
> |  > | 5-
> |  > | bidir-constr-
> |  > |
> |  sigs.rst&data=02%7C01%7Csimonpj%40microsoft.com%7C8f0f0cb282eb4990ce
> |  > | 1308d
> |  > |
> |  4a3b0fa63%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6363134278964
> |  > | 69235
> |  > | &sdata=pbr9v2OY4hhg5qmZNA9rEOBnbO5ttZG%2BDtvzbEUSNnI%3D&reserved=0
> |  > | _______________________________________________
> |  > | ghc-steering-committee mailing list
> |  > | ghc-steering-committee at haskell.org
> |  > | https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-
> |  commi
> |  > | ttee
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20170526/0f9f6427/attachment.html>

From rae at cs.brynmawr.edu  Tue May 30 13:54:54 2017
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Tue, 30 May 2017 09:54:54 -0400
Subject: [ghc-steering-committee] GHC proposal #5
In-Reply-To: <CAMgWh9tLRuzesbg=Q+GAvUnXx09Q9CVdrDFtr-oU6km3zoqXaw@mail.gmail.com>
References: <CAMgWh9v5u8ExGYsF-9zWEspR1OydrJGLVoYZw8JwCF5=GH8uaQ@mail.gmail.com>
 <DM2PR21MB0028F9BAA28FF0BFE84E3B96ADFF0@DM2PR21MB0028.namprd21.prod.outlook.com>
 <CAMgWh9vUuw1SWv+qBo6xhF8L9UoCEzD41An_ViE67w6Hj5R6ww@mail.gmail.com>
 <DM2PR21MB00288226B76104A5498C6A6CADFC0@DM2PR21MB0028.namprd21.prod.outlook.com>
 <CAMgWh9sPSF=vRVX+vgcwppNE2530y4SFYg7AAD-1e1S7kLPbHA@mail.gmail.com>
 <CAMgWh9tLRuzesbg=Q+GAvUnXx09Q9CVdrDFtr-oU6km3zoqXaw@mail.gmail.com>
Message-ID: <12C144C7-5E7C-4DAE-BB74-4CB28A6E1072@cs.brynmawr.edu>

I'm afraid I think the best way to have this discussion is to submit another proposal. Is there a Trac ticket for the first one? That ticket should track implementation, and we could put a note there saying not to implement, pending the new proposal.

Why do I want yet more process? Because I'm worried about having design conversations "behind closed doors", as doing so can be exclusionary. My other motivation is that I initially agree with Simon and say "no" -- but I want to give you a chance to convince me. Your best opportunity will be to get others to agree with you. Incidentally, my suggestion here agrees with what has been said on the initial pull request.

Richard

> On May 26, 2017, at 2:58 PM, David Feuer <david.feuer at gmail.com> wrote:
> 
> I thought of something that coops be a good compromise. You could require the signatures to be the same, modulo constraints, unless another extension allowed equality constraints. So using just PatternSynonyms, only "sensible" types would occur, but adding GADTs or TypeFamilies would let the signatures be totally wild.
> 
> On May 26, 2017 9:10 AM, "David Feuer" <david.feuer at gmail.com <mailto:david.feuer at gmail.com>> wrote:
> I really am advocating allowing that, although I don't believe any library writer should write such a ridiculous pattern. Here's my reasoning. The proposal, even with the restriction, fundamentally adds expressiveness to the pattern synonym extension. This is a good thing, because it allows people to write substantially more useful patterns than they can today. As soon as you add expressiveness, I think it makes sense to see just how much you've added. As I've demonstrated, it seems that the restricted proposal adds enough power to allow effectively unrelated pattern and builder signatures. That is, the restriction doesn't really seem to restrict! So it seems primarily to serve to punish anyone who wants to do something too weird by making weird things inconvenient and ugly, which doesn't seem very valuable to me.
> 
> Note: I really want this proposal to go through, even if restricted; I just don't see the wisdom of the restriction.
> 
> David
> 
> On May 26, 2017 8:54 AM, "Simon Peyton Jones" <simonpj at microsoft.com <mailto:simonpj at microsoft.com>> wrote:
> Are you really advocating NO restrictions?  Eg
> 
> pattern P :: Int -> Maybe Int
> pattern P x = Just w
>   where
>      P :: Char -> Int
>      P x = ord x
> 
> This seems deeply peculiar to me.  No value produced by an expression using P can be consumed by a pattern matching on P.
> 
> My instinct is always to accept /fewer/ programs to start with, and expand in response to demand, rather than the reverse.
> 
> I don't feel qualified to judge how convincing the lens example is.
> 
> 
> |  Pattern synonyms are fundamentally about *syntax*. While particular
> |  use cases provide the motivation to have them, users are free to do
> |  with them as they will. I tend to think that a pattern synonym should
> 
> I don't agree.  A pattern synonym introduces an abstraction, and so far as possible we should be able to reason about it without looking inside it. We can't check that matching and construction are mutually inverse, but usually they should be.  Familiar laws should hold, so that
>    case P e of P y -> rhs
> means the same as
>    let y=e in rhs
> It's hard to enforce that, but I'd like to nudge programmers firmly in that direction.
> So I'm not convinced.  What about others.
> 
> Simon
> 
> 
> |  -----Original Message-----
> |  From: David Feuer [mailto:david.feuer at gmail.com <mailto:david.feuer at gmail.com>]
> |  Sent: 26 May 2017 00:08
> |  To: Simon Peyton Jones <simonpj at microsoft.com <mailto:simonpj at microsoft.com>>
> |  Cc: ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> |  Subject: Re: [ghc-steering-committee] GHC proposal #5
> |
> |  The reason I did not include the lens example in the original proposal
> |  is that I hadn't thought of it by then.
> |  I had the nagging feeling that I (or someone else) would eventually
> |  find a motivating example, but I didn't manage to come up with a
> |  sufficiently realistic one until last night.
> |  I'm sorry about that. As for your
> |  questions:
> |
> |  1. As I stated in the original pull request, before I was asked to
> |  modify it, I believe that the type signatures should not have any
> |  restrictions whatsoever. As the first example in my last email
> |  demonstrates, it seems impossible to actually preclude "unreasonable"
> |  pairs of signatures while still accomplishing the basic objectives. I
> |  don't think mismatched signatures are likely ever to be common, but I
> |  don't think making them harder to write and harder to read serves any
> |  obvious purpose. In the case of DefaultSignatures, there was
> |  apparently a compelling reason to impose a similar restriction to make
> |  correct implementation feasible.
> |  I am not aware of any similar reason in this case. Should one arise, I
> |  will certainly accept the restriction.
> |
> |  2. The ALens/Lens -> ReifiedLens pattern in my last email strikes me
> |  as a decent example: it may reasonable in some cases for pattern
> |  matching to provide a value with a type that subsumes the type
> |  required to apply the builder.
> |
> |  I imagine it might sometimes be useful to go in the opposite
> |  direction, but I haven't been able to find a good example of that yet.
> |  Intuitively, one possible direction an example might take would be a
> |  builder that requires its argument to be polymorphic in order to make
> |  some guarantee by parametricity, with an efficient monomorphic
> |  representation that can only provide a monomorphic pattern.
> |
> |  A final thought, for now:
> |
> |  Pattern synonyms are fundamentally about *syntax*. While particular
> |  use cases provide the motivation to have them, users are free to do
> |  with them as they will. I tend to think that a pattern synonym should
> |  always be cheap, both when building and when matching. Others
> |  disagree. I would be very much opposed to any attempt to restrict
> |  pattern synonyms to cheap operations, as a matter of principle. I
> |  similarly believe that building and matching should never throw
> |  exceptions or fail to terminate when given non-bottom input, but would
> |  oppose attempts to enforce such a law. In the present instance, I ask
> |  you to set aside how you think pattern synonyms and builders *should*
> |  relate in type, and to consider instead whether they really must.
> |
> |  Thanks,
> |  David
> |
> |  On Thu, May 25, 2017 at 5:57 PM, Simon Peyton Jones
> |  <simonpj at microsoft.com <mailto:simonpj at microsoft.com>> wrote:
> |  > So what do you propose?  The current rendered proposal has many
> |  alternatives, so I don't know what you propose.
> |  >
> |  > Moreover, all the example you give in the proposal /do/ obey the
> |  restriction; and all the /motivation/ in the proposal concerns
> |  variations in the constraints due to extra constraints required for
> |  pattern matching.
> |  >
> |  > So:
> |  >
> |  > * What proposal do you advocate? In particular...
> |  > * What restrictions -- if any! -- must the two type signatures
> |  satisfy
> |  > * What examples motivate whatever extra flexibility you advocate?
> |  >
> |  > Simon
> |  >
> |  > | -----Original Message-----
> |  > | From: ghc-steering-committee [mailto:ghc-steering-committee- <mailto:ghc-steering-committee->
> |  > | bounces at haskell.org <mailto:bounces at haskell.org>] On Behalf Of David Feuer
> |  > | Sent: 25 May 2017 06:28
> |  > | To: ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> |  > | Subject: [ghc-steering-committee] GHC proposal #5
> |  > |
> |  > | GHC proposal  #5 [*], which I drafted, was recently merged. I was
> |  > | asked to modify the proposal to restrict the type signatures of
> |  > | patterns and builders to be the same, except for their contexts. I
> |  > | would like to make one last plea to remove this restriction,
> |  unless
> |  > | there are fundamental reasons it cannot be done. The reasons are
> |  as follows.
> |  > |
> |  > | 1. Despite the restriction, it remains possible, at least in many
> |  > | cases, to achieve exactly the same effect, albeit in a manner that
> |  > | is considerably more difficult to read. For example, one could
> |  write
> |  > | the following (ill-advised) pattern:
> |  > |
> |  > | pattern Ha :: a ~ Int => Word -> a
> |  > | pattern Ha x <- (fromIntegral -> x)
> |  > |   where
> |  > |     Ha :: a ~ (Word -> Word) => Word -> a
> |  > |     Ha x = (x +)
> |  > |
> |  > | which, after more thinking than one might wish to apply, turns out
> |  > | to mean
> |  > |
> |  > | pattern Ha :: Word -> Int
> |  > | pattern Ha x <- (fromIntegral -> x)
> |  > |   where
> |  > |     Ha :: Word -> Word -> Word
> |  > |     Ha x = (x +)
> |  > |
> |  > | 2. It would be *extremely unpleasant* to make this trick work with
> |  > | RankNTypes, where such mismatched signatures seem likely to have
> |  the
> |  > | most practical value. For example, suppose I want to write
> |  > |
> |  > | import Control.Lens
> |  > | import Control.Lens.Reified
> |  > |
> |  > | pattern Package :: Lens s t a b -> ReifiedLens s t a b pattern
> |  > | Package f
> |  > | <- Lens f
> |  > |   where
> |  > |     Package :: ALens s t a b -> ReifiedLens s t a b
> |  > |     Package f = Lens $ cloneLens f
> |  > |
> |  > | This convenience pattern would pack up an ALens into a
> |  ReifiedLens;
> |  > | when unpacked, I'd get back a full Lens (The type Lens s t a b
> |  > | subsumes the type ALens s t a b). Without being able to use those
> |  > | different type signatures, I'd have to write something like this
> |  > | monstrosity:
> |  > |
> |  > | import Control.Lens.Internal.Context -- additionally
> |  > |
> |  > | pattern Package :: c ~ Functor
> |  > |                => (forall f. c f => LensLike f s t a b)
> |  > |                -> ReifiedLens s t a b pattern Package f <- Lens f
> |  > |   where
> |  > |     Package :: c ~ ((~) (Pretext (->) a b))
> |  > |            => (forall f. c f => LensLike f s t a b)
> |  > |            -> ReifiedLens s t a b
> |  > |     Package f = Lens $ cloneLens f
> |  > |
> |  > | I pity the poor soul who has to try to reverse engineer what those
> |  > | signatures are supposed to mean!
> |  > |
> |  > | While it's certainly possible to implement the restricted version
> |  > | now and expand it later, that would add *yet another*
> |  > | PatternSynonyms change for users to hack around with CPP. I hope
> |  > | you'll reconsider that decision in light of these examples.
> |  > |
> |  > | Thank you for your time,
> |  > | David Feuer
> |  > |
> |  > |
> |  > | [*]
> |  > |
> |  https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit>
> |  > | hub.c
> |  > | om%2Fghc-proposals%2Fghc-
> |  proposals%2Fblob%2Fmaster%2Fproposals%2F000
> |  > | 5-
> |  > | bidir-constr-
> |  > |
> |  sigs.rst&data=02%7C01%7Csimonpj%40microsoft.com <http://40microsoft.com/>%7C8f0f0cb282eb4990ce
> |  > | 1308d
> |  > |
> |  4a3b0fa63%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6363134278964
> |  > | 69235
> |  > | &sdata=pbr9v2OY4hhg5qmZNA9rEOBnbO5ttZG%2BDtvzbEUSNnI%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- <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering->
> |  commi
> |  > | ttee
> 
> _______________________________________________
> 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/20170530/ae182755/attachment-0001.html>

From david.feuer at gmail.com  Tue May 30 14:21:51 2017
From: david.feuer at gmail.com (David Feuer)
Date: Tue, 30 May 2017 10:21:51 -0400
Subject: [ghc-steering-committee] GHC proposal #5
In-Reply-To: <12C144C7-5E7C-4DAE-BB74-4CB28A6E1072@cs.brynmawr.edu>
References: <CAMgWh9v5u8ExGYsF-9zWEspR1OydrJGLVoYZw8JwCF5=GH8uaQ@mail.gmail.com>
 <DM2PR21MB0028F9BAA28FF0BFE84E3B96ADFF0@DM2PR21MB0028.namprd21.prod.outlook.com>
 <CAMgWh9vUuw1SWv+qBo6xhF8L9UoCEzD41An_ViE67w6Hj5R6ww@mail.gmail.com>
 <DM2PR21MB00288226B76104A5498C6A6CADFC0@DM2PR21MB0028.namprd21.prod.outlook.com>
 <CAMgWh9sPSF=vRVX+vgcwppNE2530y4SFYg7AAD-1e1S7kLPbHA@mail.gmail.com>
 <CAMgWh9tLRuzesbg=Q+GAvUnXx09Q9CVdrDFtr-oU6km3zoqXaw@mail.gmail.com>
 <12C144C7-5E7C-4DAE-BB74-4CB28A6E1072@cs.brynmawr.edu>
Message-ID: <CAMgWh9tSL_VCytoCz4FNw8M_Lqz9CH08XLSL6D3xWmxYeyP3Qg@mail.gmail.com>

All right. I don't personally think this should block implementation, but
I'll otherwise go ahead with the process you suggest.

On May 30, 2017 9:54 AM, "Richard Eisenberg" <rae at cs.brynmawr.edu> wrote:

> I'm afraid I think the best way to have this discussion is to submit
> another proposal. Is there a Trac ticket for the first one? That ticket
> should track implementation, and we could put a note there saying not to
> implement, pending the new proposal.
>
> Why do I want yet more process? Because I'm worried about having design
> conversations "behind closed doors", as doing so can be exclusionary. My
> other motivation is that I initially agree with Simon and say "no" -- but I
> want to give you a chance to convince me. Your best opportunity will be to
> get others to agree with you. Incidentally, my suggestion here agrees with
> what has been said on the initial pull request.
>
> Richard
>
> On May 26, 2017, at 2:58 PM, David Feuer <david.feuer at gmail.com> wrote:
>
> I thought of something that coops be a good compromise. You could require
> the signatures to be the same, modulo constraints, unless another extension
> allowed equality constraints. So using just PatternSynonyms, only
> "sensible" types would occur, but adding GADTs or TypeFamilies would let
> the signatures be totally wild.
>
> On May 26, 2017 9:10 AM, "David Feuer" <david.feuer at gmail.com> wrote:
>
>> I really am advocating allowing that, although I don't believe any
>> library writer should write such a ridiculous pattern. Here's my reasoning.
>> The proposal, even with the restriction, fundamentally adds expressiveness
>> to the pattern synonym extension. This is a good thing, because it allows
>> people to write substantially more useful patterns than they can today. As
>> soon as you add expressiveness, I think it makes sense to see just how much
>> you've added. As I've demonstrated, it seems that the restricted proposal
>> adds enough power to allow effectively unrelated pattern and builder
>> signatures. That is, the restriction doesn't really seem to restrict! So it
>> seems primarily to serve to punish anyone who wants to do something too
>> weird by making weird things inconvenient and ugly, which doesn't seem very
>> valuable to me.
>>
>> Note: I really want this proposal to go through, even if restricted; I
>> just don't see the wisdom of the restriction.
>>
>> David
>>
>> On May 26, 2017 8:54 AM, "Simon Peyton Jones" <simonpj at microsoft.com>
>> wrote:
>>
>> Are you really advocating NO restrictions?  Eg
>>
>> pattern P :: Int -> Maybe Int
>> pattern P x = Just w
>>   where
>>      P :: Char -> Int
>>      P x = ord x
>>
>> This seems deeply peculiar to me.  No value produced by an expression
>> using P can be consumed by a pattern matching on P.
>>
>> My instinct is always to accept /fewer/ programs to start with, and
>> expand in response to demand, rather than the reverse.
>>
>> I don't feel qualified to judge how convincing the lens example is.
>>
>>
>> |  Pattern synonyms are fundamentally about *syntax*. While particular
>> |  use cases provide the motivation to have them, users are free to do
>> |  with them as they will. I tend to think that a pattern synonym should
>>
>> I don't agree.  A pattern synonym introduces an abstraction, and so far
>> as possible we should be able to reason about it without looking inside it.
>> We can't check that matching and construction are mutually inverse, but
>> usually they should be.  Familiar laws should hold, so that
>>    case P e of P y -> rhs
>> means the same as
>>    let y=e in rhs
>> It's hard to enforce that, but I'd like to nudge programmers firmly in
>> that direction.
>> So I'm not convinced.  What about others.
>>
>> Simon
>>
>>
>> |  -----Original Message-----
>> |  From: David Feuer [mailto:david.feuer at gmail.com]
>> |  Sent: 26 May 2017 00:08
>> |  To: Simon Peyton Jones <simonpj at microsoft.com>
>> |  Cc: ghc-steering-committee at haskell.org
>> |  Subject: Re: [ghc-steering-committee] GHC proposal #5
>> |
>> |  The reason I did not include the lens example in the original proposal
>> |  is that I hadn't thought of it by then.
>> |  I had the nagging feeling that I (or someone else) would eventually
>> |  find a motivating example, but I didn't manage to come up with a
>> |  sufficiently realistic one until last night.
>> |  I'm sorry about that. As for your
>> |  questions:
>> |
>> |  1. As I stated in the original pull request, before I was asked to
>> |  modify it, I believe that the type signatures should not have any
>> |  restrictions whatsoever. As the first example in my last email
>> |  demonstrates, it seems impossible to actually preclude "unreasonable"
>> |  pairs of signatures while still accomplishing the basic objectives. I
>> |  don't think mismatched signatures are likely ever to be common, but I
>> |  don't think making them harder to write and harder to read serves any
>> |  obvious purpose. In the case of DefaultSignatures, there was
>> |  apparently a compelling reason to impose a similar restriction to make
>> |  correct implementation feasible.
>> |  I am not aware of any similar reason in this case. Should one arise, I
>> |  will certainly accept the restriction.
>> |
>> |  2. The ALens/Lens -> ReifiedLens pattern in my last email strikes me
>> |  as a decent example: it may reasonable in some cases for pattern
>> |  matching to provide a value with a type that subsumes the type
>> |  required to apply the builder.
>> |
>> |  I imagine it might sometimes be useful to go in the opposite
>> |  direction, but I haven't been able to find a good example of that yet.
>> |  Intuitively, one possible direction an example might take would be a
>> |  builder that requires its argument to be polymorphic in order to make
>> |  some guarantee by parametricity, with an efficient monomorphic
>> |  representation that can only provide a monomorphic pattern.
>> |
>> |  A final thought, for now:
>> |
>> |  Pattern synonyms are fundamentally about *syntax*. While particular
>> |  use cases provide the motivation to have them, users are free to do
>> |  with them as they will. I tend to think that a pattern synonym should
>> |  always be cheap, both when building and when matching. Others
>> |  disagree. I would be very much opposed to any attempt to restrict
>> |  pattern synonyms to cheap operations, as a matter of principle. I
>> |  similarly believe that building and matching should never throw
>> |  exceptions or fail to terminate when given non-bottom input, but would
>> |  oppose attempts to enforce such a law. In the present instance, I ask
>> |  you to set aside how you think pattern synonyms and builders *should*
>> |  relate in type, and to consider instead whether they really must.
>> |
>> |  Thanks,
>> |  David
>> |
>> |  On Thu, May 25, 2017 at 5:57 PM, Simon Peyton Jones
>> |  <simonpj at microsoft.com> wrote:
>> |  > So what do you propose?  The current rendered proposal has many
>> |  alternatives, so I don't know what you propose.
>> |  >
>> |  > Moreover, all the example you give in the proposal /do/ obey the
>> |  restriction; and all the /motivation/ in the proposal concerns
>> |  variations in the constraints due to extra constraints required for
>> |  pattern matching.
>> |  >
>> |  > So:
>> |  >
>> |  > * What proposal do you advocate? In particular...
>> |  > * What restrictions -- if any! -- must the two type signatures
>> |  satisfy
>> |  > * What examples motivate whatever extra flexibility you advocate?
>> |  >
>> |  > Simon
>> |  >
>> |  > | -----Original Message-----
>> |  > | From: ghc-steering-committee [mailto:ghc-steering-committee-
>> |  > | bounces at haskell.org] On Behalf Of David Feuer
>> |  > | Sent: 25 May 2017 06:28
>> |  > | To: ghc-steering-committee at haskell.org
>> |  > | Subject: [ghc-steering-committee] GHC proposal #5
>> |  > |
>> |  > | GHC proposal  #5 [*], which I drafted, was recently merged. I was
>> |  > | asked to modify the proposal to restrict the type signatures of
>> |  > | patterns and builders to be the same, except for their contexts. I
>> |  > | would like to make one last plea to remove this restriction,
>> |  unless
>> |  > | there are fundamental reasons it cannot be done. The reasons are
>> |  as follows.
>> |  > |
>> |  > | 1. Despite the restriction, it remains possible, at least in many
>> |  > | cases, to achieve exactly the same effect, albeit in a manner that
>> |  > | is considerably more difficult to read. For example, one could
>> |  write
>> |  > | the following (ill-advised) pattern:
>> |  > |
>> |  > | pattern Ha :: a ~ Int => Word -> a
>> |  > | pattern Ha x <- (fromIntegral -> x)
>> |  > |   where
>> |  > |     Ha :: a ~ (Word -> Word) => Word -> a
>> |  > |     Ha x = (x +)
>> |  > |
>> |  > | which, after more thinking than one might wish to apply, turns out
>> |  > | to mean
>> |  > |
>> |  > | pattern Ha :: Word -> Int
>> |  > | pattern Ha x <- (fromIntegral -> x)
>> |  > |   where
>> |  > |     Ha :: Word -> Word -> Word
>> |  > |     Ha x = (x +)
>> |  > |
>> |  > | 2. It would be *extremely unpleasant* to make this trick work with
>> |  > | RankNTypes, where such mismatched signatures seem likely to have
>> |  the
>> |  > | most practical value. For example, suppose I want to write
>> |  > |
>> |  > | import Control.Lens
>> |  > | import Control.Lens.Reified
>> |  > |
>> |  > | pattern Package :: Lens s t a b -> ReifiedLens s t a b pattern
>> |  > | Package f
>> |  > | <- Lens f
>> |  > |   where
>> |  > |     Package :: ALens s t a b -> ReifiedLens s t a b
>> |  > |     Package f = Lens $ cloneLens f
>> |  > |
>> |  > | This convenience pattern would pack up an ALens into a
>> |  ReifiedLens;
>> |  > | when unpacked, I'd get back a full Lens (The type Lens s t a b
>> |  > | subsumes the type ALens s t a b). Without being able to use those
>> |  > | different type signatures, I'd have to write something like this
>> |  > | monstrosity:
>> |  > |
>> |  > | import Control.Lens.Internal.Context -- additionally
>> |  > |
>> |  > | pattern Package :: c ~ Functor
>> |  > |                => (forall f. c f => LensLike f s t a b)
>> |  > |                -> ReifiedLens s t a b pattern Package f <- Lens f
>> |  > |   where
>> |  > |     Package :: c ~ ((~) (Pretext (->) a b))
>> |  > |            => (forall f. c f => LensLike f s t a b)
>> |  > |            -> ReifiedLens s t a b
>> |  > |     Package f = Lens $ cloneLens f
>> |  > |
>> |  > | I pity the poor soul who has to try to reverse engineer what those
>> |  > | signatures are supposed to mean!
>> |  > |
>> |  > | While it's certainly possible to implement the restricted version
>> |  > | now and expand it later, that would add *yet another*
>> |  > | PatternSynonyms change for users to hack around with CPP. I hope
>> |  > | you'll reconsider that decision in light of these examples.
>> |  > |
>> |  > | Thank you for your time,
>> |  > | David Feuer
>> |  > |
>> |  > |
>> |  > | [*]
>> |  > |
>> |  https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit
>> |  > | hub.c
>> |  > | om%2Fghc-proposals%2Fghc-
>> |  proposals%2Fblob%2Fmaster%2Fproposals%2F000
>> |  > | 5-
>> |  > | bidir-constr-
>> |  > |
>> |  sigs.rst&data=02%7C01%7Csimonpj%40microsoft.com%7C8f0f0cb282eb4990ce
>> |  > | 1308d
>> |  > |
>> |  4a3b0fa63%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6363134278964
>> |  > | 69235
>> |  > | &sdata=pbr9v2OY4hhg5qmZNA9rEOBnbO5ttZG%2BDtvzbEUSNnI%3D&reserved=0
>> |  > | _______________________________________________
>> |  > | ghc-steering-committee mailing list
>> |  > | ghc-steering-committee at haskell.org
>> |  > | https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-
>> |  commi
>> |  > | ttee
>>
>>
>> _______________________________________________
> 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/20170530/5e18bdbf/attachment-0001.html>