From cma at bitemyapp.com  Tue May  1 00:13:54 2018
From: cma at bitemyapp.com (Christopher Allen)
Date: Mon, 30 Apr 2018 19:13:54 -0500
Subject: [ghc-steering-committee] Resurrect Pattern Signatures (#119),
	Recommendation: accept
Message-ID: <CADnndOp6Rx0DLXwQV-6pRY8m63Qg1rPP+9jr2m3_Zej73x4Knw@mail.gmail.com>

This proposal splits out the faculty for assigning type signatures to
variables destructured out of a pattern from ScopedTypeVariables.

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

My recommendation is to accept the proposal, with some reservations.

ScopedTypeVariables is one of the more popular candidates for "this
should always be on regardless." The cases in which STV would be
useful greatly outnumber the downsides Gundry cited in my experience.
My impression of this upheld by my industrial experience and that of
the other industrial programmers I've talked to in the past about
ScopedTypeVariables. Almost any time it is brought up almost
invariably the conversation touches on, "why isn't this on by
default?"

I understand STV could break programs with overlapping names that are
intended to be independent type variables, I don't presume to litigate
or resolve that issue here.

Extension fatigue is wearing on the Haskell users I regularly interact
with, especially as it's unclear if Haskell Prime will convene and
consolidate commonly used extensions into the core language.

In my view these aren't sufficient reason to reject the proposed
extension on the merits so my recommendation is to accept it as-is. I
think the case for this proposal is particularly strong as it would
clean up the extension's presently somewhat confusing relationship
with STV.

If no objections are raised, it should be assumed that this has the
assent of the committee.

-- 
Chris Allen

From cma at bitemyapp.com  Tue May  1 00:20:38 2018
From: cma at bitemyapp.com (Christopher Allen)
Date: Mon, 30 Apr 2018 19:20:38 -0500
Subject: [ghc-steering-committee] Extra Commas (#87), Recommend: accept
Message-ID: <CADnndOpYDrL-BVn69seXAya0cSwm9N=xqLnsDKHTyoD5MGzAVA@mail.gmail.com>

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

With the provisos mentioned by Simon starting here in mind:
https://github.com/ghc-proposals/ghc-proposals/pull/87#issuecomment-385536587

I recommend we accept the proposal with the understanding that the
final specification or implementation could be handled by GHC's code
review process. I also have a concern about the potential interactions
with TupleSections.

If no objections are raised, it should be assumed that no one opposes
this proposal.

--- Chris Allen

From chak at justtesting.org  Tue May  1 01:58:22 2018
From: chak at justtesting.org (Manuel M T Chakravarty)
Date: Tue, 1 May 2018 11:58:22 +1000
Subject: [ghc-steering-committee] Extra Commas (#87), Recommend: accept
In-Reply-To: <CADnndOpYDrL-BVn69seXAya0cSwm9N=xqLnsDKHTyoD5MGzAVA@mail.gmail.com>
References: <CADnndOpYDrL-BVn69seXAya0cSwm9N=xqLnsDKHTyoD5MGzAVA@mail.gmail.com>
Message-ID: <46C3249E-5E68-4333-8776-DB130D226157@justtesting.org>

Seems fine provided Simon’s provisos are being addressed.

Cheers,
Manuel

> Am 01.05.2018 um 10:20 schrieb Christopher Allen <cma at bitemyapp.com>:
> 
> https://github.com/ghc-proposals/ghc-proposals/pull/87
> 
> With the provisos mentioned by Simon starting here in mind:
> https://github.com/ghc-proposals/ghc-proposals/pull/87#issuecomment-385536587
> 
> I recommend we accept the proposal with the understanding that the
> final specification or implementation could be handled by GHC's code
> review process. I also have a concern about the potential interactions
> with TupleSections.
> 
> If no objections are raised, it should be assumed that no one opposes
> this proposal.
> 
> --- Chris Allen
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 874 bytes
Desc: Message signed with OpenPGP
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20180501/775ee541/attachment.sig>

From chak at justtesting.org  Tue May  1 02:12:43 2018
From: chak at justtesting.org (Manuel M T Chakravarty)
Date: Tue, 1 May 2018 12:12:43 +1000
Subject: [ghc-steering-committee] Discussion on proposal #99: forall {k}
In-Reply-To: <CAGK9nuqSLUuf6FuzDHhr0PofG=KpjRVGee0J_j2LU+p4kt76rg@mail.gmail.com>
References: <CAGK9nuqSLUuf6FuzDHhr0PofG=KpjRVGee0J_j2LU+p4kt76rg@mail.gmail.com>
Message-ID: <64BD23D8-934F-403A-B8EB-8850A712BBDD@justtesting.org>

I assume, you meant to send this to ghc-steering-committee at haskell.org (in CC now) and not to the dev list.

Manuel

> 01.05.2018 02:12 Iavor Diatchki <iavor.diatchki at gmail.com>:
> 
> Hello,
> 
> As a shepherd for proposal #99, I'd like to kick off the discussion.  The full proposal is available here: https://github.com/goldfirere/ghc-proposals/blob/explicit-specificity/proposals/0000-explicit-specificity.rst <https://github.com/goldfirere/ghc-proposals/blob/explicit-specificity/proposals/0000-explicit-specificity.rst>
> 
> Summary: allows programmers to write `forall {x}` instead of `forall x` in type signatures.  The meaning of the braces is that this parameter cannot be instantiated with an explicit type application and will always be inferred.  The motivation is to shorten explicit type applications by skipping parameters that are known to be inferable, the common example being omitting the kinds in signatures with poly kinds.
> 
> As I understand it, the main motivation for this proposals is to give programmers more flexibility when instantiating type variables, with a less noisy syntax.   While the proposed solution might work in some situations, I am unconvinced that it is the best way to address the issue in general, for the following reasons:
> 
>   1. It requires that programmers commit at declaration time about which arguments will be inferred, and which may be inferred or specified.   While in some cases this may be an easy decision to make, in many cases this really is a decision which should be made at the use site of a function (e.g., I'd like to provide argument X, but would like GHC to infer argument Y).
> 
>   2. It still requires that programmers instantiate arguments in a fixed order,  which is sometimes dictated by the structure of the type itslef.  Here is, for example, what the proposal suggests to do if you want to provide type before a kind:
> 
>     typeRep4 :: forall {k} (a :: k) k'. (k ~ k', Typeable a) => TypeRep a
> 
>     While technically this is not wrong, it is not exactly elegant.
> 
> I think that we should reject this proposal, and try to come up with a more comprehensive solution to the problem.
> 
> One alternative design is to allow programmers to instantiate type variables by name.  This is much more flexible as it allows programmers to instantiate whichever variables they want, and in whatever order.  We've been doing this in Cryptol for a long time, and it seems to work really well.
> 
> -Iavor
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20180501/bc3004fc/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 874 bytes
Desc: Message signed with OpenPGP
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20180501/bc3004fc/attachment.sig>

From mail at joachim-breitner.de  Tue May  1 02:59:51 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 30 Apr 2018 22:59:51 -0400
Subject: [ghc-steering-committee] Extra Commas (#87), Recommend: accept
In-Reply-To: <CADnndOpYDrL-BVn69seXAya0cSwm9N=xqLnsDKHTyoD5MGzAVA@mail.gmail.com>
References: <CADnndOpYDrL-BVn69seXAya0cSwm9N=xqLnsDKHTyoD5MGzAVA@mail.gmail.com>
Message-ID: <c07a4db8535287683f9de45307a62b58c6c3fce1.camel@joachim-breitner.de>

Hi,


Am Montag, den 30.04.2018, 19:20 -0500 schrieb Christopher Allen:
> https://github.com/ghc-proposals/ghc-proposals/pull/87
> 
> With the provisos mentioned by Simon starting here in mind:
> https://github.com/ghc-proposals/ghc-proposals/pull/87#issuecomment-385536587

I am not against the proposal, but in the interest of fighting
extension fatigue I’d like to draw your attention to this (which I had 
just posted at https://github.com/ghc-proposals/ghc-proposals/pull/87#issuecomment-385581915)


If the motivation is really mainly about subexports lists, then we
could simply tell GHC to accept

   module Foo
       (
       Foo(A),
       Foo(B),
       )
   where

without warning about the duplicate export of `Foo`.


Is this good enough to solve the subexport list problem for CPP users?
(probably yes)

Do we still want ExtraCommas, because it is also useful in lists and
other syntactic constructs?
(probably probably; I could be swayed either way).


Cheers,
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/20180430/fb1f4645/attachment-0001.sig>

From simonpj at microsoft.com  Tue May  1 09:55:04 2018
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 1 May 2018 09:55:04 +0000
Subject: [ghc-steering-committee] Resurrect Pattern Signatures (#119),
	Recommendation: accept
In-Reply-To: <CADnndOp6Rx0DLXwQV-6pRY8m63Qg1rPP+9jr2m3_Zej73x4Knw@mail.gmail.com>
References: <CADnndOp6Rx0DLXwQV-6pRY8m63Qg1rPP+9jr2m3_Zej73x4Knw@mail.gmail.com>
Message-ID: <AM5PR83MB01636480913B115873FDA353AD810@AM5PR83MB0163.EURPRD83.prod.outlook.com>

I'm ok with this (not particularly keen, but ok), but see my comment:
https://github.com/ghc-proposals/ghc-proposals/pull/119/#issuecomment-385637259

|  -----Original Message-----
|  From: ghc-steering-committee <ghc-steering-committee-
|  bounces at haskell.org> On Behalf Of Christopher Allen
|  Sent: 01 May 2018 01:14
|  To: ghc-steering-committee at haskell.org
|  Subject: [ghc-steering-committee] Resurrect Pattern Signatures (#119),
|  Recommendation: accept
|  
|  This proposal splits out the faculty for assigning type signatures to
|  variables destructured out of a pattern from ScopedTypeVariables.
|  
|  https://github.com/ghc-proposals/ghc-proposals/pull/119/
|  
|  My recommendation is to accept the proposal, with some reservations.
|  
|  ScopedTypeVariables is one of the more popular candidates for "this
|  should always be on regardless." The cases in which STV would be
|  useful greatly outnumber the downsides Gundry cited in my experience.
|  My impression of this upheld by my industrial experience and that of
|  the other industrial programmers I've talked to in the past about
|  ScopedTypeVariables. Almost any time it is brought up almost
|  invariably the conversation touches on, "why isn't this on by
|  default?"
|  
|  I understand STV could break programs with overlapping names that are
|  intended to be independent type variables, I don't presume to litigate
|  or resolve that issue here.
|  
|  Extension fatigue is wearing on the Haskell users I regularly interact
|  with, especially as it's unclear if Haskell Prime will convene and
|  consolidate commonly used extensions into the core language.
|  
|  In my view these aren't sufficient reason to reject the proposed
|  extension on the merits so my recommendation is to accept it as-is. I
|  think the case for this proposal is particularly strong as it would
|  clean up the extension's presently somewhat confusing relationship
|  with STV.
|  
|  If no objections are raised, it should be assumed that this has the
|  assent of the committee.
|  
|  --
|  Chris Allen
|  _______________________________________________
|  ghc-steering-committee mailing list
|  ghc-steering-committee at haskell.org
|  https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-
|  committee

From simonpj at microsoft.com  Tue May  1 10:55:28 2018
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 1 May 2018 10:55:28 +0000
Subject: [ghc-steering-committee] Discussion on proposal #99: forall {k}
In-Reply-To: <CAGK9nuqSLUuf6FuzDHhr0PofG=KpjRVGee0J_j2LU+p4kt76rg@mail.gmail.com>
References: <CAGK9nuqSLUuf6FuzDHhr0PofG=KpjRVGee0J_j2LU+p4kt76rg@mail.gmail.com>
Message-ID: <AM5PR83MB01638A81718CBB12CA0BCE45AD810@AM5PR83MB0163.EURPRD83.prod.outlook.com>

[Redirecting to the steering committee]

I argue for acceptance.


  *   For me a compelling motivation is this: at the moment we can infer types and kinds that we cannot write down with an explicitly-quantified type signature.  That seems all wrong to me: we should be able to write down any type you can infer.
  *   The proposal adds notation.  It does not add semantics.  We already have the distinction between “inferred” and “specified” type variables.  You might not like it, but it’s there in GHC.
     *   If it wasn’t there already, I’d be happy to debate not adding it.
     *   If you want to argue for removing the distinction, that would certainly render the current proposal moot.  But that would take a GHC proposal – and there are good reasons for the status quo!
     *   What is bad is to maintain the semantic distinction, but be unable to express it.  That’s what we have right now, and it’s a bad thing.

What is the distinction between “specified” and “inferred”?

  *   Specified.   f :: forall a. blah, or   f :: a -> a.

You may give a visible type argument at a call of f, but you do not have to.  Thus  (f x) or (f @type x).



  *   Inferred.  f :: t a -> t a.  The type of f is really

g :: forall {k} (t :: k -> *) (a :: k). t a -> t a
Note that k does not appear at all in the signature; that’s why it is “inferred”.  In GHC today you cannot supply an explicit kind argument for g, but you can supply explicit argument for t and a.

So by all means make the case for abolishing the distinction, to render the present proposal moot.  But I think it’s unreasonably simply to reject on the grounds of “please think of something better”.

Simon

From: ghc-devs <ghc-devs-bounces at haskell.org> On Behalf Of Iavor Diatchki
Sent: 30 April 2018 17:12
To: ghc-devs at haskell.org
Subject: Discussion on proposal #99: forall {k}

Hello,

As a shepherd for proposal #99, I'd like to kick off the discussion.  The full proposal is available here: https://github.com/goldfirere/ghc-proposals/blob/explicit-specificity/proposals/0000-explicit-specificity.rst

Summary: allows programmers to write `forall {x}` instead of `forall x` in type signatures.  The meaning of the braces is that this parameter cannot be instantiated with an explicit type application and will always be inferred.  The motivation is to shorten explicit type applications by skipping parameters that are known to be inferable, the common example being omitting the kinds in signatures with poly kinds.

As I understand it, the main motivation for this proposals is to give programmers more flexibility when instantiating type variables, with a less noisy syntax.   While the proposed solution might work in some situations, I am unconvinced that it is the best way to address the issue in general, for the following reasons:

  1. It requires that programmers commit at declaration time about which arguments will be inferred, and which may be inferred or specified.   While in some cases this may be an easy decision to make, in many cases this really is a decision which should be made at the use site of a function (e.g., I'd like to provide argument X, but would like GHC to infer argument Y).

  2. It still requires that programmers instantiate arguments in a fixed order,  which is sometimes dictated by the structure of the type itslef.  Here is, for example, what the proposal suggests to do if you want to provide type before a kind:

    typeRep4 :: forall {k} (a :: k) k'. (k ~ k', Typeable a) => TypeRep a

    While technically this is not wrong, it is not exactly elegant.

I think that we should reject this proposal, and try to come up with a more comprehensive solution to the problem.

One alternative design is to allow programmers to instantiate type variables by name.  This is much more flexible as it allows programmers to instantiate whichever variables they want, and in whatever order.  We've been doing this in Cryptol for a long time, and it seems to work really well.

-Iavor








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

From mail at joachim-breitner.de  Tue May  1 12:12:01 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 01 May 2018 08:12:01 -0400
Subject: [ghc-steering-committee] Please Review: Array resizing primitives
 (#121), Shepherd: Simon Marlow
Message-ID: <0b18081bcb2172a0ba93729de5011239fd69f39c.camel@joachim-breitner.de>

Dear Committee,

this is your secretary speaking:

Array resizing primitives have been proposed by David Feuer:
https://github.com/ghc-proposals/ghc-proposals/pull/121

I propose Simon Marlow as the shepherd.

Simon, please reach consensus as described in
https://github.com/ghc-proposals/ghc-proposals#committee-process

I suggest you make a recommendation, in a new e-mail thread with the
proposal number in the subject, about the decision, maybe point out
debatable points, and assume that anyone who stays quiet agrees with
you.

Thanks,
-- 
Joachim 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/20180501/45e7ab9f/attachment.sig>

From iavor.diatchki at gmail.com  Tue May  1 16:56:20 2018
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Tue, 01 May 2018 16:56:20 +0000
Subject: [ghc-steering-committee] Discussion on proposal #99: forall {k}
In-Reply-To: <AM5PR83MB01638A81718CBB12CA0BCE45AD810@AM5PR83MB0163.EURPRD83.prod.outlook.com>
References: <CAGK9nuqSLUuf6FuzDHhr0PofG=KpjRVGee0J_j2LU+p4kt76rg@mail.gmail.com>
 <AM5PR83MB01638A81718CBB12CA0BCE45AD810@AM5PR83MB0163.EURPRD83.prod.outlook.com>
Message-ID: <CAGK9nuqEyHcrt9YZoMg+kawhNJ8jH7YFRyf1cJDNYyVgaMYsLw@mail.gmail.com>

Hello,

I just re-read the proposal and I am a bit unclear:  are we proposing that
we make this change only in type signatures or in all places where we bind
type variables?  At first I thought we are talking only about type
signatures, but I noticed that the proposal seems to mention type classes,
but not `data` declarations or type families.  I find the "implicit" hidden
parameters in those to be one of the most confusing features of GHC, so
having a way to write those would certainly be useful.  I do have some
clarifying questions illustrated by the examples below (assuming that this
extension should work on `data`):

-- 1) The "normal" case.  I've written the types of the introduces names
underneath, are they correct?
data T1 {k} (a :: k) = C1
-- T1 :: forall {k::Type}. k -> Type
-- C1 :: forall {k::Type} (a :: k). T1 {k} a
-- Am I correct in assuming that while GHC could print the types like that,
but users are not allowed to actually write those types (i.e., `T1 {k}
(a::k)` is not a valid type).

-- 2) Can GHC add extra inferred parameters? (This examples assumes
`PolyKinds`)
data T2 {k} a = C2
-- C2 :: forall {k1::Type} {k::Type} (a :: k1). T2 {k1} {k} a   (ambiguous?)

-- 3) Can we infer non-kind types?
data T3 {a} = C3 a
-- C3 :: forall {a::Type}. a -> T3 {a}

-- 4) If `T3` is OK, how does "inferring" work in signatures? To make
things concrete, would the following be accepted?
f :: T3
f = C3 True
-- A): not, because the signature is really: `forall {a}. T3 {a}`.
-- B): yes, because we are going to infer that the missing type is `Bool`,
so the signature becomes `T3 {Bool}`.

-- 5) The proposal has a class, something like this:
class C a {b} where
  meth1 :: a -> b

-- How do I write an instance for this class?
-- A)
instance C Int where
    meth1 x = x

-- B)
instance C Int {Int} where
    meth1 x = x

I imagine the answer is A) is I see nothing about writing types like
`{Int}`.  If so, here are a couple of follow up questions about instances:

-- Valid?
instance C Int where
    meth1 x = []
-- instance is really `forall {a::Type}. C Int {[a]}` ?

instance C Int where
    meth1 x = return x
--- error, instance is `C Int {m Int}`, but no `Monad` constraint.
-- There doesn't seem to be a way to write the instance with the constraint?

Sorry for the long e-mail, but I hope that these examples might bring some
clarity to users of the proposed feature.

-Iavor



On Tue, May 1, 2018 at 3:55 AM Simon Peyton Jones <simonpj at microsoft.com>
wrote:

> [Redirecting to the steering committee]
>
>
>
> I argue for acceptance.
>
>
>
>    - For me a compelling motivation is this: at the moment *we can infer
>    types and kinds that we cannot write down with an explicitly-quantified
>    type signature*.  That seems all wrong to me: we should be able to
>    write down any type you can infer.
>    - The proposal adds *notation*.  It does *not* add semantics.  We
>    already have the distinction between “inferred” and “specified” type
>    variables.  You might not like it, but it’s there in GHC.
>       - If it wasn’t there already, I’d be happy to debate not adding
>       it.
>       - If you want to argue for removing the distinction, that would
>       certainly render the current proposal moot.  But that would take a GHC
>       proposal – and there are good reasons for the status quo!
>       - What is bad is to maintain the semantic distinction, but be
>       unable to express it.  That’s what we have right now, and it’s a bad thing.
>
>
>
> What is the distinction between “specified” and “inferred”?
>
>    - *Specified.   f :: forall a. blah, or   f :: a -> a.*
>
> You may give a visible type argument at a call of f, but you do not have
> to.  Thus  (f x) or (f @type x).
>
>
>
>    - *Inferred*.  *f :: t a -> t a.*  The type of f is really
>
> g :: forall {k} (t :: k -> *) (a :: k). t a -> t a
>
> Note that k does not appear at all in the signature; that’s why it is
> “inferred”.  In GHC today you cannot supply an explicit kind argument for
> g, but you can supply explicit argument for t and a.
>
>
>
> So by all means make the case for abolishing the distinction, to render
> the present proposal moot.  But I think it’s unreasonably simply to reject
> on the grounds of “please think of something better”.
>
>
>
> Simon
>
>
>
> *From:* ghc-devs <ghc-devs-bounces at haskell.org> *On Behalf Of *Iavor
> Diatchki
> *Sent:* 30 April 2018 17:12
> *To:* ghc-devs at haskell.org
> *Subject:* Discussion on proposal #99: forall {k}
>
>
>
> Hello,
>
>
>
> As a shepherd for proposal #99, I'd like to kick off the discussion.  The
> full proposal is available here:
> https://github.com/goldfirere/ghc-proposals/blob/explicit-specificity/proposals/0000-explicit-specificity.rst
>
>
>
> Summary: allows programmers to write `forall {x}` instead of `forall x` in
> type signatures.  The meaning of the braces is that this parameter cannot
> be instantiated with an explicit type application and will always be
> inferred.  The motivation is to shorten explicit type applications by
> skipping parameters that are known to be inferable, the common example
> being omitting the kinds in signatures with poly kinds.
>
>
>
> As I understand it, the main motivation for this proposals is to give
> programmers more flexibility when instantiating type variables, with a less
> noisy syntax.   While the proposed solution might work in some situations,
> I am unconvinced that it is the best way to address the issue in general,
> for the following reasons:
>
>
>
>   1. It requires that programmers commit at declaration time about which
> arguments will be inferred, and which may be inferred or specified.   While
> in some cases this may be an easy decision to make, in many cases this
> really is a decision which should be made at the use site of a function
> (e.g., I'd like to provide argument X, but would like GHC to infer argument
> Y).
>
>
>
>   2. It still requires that programmers instantiate arguments in a fixed
> order,  which is sometimes dictated by the structure of the type itslef.
> Here is, for example, what the proposal suggests to do if you want to
> provide type before a kind:
>
>
>
>     typeRep4 :: forall {k} (a :: k) k'. (k ~ k', Typeable a) => TypeRep a
>
>
>
>     While technically this is not wrong, it is not exactly elegant.
>
>
>
> I think that we should reject this proposal, and try to come up with a
> more comprehensive solution to the problem.
>
>
>
> One alternative design is to allow programmers to instantiate type
> variables by name.  This is much more flexible as it allows programmers to
> instantiate whichever variables they want, and in whatever order.  We've
> been doing this in Cryptol for a long time, and it seems to work really
> well.
>
>
>
> -Iavor
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20180501/d9a2be6f/attachment.html>

From rae at cs.brynmawr.edu  Wed May  2 02:05:35 2018
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Tue, 1 May 2018 22:05:35 -0400
Subject: [ghc-steering-committee] Discussion on proposal #99: forall {k}
In-Reply-To: <CAGK9nuqEyHcrt9YZoMg+kawhNJ8jH7YFRyf1cJDNYyVgaMYsLw@mail.gmail.com>
References: <CAGK9nuqSLUuf6FuzDHhr0PofG=KpjRVGee0J_j2LU+p4kt76rg@mail.gmail.com>
 <AM5PR83MB01638A81718CBB12CA0BCE45AD810@AM5PR83MB0163.EURPRD83.prod.outlook.com>
 <CAGK9nuqEyHcrt9YZoMg+kawhNJ8jH7YFRyf1cJDNYyVgaMYsLw@mail.gmail.com>
Message-ID: <7EB6937A-086F-415C-81DC-C44BCA716DFB@cs.brynmawr.edu>

The proposal, as written, affects only type signatures and class declarations. It does not cover datatype declarations, though perhaps it should. This seems to be an oversight.

A key problem with this notation in type declarations is that H98-syntax datatype and class declarations do two things: they create a new type and they also inform the types of term-level definitions. In the case of a datatype, the terms are the constructors; in the case of a class, the terms are the methods.

Suppose we want to make term-level definitions suppress a certain variable but not to suppress this variable in the type definition? For example, perhaps we want data Proxy k (a :: k) = P, where Proxy :: forall k -> k -> Type, but P :: forall {k} (a :: k). Proxy k a. Note the different visibilities at the different levels.

We can boil it down to one rule for these situations:
 RULE. Braces used in type declarations affect only the types of terms declared within the declaration. The braces have no effect whatsoever on the kind of the type(s) declared.

With this in mind, I'll answer the questions below:

> On May 1, 2018, at 12:56 PM, Iavor Diatchki <iavor.diatchki at gmail.com> wrote:
> 
> -- 1) The "normal" case.  I've written the types of the introduces names underneath, are they correct?
> data T1 {k} (a :: k) = C1
> -- T1 :: forall {k::Type}. k -> Type
> -- C1 :: forall {k::Type} (a :: k). T1 {k} a

I would say we get

T1 :: forall (k :: Type) -> k -> Type    -- T1 has *2* visible arguments
C1 :: forall {k :: Type} (a :: k). T1 k a   -- C1 has one inferred and one specified type argument

> -- Am I correct in assuming that while GHC could print the types like that, but users are not allowed to actually write those types (i.e., `T1 {k} (a::k)` is not a valid type).

GHC will print braces only around inferred-variable binding sites, not usage sites. If we wanted k not to be visible in the kind of T1, then one comment on the thread proposed

data T1' @k (a :: k) = C1'

which would yield

T1' :: forall (k :: Type). k -> Type
C1' :: forall (k :: Type) (a :: k). T1' a

I imagine we could combine the two, so that

data T1'' @{k} (a :: k) = C1''

would yield

T1'' :: forall (k :: Type). k -> Type
C1'' :: forall {k :: Type} (a :: k). T1'' a

Under this idea, there would be no way to get k to be *inferred* in the type's kind. A top-level kind signature (#54) would be necessary.

Note that the extensions discussed here, with @, are *not* part of this proposal, but might be a future one.

> 
> -- 2) Can GHC add extra inferred parameters? (This examples assumes `PolyKinds`)
> data T2 {k} a = C2
> -- C2 :: forall {k1::Type} {k::Type} (a :: k1). T2 {k1} {k} a   (ambiguous?)

I get

T2 :: forall {x :: Type} {y :: Type}. x -> y -> Type
C2 :: forall {x :: Type} {y :: Type} {k :: x} (a :: y). T2 k a

This is not an ambiguous type, because all the variables are determined by the (injective) result type.

So, in answer to your question: yes.

> 
> -- 3) Can we infer non-kind types?
> data T3 {a} = C3 a
> -- C3 :: forall {a::Type}. a -> T3 {a}

I get

T3 :: Type -> Type
C3 :: forall {a :: Type}. a -> T3 a

In answer to your question: yes.

> 
> -- 4) If `T3` is OK, how does "inferring" work in signatures? To make things concrete, would the following be accepted?
> f :: T3
> f = C3 True 
> -- A): not, because the signature is really: `forall {a}. T3 {a}`.
> -- B): yes, because we are going to infer that the missing type is `Bool`, so the signature becomes `T3 {Bool}`.

C) not, because T3 still has a visible argument, and therefore T3 has kind `Type -> Type`, which is inappropriate for a type signature.

> 
> -- 5) The proposal has a class, something like this:
> class C a {b} where
>   meth1 :: a -> b
> 
> -- How do I write an instance for this class?
> -- A)
> instance C Int where
>     meth1 x = x 
> 
> -- B)
> instance C Int {Int} where
>     meth1 x = x
> 
> I imagine the answer is A) is I see nothing about writing types like `{Int}`.  If so, here are a couple of follow up questions about instances:
> 

Neither. I would write

instance C Int Int where
  meth1 x = x

The braces in the type declaration affect only the term-level definitions therein, not the type definition, according to RULE.

> -- Valid?
> instance C Int where
>     meth1 x = []
> -- instance is really `forall {a::Type}. C Int {[a]}` ?
> 
> instance C Int where
>     meth1 x = return x
> --- error, instance is `C Int {m Int}`, but no `Monad` constraint.
> -- There doesn't seem to be a way to write the instance with the constraint?

These are not valid.

> 
> Sorry for the long e-mail, but I hope that these examples might bring some clarity to users of the proposed feature.

These questions are really helpful in poking at the squishy spots! Thanks.

Richard

> 
> -Iavor
> 
> 
> 
> On Tue, May 1, 2018 at 3:55 AM Simon Peyton Jones <simonpj at microsoft.com <mailto:simonpj at microsoft.com>> wrote:
> [Redirecting to the steering committee]
> 
>  
> 
> I argue for acceptance.
> 
>  
> 
> For me a compelling motivation is this: at the moment we can infer types and kinds that we cannot write down with an explicitly-quantified type signature.  That seems all wrong to me: we should be able to write down any type you can infer.
> The proposal adds notation.  It does not add semantics.  We already have the distinction between “inferred” and “specified” type variables.  You might not like it, but it’s there in GHC.
> If it wasn’t there already, I’d be happy to debate not adding it. 
> If you want to argue for removing the distinction, that would certainly render the current proposal moot.  But that would take a GHC proposal – and there are good reasons for the status quo!
> What is bad is to maintain the semantic distinction, but be unable to express it.  That’s what we have right now, and it’s a bad thing.
>  
> 
> What is the distinction between “specified” and “inferred”?
> 
> Specified.   f :: forall a. blah, or   f :: a -> a. 
> You may give a visible type argument at a call of f, but you do not have to.  Thus  (f x) or (f @type x).
> 
>  
> 
> Inferred.  f :: t a -> t a.  The type of f is really
> g :: forall {k} (t :: k -> *) (a :: k). t a -> t a
> 
> Note that k does not appear at all in the signature; that’s why it is “inferred”.  In GHC today you cannot supply an explicit kind argument for g, but you can supply explicit argument for t and a.
> 
>  
> 
> So by all means make the case for abolishing the distinction, to render the present proposal moot.  But I think it’s unreasonably simply to reject on the grounds of “please think of something better”.
> 
>  
> 
> Simon
> 
>  
> 
> From: ghc-devs <ghc-devs-bounces at haskell.org <mailto:ghc-devs-bounces at haskell.org>> On Behalf Of Iavor Diatchki
> Sent: 30 April 2018 17:12
> To: ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>
> Subject: Discussion on proposal #99: forall {k}
> 
>  
> 
> Hello,
> 
>  
> 
> As a shepherd for proposal #99, I'd like to kick off the discussion.  The full proposal is available here: https://github.com/goldfirere/ghc-proposals/blob/explicit-specificity/proposals/0000-explicit-specificity.rst <https://github.com/goldfirere/ghc-proposals/blob/explicit-specificity/proposals/0000-explicit-specificity.rst>
>  
> 
> Summary: allows programmers to write `forall {x}` instead of `forall x` in type signatures.  The meaning of the braces is that this parameter cannot be instantiated with an explicit type application and will always be inferred.  The motivation is to shorten explicit type applications by skipping parameters that are known to be inferable, the common example being omitting the kinds in signatures with poly kinds.
> 
>  
> 
> As I understand it, the main motivation for this proposals is to give programmers more flexibility when instantiating type variables, with a less noisy syntax.   While the proposed solution might work in some situations, I am unconvinced that it is the best way to address the issue in general, for the following reasons:
> 
>  
> 
>   1. It requires that programmers commit at declaration time about which arguments will be inferred, and which may be inferred or specified.   While in some cases this may be an easy decision to make, in many cases this really is a decision which should be made at the use site of a function (e.g., I'd like to provide argument X, but would like GHC to infer argument Y).
> 
>  
> 
>   2. It still requires that programmers instantiate arguments in a fixed order,  which is sometimes dictated by the structure of the type itslef.  Here is, for example, what the proposal suggests to do if you want to provide type before a kind:
> 
>  
> 
>     typeRep4 :: forall {k} (a :: k) k'. (k ~ k', Typeable a) => TypeRep a
> 
>  
> 
>     While technically this is not wrong, it is not exactly elegant.
> 
>  
> 
> I think that we should reject this proposal, and try to come up with a more comprehensive solution to the problem.
> 
>  
> 
> One alternative design is to allow programmers to instantiate type variables by name.  This is much more flexible as it allows programmers to instantiate whichever variables they want, and in whatever order.  We've been doing this in Cryptol for a long time, and it seems to work really well.
> 
>  
> 
> -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/20180501/0491aa96/attachment-0001.html>

From rae at cs.brynmawr.edu  Wed May  2 02:33:07 2018
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Tue, 1 May 2018 22:33:07 -0400
Subject: [ghc-steering-committee] Discussion on proposal #99: forall {k}
In-Reply-To: <7EB6937A-086F-415C-81DC-C44BCA716DFB@cs.brynmawr.edu>
References: <CAGK9nuqSLUuf6FuzDHhr0PofG=KpjRVGee0J_j2LU+p4kt76rg@mail.gmail.com>
 <AM5PR83MB01638A81718CBB12CA0BCE45AD810@AM5PR83MB0163.EURPRD83.prod.outlook.com>
 <CAGK9nuqEyHcrt9YZoMg+kawhNJ8jH7YFRyf1cJDNYyVgaMYsLw@mail.gmail.com>
 <7EB6937A-086F-415C-81DC-C44BCA716DFB@cs.brynmawr.edu>
Message-ID: <4EE047D9-E17D-4E7F-9706-1D4B397779A0@cs.brynmawr.edu>

In thinking about this more, I created a new proposal, #131 (https://github.com/ghc-proposals/ghc-proposals/pull/131 <https://github.com/ghc-proposals/ghc-proposals/pull/131>), which is the best alternative I can think of to this proposal. Indeed, I think it's the "more comprehensive solution" Iavor seeks. (Though it doesn't use nominal arguments.) Sadly, I don't think #131 is implementable, though it's specification is wonderfully straightforward.

I post #131 essentially as a counterpoint to the current proposal. If #131 were implementable, I would favor that and abandon this one.

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

From simonpj at microsoft.com  Tue May  1 22:08:36 2018
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 1 May 2018 22:08:36 +0000
Subject: [ghc-steering-committee] Discussion on proposal #99: forall {k}
In-Reply-To: <CAGK9nuqEyHcrt9YZoMg+kawhNJ8jH7YFRyf1cJDNYyVgaMYsLw@mail.gmail.com>
References: <CAGK9nuqSLUuf6FuzDHhr0PofG=KpjRVGee0J_j2LU+p4kt76rg@mail.gmail.com>
 <AM5PR83MB01638A81718CBB12CA0BCE45AD810@AM5PR83MB0163.EURPRD83.prod.outlook.com>
 <CAGK9nuqEyHcrt9YZoMg+kawhNJ8jH7YFRyf1cJDNYyVgaMYsLw@mail.gmail.com>
Message-ID: <AM5PR83MB0163B60485612373F9E65700AD810@AM5PR83MB0163.EURPRD83.prod.outlook.com>

All good questions.  Since Richard is on this list I’ll let him reply – but Ricahrd, I urge you to make the answers to these questions clear in the proposal itself.

On one point
Am I correct in assuming that while GHC could print the types like that, but users are not allowed to actually write those types

Yes, that’s what bothers me.  GHC embodies a distinction that it faithfully implements, and can print out (with `-fprint-explicit-foralls`, but the user cannot write.  It seems Very Bad to have types that can be inferred but not declared.    That’s partly why I’m arguing that the status quo is a bad place to sit.

Simon

From: Iavor Diatchki <iavor.diatchki at gmail.com>
Sent: 01 May 2018 17:56
To: Simon Peyton Jones <simonpj at microsoft.com>
Cc: ghc-steering-committee at haskell.org
Subject: Re: Discussion on proposal #99: forall {k}

Hello,

I just re-read the proposal and I am a bit unclear:  are we proposing that we make this change only in type signatures or in all places where we bind type variables?  At first I thought we are talking only about type signatures, but I noticed that the proposal seems to mention type classes, but not `data` declarations or type families.  I find the "implicit" hidden parameters in those to be one of the most confusing features of GHC, so having a way to write those would certainly be useful.  I do have some clarifying questions illustrated by the examples below (assuming that this extension should work on `data`):

-- 1) The "normal" case.  I've written the types of the introduces names underneath, are they correct?
data T1 {k} (a :: k) = C1
-- T1 :: forall {k::Type}. k -> Type
-- C1 :: forall {k::Type} (a :: k). T1 {k} a
-- Am I correct in assuming that while GHC could print the types like that, but users are not allowed to actually write those types (i.e., `T1 {k} (a::k)` is not a valid type).

-- 2) Can GHC add extra inferred parameters? (This examples assumes `PolyKinds`)
data T2 {k} a = C2
-- C2 :: forall {k1::Type} {k::Type} (a :: k1). T2 {k1} {k} a   (ambiguous?)

-- 3) Can we infer non-kind types?
data T3 {a} = C3 a
-- C3 :: forall {a::Type}. a -> T3 {a}

-- 4) If `T3` is OK, how does "inferring" work in signatures? To make things concrete, would the following be accepted?
f :: T3
f = C3 True
-- A): not, because the signature is really: `forall {a}. T3 {a}`.
-- B): yes, because we are going to infer that the missing type is `Bool`, so the signature becomes `T3 {Bool}`.

-- 5) The proposal has a class, something like this:
class C a {b} where
  meth1 :: a -> b

-- How do I write an instance for this class?
-- A)
instance C Int where
    meth1 x = x

-- B)
instance C Int {Int} where
    meth1 x = x

I imagine the answer is A) is I see nothing about writing types like `{Int}`.  If so, here are a couple of follow up questions about instances:

-- Valid?
instance C Int where
    meth1 x = []
-- instance is really `forall {a::Type}. C Int {[a]}` ?

instance C Int where
    meth1 x = return x
--- error, instance is `C Int {m Int}`, but no `Monad` constraint.
-- There doesn't seem to be a way to write the instance with the constraint?

Sorry for the long e-mail, but I hope that these examples might bring some clarity to users of the proposed feature.

-Iavor



On Tue, May 1, 2018 at 3:55 AM Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:
[Redirecting to the steering committee]

I argue for acceptance.


  *   For me a compelling motivation is this: at the moment we can infer types and kinds that we cannot write down with an explicitly-quantified type signature.  That seems all wrong to me: we should be able to write down any type you can infer.
  *   The proposal adds notation.  It does not add semantics.  We already have the distinction between “inferred” and “specified” type variables.  You might not like it, but it’s there in GHC.

     *   If it wasn’t there already, I’d be happy to debate not adding it.
     *   If you want to argue for removing the distinction, that would certainly render the current proposal moot.  But that would take a GHC proposal – and there are good reasons for the status quo!
     *   What is bad is to maintain the semantic distinction, but be unable to express it.  That’s what we have right now, and it’s a bad thing.

What is the distinction between “specified” and “inferred”?

  *   Specified.   f :: forall a. blah, or   f :: a -> a.

You may give a visible type argument at a call of f, but you do not have to.  Thus  (f x) or (f @type x).



  *   Inferred.  f :: t a -> t a.  The type of f is really

g :: forall {k} (t :: k -> *) (a :: k). t a -> t a
Note that k does not appear at all in the signature; that’s why it is “inferred”.  In GHC today you cannot supply an explicit kind argument for g, but you can supply explicit argument for t and a.

So by all means make the case for abolishing the distinction, to render the present proposal moot.  But I think it’s unreasonably simply to reject on the grounds of “please think of something better”.

Simon

From: ghc-devs <ghc-devs-bounces at haskell.org<mailto:ghc-devs-bounces at haskell.org>> On Behalf Of Iavor Diatchki
Sent: 30 April 2018 17:12
To: ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
Subject: Discussion on proposal #99: forall {k}

Hello,

As a shepherd for proposal #99, I'd like to kick off the discussion.  The full proposal is available here: https://github.com/goldfirere/ghc-proposals/blob/explicit-specificity/proposals/0000-explicit-specificity.rst<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoldfirere%2Fghc-proposals%2Fblob%2Fexplicit-specificity%2Fproposals%2F0000-explicit-specificity.rst&data=02%7C01%7Csimonpj%40microsoft.com%7C8b8abc82d3844e6ac16108d5af847f8e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636607905970942446&sdata=pQJfEQnIdUsezJ06209Hqhx8%2Fqey1r%2BL556roQTX4Rk%3D&reserved=0>

Summary: allows programmers to write `forall {x}` instead of `forall x` in type signatures.  The meaning of the braces is that this parameter cannot be instantiated with an explicit type application and will always be inferred.  The motivation is to shorten explicit type applications by skipping parameters that are known to be inferable, the common example being omitting the kinds in signatures with poly kinds.

As I understand it, the main motivation for this proposals is to give programmers more flexibility when instantiating type variables, with a less noisy syntax.   While the proposed solution might work in some situations, I am unconvinced that it is the best way to address the issue in general, for the following reasons:

  1. It requires that programmers commit at declaration time about which arguments will be inferred, and which may be inferred or specified.   While in some cases this may be an easy decision to make, in many cases this really is a decision which should be made at the use site of a function (e.g., I'd like to provide argument X, but would like GHC to infer argument Y).

  2. It still requires that programmers instantiate arguments in a fixed order,  which is sometimes dictated by the structure of the type itslef.  Here is, for example, what the proposal suggests to do if you want to provide type before a kind:

    typeRep4 :: forall {k} (a :: k) k'. (k ~ k', Typeable a) => TypeRep a

    While technically this is not wrong, it is not exactly elegant.

I think that we should reject this proposal, and try to come up with a more comprehensive solution to the problem.

One alternative design is to allow programmers to instantiate type variables by name.  This is much more flexible as it allows programmers to instantiate whichever variables they want, and in whatever order.  We've been doing this in Cryptol for a long time, and it seems to work really well.

-Iavor








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

From simonpj at microsoft.com  Wed May  2 08:47:40 2018
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 2 May 2018 08:47:40 +0000
Subject: [ghc-steering-committee] Discussion on proposal #99: forall {k}
In-Reply-To: <7EB6937A-086F-415C-81DC-C44BCA716DFB@cs.brynmawr.edu>
References: <CAGK9nuqSLUuf6FuzDHhr0PofG=KpjRVGee0J_j2LU+p4kt76rg@mail.gmail.com>
 <AM5PR83MB01638A81718CBB12CA0BCE45AD810@AM5PR83MB0163.EURPRD83.prod.outlook.com>
 <CAGK9nuqEyHcrt9YZoMg+kawhNJ8jH7YFRyf1cJDNYyVgaMYsLw@mail.gmail.com>
 <7EB6937A-086F-415C-81DC-C44BCA716DFB@cs.brynmawr.edu>
Message-ID: <AM5PR83MB0163EF00CF66AF6F8BC4B31BAD800@AM5PR83MB0163.EURPRD83.prod.outlook.com>

RULE. Braces used in type declarations affect only the types of terms declared within the declaration. The braces have no effect whatsoever on the kind of the type(s) declared

I’m not very comfortable with this.  The obvious alternative is to make them behave exactly the same.  Why did you discard that?

In any case this applies solely to H98 data type decls, and class decls.    For GADT-style decls we give a complete standalone type sig for the constructor.

In any case, I’ve lost track of the details here. Might you revise the proposal, incorporating

  *   some of the motivations articulated on this thread (eg by me 😊)
  *   some of the illustrative examples herein
  *   what is not covered [I think stuff to do with data type decls?]
Then we can take a fresh run at it.

Simon

From: Richard Eisenberg <rae at cs.brynmawr.edu>
Sent: 02 May 2018 03:06
To: Iavor Diatchki <iavor.diatchki at gmail.com>
Cc: Simon Peyton Jones <simonpj at microsoft.com>; ghc-steering-committee at haskell.org
Subject: Re: [ghc-steering-committee] Discussion on proposal #99: forall {k}

The proposal, as written, affects only type signatures and class declarations. It does not cover datatype declarations, though perhaps it should. This seems to be an oversight.

A key problem with this notation in type declarations is that H98-syntax datatype and class declarations do two things: they create a new type and they also inform the types of term-level definitions. In the case of a datatype, the terms are the constructors; in the case of a class, the terms are the methods.

Suppose we want to make term-level definitions suppress a certain variable but not to suppress this variable in the type definition? For example, perhaps we want data Proxy k (a :: k) = P, where Proxy :: forall k -> k -> Type, but P :: forall {k} (a :: k). Proxy k a. Note the different visibilities at the different levels.

We can boil it down to one rule for these situations:
 RULE. Braces used in type declarations affect only the types of terms declared within the declaration. The braces have no effect whatsoever on the kind of the type(s) declared.

With this in mind, I'll answer the questions below:

On May 1, 2018, at 12:56 PM, Iavor Diatchki <iavor.diatchki at gmail.com<mailto:iavor.diatchki at gmail.com>> wrote:

-- 1) The "normal" case.  I've written the types of the introduces names underneath, are they correct?
data T1 {k} (a :: k) = C1
-- T1 :: forall {k::Type}. k -> Type
-- C1 :: forall {k::Type} (a :: k). T1 {k} a

I would say we get

T1 :: forall (k :: Type) -> k -> Type    -- T1 has *2* visible arguments
C1 :: forall {k :: Type} (a :: k). T1 k a   -- C1 has one inferred and one specified type argument

-- Am I correct in assuming that while GHC could print the types like that, but users are not allowed to actually write those types (i.e., `T1 {k} (a::k)` is not a valid type).

GHC will print braces only around inferred-variable binding sites, not usage sites. If we wanted k not to be visible in the kind of T1, then one comment on the thread proposed

data T1' @k (a :: k) = C1'

which would yield

T1' :: forall (k :: Type). k -> Type
C1' :: forall (k :: Type) (a :: k). T1' a

I imagine we could combine the two, so that

data T1'' @{k} (a :: k) = C1''

would yield

T1'' :: forall (k :: Type). k -> Type
C1'' :: forall {k :: Type} (a :: k). T1'' a

Under this idea, there would be no way to get k to be *inferred* in the type's kind. A top-level kind signature (#54) would be necessary.

Note that the extensions discussed here, with @, are *not* part of this proposal, but might be a future one.



-- 2) Can GHC add extra inferred parameters? (This examples assumes `PolyKinds`)
data T2 {k} a = C2
-- C2 :: forall {k1::Type} {k::Type} (a :: k1). T2 {k1} {k} a   (ambiguous?)

I get

T2 :: forall {x :: Type} {y :: Type}. x -> y -> Type
C2 :: forall {x :: Type} {y :: Type} {k :: x} (a :: y). T2 k a

This is not an ambiguous type, because all the variables are determined by the (injective) result type.

So, in answer to your question: yes.



-- 3) Can we infer non-kind types?
data T3 {a} = C3 a
-- C3 :: forall {a::Type}. a -> T3 {a}

I get

T3 :: Type -> Type
C3 :: forall {a :: Type}. a -> T3 a

In answer to your question: yes.


-- 4) If `T3` is OK, how does "inferring" work in signatures? To make things concrete, would the following be accepted?
f :: T3
f = C3 True
-- A): not, because the signature is really: `forall {a}. T3 {a}`.
-- B): yes, because we are going to infer that the missing type is `Bool`, so the signature becomes `T3 {Bool}`.

C) not, because T3 still has a visible argument, and therefore T3 has kind `Type -> Type`, which is inappropriate for a type signature.



-- 5) The proposal has a class, something like this:
class C a {b} where
  meth1 :: a -> b

-- How do I write an instance for this class?
-- A)
instance C Int where
    meth1 x = x

-- B)
instance C Int {Int} where
    meth1 x = x

I imagine the answer is A) is I see nothing about writing types like `{Int}`.  If so, here are a couple of follow up questions about instances:


Neither. I would write

instance C Int Int where
  meth1 x = x

The braces in the type declaration affect only the term-level definitions therein, not the type definition, according to RULE.


-- Valid?
instance C Int where
    meth1 x = []
-- instance is really `forall {a::Type}. C Int {[a]}` ?

instance C Int where
    meth1 x = return x
--- error, instance is `C Int {m Int}`, but no `Monad` constraint.
-- There doesn't seem to be a way to write the instance with the constraint?

These are not valid.



Sorry for the long e-mail, but I hope that these examples might bring some clarity to users of the proposed feature.

These questions are really helpful in poking at the squishy spots! Thanks.

Richard



-Iavor



On Tue, May 1, 2018 at 3:55 AM Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:
[Redirecting to the steering committee]

I argue for acceptance.


  *   For me a compelling motivation is this: at the moment we can infer types and kinds that we cannot write down with an explicitly-quantified type signature.  That seems all wrong to me: we should be able to write down any type you can infer.
  *   The proposal adds notation.  It does not add semantics.  We already have the distinction between “inferred” and “specified” type variables.  You might not like it, but it’s there in GHC.

     *   If it wasn’t there already, I’d be happy to debate not adding it.
     *   If you want to argue for removing the distinction, that would certainly render the current proposal moot.  But that would take a GHC proposal – and there are good reasons for the status quo!
     *   What is bad is to maintain the semantic distinction, but be unable to express it.  That’s what we have right now, and it’s a bad thing.

What is the distinction between “specified” and “inferred”?

  *   Specified.   f :: forall a. blah, or   f :: a -> a.

You may give a visible type argument at a call of f, but you do not have to.  Thus  (f x) or (f @type x).



  *   Inferred.  f :: t a -> t a.  The type of f is really

g :: forall {k} (t :: k -> *) (a :: k). t a -> t a
Note that k does not appear at all in the signature; that’s why it is “inferred”.  In GHC today you cannot supply an explicit kind argument for g, but you can supply explicit argument for t and a.

So by all means make the case for abolishing the distinction, to render the present proposal moot.  But I think it’s unreasonably simply to reject on the grounds of “please think of something better”.

Simon

From: ghc-devs <ghc-devs-bounces at haskell.org<mailto:ghc-devs-bounces at haskell.org>> On Behalf Of Iavor Diatchki
Sent: 30 April 2018 17:12
To: ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
Subject: Discussion on proposal #99: forall {k}

Hello,

As a shepherd for proposal #99, I'd like to kick off the discussion.  The full proposal is available here: https://github.com/goldfirere/ghc-proposals/blob/explicit-specificity/proposals/0000-explicit-specificity.rst<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoldfirere%2Fghc-proposals%2Fblob%2Fexplicit-specificity%2Fproposals%2F0000-explicit-specificity.rst&data=02%7C01%7Csimonpj%40microsoft.com%7C91b5ba6ae508426a711b08d5afd13277%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636608235390001323&sdata=2tYpwTwlWtp73a1pkWEIhIOQFnWwLufJWSDKwRkqB8g%3D&reserved=0>

Summary: allows programmers to write `forall {x}` instead of `forall x` in type signatures.  The meaning of the braces is that this parameter cannot be instantiated with an explicit type application and will always be inferred.  The motivation is to shorten explicit type applications by skipping parameters that are known to be inferable, the common example being omitting the kinds in signatures with poly kinds.

As I understand it, the main motivation for this proposals is to give programmers more flexibility when instantiating type variables, with a less noisy syntax.   While the proposed solution might work in some situations, I am unconvinced that it is the best way to address the issue in general, for the following reasons:

  1. It requires that programmers commit at declaration time about which arguments will be inferred, and which may be inferred or specified.   While in some cases this may be an easy decision to make, in many cases this really is a decision which should be made at the use site of a function (e.g., I'd like to provide argument X, but would like GHC to infer argument Y).

  2. It still requires that programmers instantiate arguments in a fixed order,  which is sometimes dictated by the structure of the type itslef.  Here is, for example, what the proposal suggests to do if you want to provide type before a kind:

    typeRep4 :: forall {k} (a :: k) k'. (k ~ k', Typeable a) => TypeRep a

    While technically this is not wrong, it is not exactly elegant.

I think that we should reject this proposal, and try to come up with a more comprehensive solution to the problem.

One alternative design is to allow programmers to instantiate type variables by name.  This is much more flexible as it allows programmers to instantiate whichever variables they want, and in whatever order.  We've been doing this in Cryptol for a long time, and it seems to work really well.

-Iavor








_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

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

From mail at joachim-breitner.de  Wed May  2 13:48:38 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 02 May 2018 09:48:38 -0400
Subject: [ghc-steering-committee] Discussion on proposal #99: forall {k}
In-Reply-To: <7EB6937A-086F-415C-81DC-C44BCA716DFB@cs.brynmawr.edu>
References: <CAGK9nuqSLUuf6FuzDHhr0PofG=KpjRVGee0J_j2LU+p4kt76rg@mail.gmail.com>
 <AM5PR83MB01638A81718CBB12CA0BCE45AD810@AM5PR83MB0163.EURPRD83.prod.outlook.com>
 <CAGK9nuqEyHcrt9YZoMg+kawhNJ8jH7YFRyf1cJDNYyVgaMYsLw@mail.gmail.com>
 <7EB6937A-086F-415C-81DC-C44BCA716DFB@cs.brynmawr.edu>
Message-ID: <ad6d92eb536d12c18fc79bdf27a16ecfa6b3f115.camel@joachim-breitner.de>

Hi,

Am Dienstag, den 01.05.2018, 22:05 -0400 schrieb Richard Eisenberg:
> We can boil it down to one rule for these situations:
>  RULE. Braces used in type declarations affect only the types of
> terms declared within the declaration. The braces have no effect
> whatsoever on the kind of the type(s) declared.
> 
> With this in mind, I'll answer the questions below:
> 
> > On May 1, 2018, at 12:56 PM, Iavor Diatchki <iavor.diatchki at gmail.c
> > om> wrote:
> > 
> > -- 1) The "normal" case.  I've written the types of the introduces names underneath, are they correct?
> > data T1 {k} (a :: k) = C1
> > -- T1 :: forall {k::Type}. k -> Type
> > -- C1 :: forall {k::Type} (a :: k). T1 {k} a
> 
> I would say we get
> 
> T1 :: forall (k :: Type) -> k -> Type    -- T1 has *2* visible arguments
> C1 :: forall {k :: Type} (a :: k). T1 k a   -- C1 has one inferred and one specified type argument


I think this is highly confusing. The {k} is on T1, but it does not
affect T1, but rather something else?

What is wrong with “if you want to have different specificity on the
tycon and the datacon, use GADTSyntax”?

Cheers,
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/20180502/d8bfef42/attachment.sig>

From rae at cs.brynmawr.edu  Wed May  2 18:10:19 2018
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Wed, 2 May 2018 14:10:19 -0400
Subject: [ghc-steering-committee] Discussion on proposal #99: forall {k}
In-Reply-To: <ad6d92eb536d12c18fc79bdf27a16ecfa6b3f115.camel@joachim-breitner.de>
References: <CAGK9nuqSLUuf6FuzDHhr0PofG=KpjRVGee0J_j2LU+p4kt76rg@mail.gmail.com>
 <AM5PR83MB01638A81718CBB12CA0BCE45AD810@AM5PR83MB0163.EURPRD83.prod.outlook.com>
 <CAGK9nuqEyHcrt9YZoMg+kawhNJ8jH7YFRyf1cJDNYyVgaMYsLw@mail.gmail.com>
 <7EB6937A-086F-415C-81DC-C44BCA716DFB@cs.brynmawr.edu>
 <ad6d92eb536d12c18fc79bdf27a16ecfa6b3f115.camel@joachim-breitner.de>
Message-ID: <D79E106D-D788-4FEC-8388-A6EFDD6B7AF4@cs.brynmawr.edu>

OK -- I could agree with forbidding braces on `data` (given that the GADT-syntax alternative exists), but what about `class`? And then if we allow it on `class`, it seems a bit silly not to do the analogous thing on `data`. (Note that the proposal currently describes the same scheme as I have described in this email thread, but only about `class`.)

Richard

> On May 2, 2018, at 9:48 AM, Joachim Breitner <mail at joachim-breitner.de> wrote:
> 
> Hi,
> 
> Am Dienstag, den 01.05.2018, 22:05 -0400 schrieb Richard Eisenberg:
>> We can boil it down to one rule for these situations:
>> RULE. Braces used in type declarations affect only the types of
>> terms declared within the declaration. The braces have no effect
>> whatsoever on the kind of the type(s) declared.
>> 
>> With this in mind, I'll answer the questions below:
>> 
>>> On May 1, 2018, at 12:56 PM, Iavor Diatchki <iavor.diatchki at gmail.c
>>> om> wrote:
>>> 
>>> -- 1) The "normal" case.  I've written the types of the introduces names underneath, are they correct?
>>> data T1 {k} (a :: k) = C1
>>> -- T1 :: forall {k::Type}. k -> Type
>>> -- C1 :: forall {k::Type} (a :: k). T1 {k} a
>> 
>> I would say we get
>> 
>> T1 :: forall (k :: Type) -> k -> Type    -- T1 has *2* visible arguments
>> C1 :: forall {k :: Type} (a :: k). T1 k a   -- C1 has one inferred and one specified type argument
> 
> 
> I think this is highly confusing. The {k} is on T1, but it does not
> affect T1, but rather something else?
> 
> What is wrong with “if you want to have different specificity on the
> tycon and the datacon, use GADTSyntax”?
> 
> Cheers,
> Joachim
> -- 
> Joachim Breitner
>  mail at joachim-breitner.de
>  http://www.joachim-breitner.de/
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee


From mail at joachim-breitner.de  Wed May  2 18:51:25 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 02 May 2018 14:51:25 -0400
Subject: [ghc-steering-committee] Discussion on proposal #99: forall {k}
In-Reply-To: <D79E106D-D788-4FEC-8388-A6EFDD6B7AF4@cs.brynmawr.edu>
References: <CAGK9nuqSLUuf6FuzDHhr0PofG=KpjRVGee0J_j2LU+p4kt76rg@mail.gmail.com>
 <AM5PR83MB01638A81718CBB12CA0BCE45AD810@AM5PR83MB0163.EURPRD83.prod.outlook.com>
 <CAGK9nuqEyHcrt9YZoMg+kawhNJ8jH7YFRyf1cJDNYyVgaMYsLw@mail.gmail.com>
 <7EB6937A-086F-415C-81DC-C44BCA716DFB@cs.brynmawr.edu>
 <ad6d92eb536d12c18fc79bdf27a16ecfa6b3f115.camel@joachim-breitner.de>
 <D79E106D-D788-4FEC-8388-A6EFDD6B7AF4@cs.brynmawr.edu>
Message-ID: <41f153f3940391752bdddc40b07c54fdc23d6ee9.camel@joachim-breitner.de>

Hi,

Am Mittwoch, den 02.05.2018, 14:10 -0400 schrieb Richard Eisenberg:
> OK -- I could agree with forbidding braces on `data` (given that the
> GADT-syntax alternative exists), but what about `class`? And then if
> we allow it on `class`, it seems a bit silly not to do the analogous
> thing on `data`. (Note that the proposal currently describes the same
> scheme as I have described in this email thread, but only about
> `class`.)

Indeed, and the Unresolved questions go into some detail here.

It still is a bit weird to have `C {a}` affect _not_ C but _only_ the
methods, but since that is the only place where {a} appears, it is hard
to avoid.

Your solution for C is to say: Write a kind signature, i.e. if I write

   class C {k} (a : k) where meth :: a

and I want the {k} to be also inferred in C’s kind, I have to write

   type C :: forall {k}. k -> Constraint

By a similar reasoning one could expect the user, if they want to
change the specificity of meth, to write out the its full type
signature separately:

   class C k (a : k) where meth :: a
   meth :: forall {k} a. C k a -> k -> Constraint

This would even allow more fine-grained control: You get to choose for
each meth what the specificity is.


In a way, that is similar to Coq’s [Arguments] command, which changes
specificity after-the-fact. And we already have something similar in
Haskell: role annotations. So maybe another alternative is to say

   class C k (a : k) where meth :: a
   specificity meth inferred specified


(The rambliness of this mail is an indication that the proposal does
not immediately resonates as the obvious right and best solution with
me…)

Cheers,
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/20180502/dc7ecbbf/attachment.sig>

From rae at cs.brynmawr.edu  Wed May  2 20:10:39 2018
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Wed, 2 May 2018 16:10:39 -0400
Subject: [ghc-steering-committee] Discussion on proposal #99: forall {k}
In-Reply-To: <41f153f3940391752bdddc40b07c54fdc23d6ee9.camel@joachim-breitner.de>
References: <CAGK9nuqSLUuf6FuzDHhr0PofG=KpjRVGee0J_j2LU+p4kt76rg@mail.gmail.com>
 <AM5PR83MB01638A81718CBB12CA0BCE45AD810@AM5PR83MB0163.EURPRD83.prod.outlook.com>
 <CAGK9nuqEyHcrt9YZoMg+kawhNJ8jH7YFRyf1cJDNYyVgaMYsLw@mail.gmail.com>
 <7EB6937A-086F-415C-81DC-C44BCA716DFB@cs.brynmawr.edu>
 <ad6d92eb536d12c18fc79bdf27a16ecfa6b3f115.camel@joachim-breitner.de>
 <D79E106D-D788-4FEC-8388-A6EFDD6B7AF4@cs.brynmawr.edu>
 <41f153f3940391752bdddc40b07c54fdc23d6ee9.camel@joachim-breitner.de>
Message-ID: <0BCE745C-7B82-4F25-9F86-3858398EA3C3@cs.brynmawr.edu>

Joachim, you are always a fount of interesting ideas.

> On May 2, 2018, at 2:51 PM, Joachim Breitner <mail at joachim-breitner.de> wrote:
> 
>   class C k (a : k) where meth :: a
>   meth :: forall {k} a. C k a -> k -> Constraint

I think this is brilliant. But not only for this proposal! Imagine this:

class Num a where
  fromInteger :: Integer -> a

fromInteger :: Integer -> forall a. Num a => a

If we do that, then #129 is essentially solved, at no further cost to anyone. (Note that in all Haskell98-style code, no one will ever be able to notice the changed type of fromInteger.)

This approach also allows for the possibility of reordering quantified type variables for Haskell98-style constructors, if anyone should want to do it.

And it allows for updated types (including quantified variable ordering, etc.) for record selectors.

And it allows (maybe?) for giving good types to GADT record selectors:

data X a where
  Foo :: { bar :: Int } -> X Int
  Quux :: { bar :: Bool } -> X Bool
bar :: X a -> a

GHC currently rejects the declaration for X, but it could be accepted if only we could specify the correct type of bar. And now we can. I don't particularly want to cook up the typing rules here, but I don't think I'm totally crazy.

GADT record selectors aside, the rule for these could be that the top-level type signature must be equivalent w.r.t. the subtype relation with the original type signature. That is, if the new signature is t1 and the old was t2, then t1 <: t2 and t2 <: t1. Easy enough to check for. The implementation would probably do a little worker/wrapper stunt.

>   class C k (a : k) where meth :: a
>   specificity meth inferred specified

This is also quite interesting. Syntax for role annotations started out very terse, and written inline with datatype declarations. Over time, we recognized that it was more ergonomic to separate them from the declarations. One reason for this was to ease the transition period and requisite CPP clutter.

I still prefer your first suggestion here more because it seems to have greater applicability.

> 
> 
> (The rambliness of this mail is an indication that the proposal does
> not immediately resonates as the obvious right and best solution with
> me…)

I agree, and so I'm pleased with this debate.

Richard

> 
> Cheers,
> Joachim
> -- 
> Joachim Breitner
>  mail at joachim-breitner.de
>  http://www.joachim-breitner.de/
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee


From marlowsd at gmail.com  Thu May  3 09:38:38 2018
From: marlowsd at gmail.com (Simon Marlow)
Date: Thu, 3 May 2018 10:38:38 +0100
Subject: [ghc-steering-committee] Extra Commas (#87), Recommend: accept
In-Reply-To: <c07a4db8535287683f9de45307a62b58c6c3fce1.camel@joachim-breitner.de>
References: <CADnndOpYDrL-BVn69seXAya0cSwm9N=xqLnsDKHTyoD5MGzAVA@mail.gmail.com>
 <c07a4db8535287683f9de45307a62b58c6c3fce1.camel@joachim-breitner.de>
Message-ID: <CANsrgPJG9XZygba1Tmg3+1mSs6Ok=ND+VkPLvRXrc3JEZpD7+w@mail.gmail.com>

I support both adding ExtraCommas (minus constraint tuples) and Joachim's
suggestion to modify the warning for duplicate exports.  Both  of these are
useful.

The "cleaner diffs" motivation is more compelling than the CPP argument, in
my opinion. I often have to work with Python where it's common practice to
include trailing commas in multiline lists, and I miss it in Haskell.

Cheers
Simon

On 1 May 2018 at 03:59, Joachim Breitner <mail at joachim-breitner.de> wrote:

> Hi,
>
>
> Am Montag, den 30.04.2018, 19:20 -0500 schrieb Christopher Allen:
> > https://github.com/ghc-proposals/ghc-proposals/pull/87
> >
> > With the provisos mentioned by Simon starting here in mind:
> > https://github.com/ghc-proposals/ghc-proposals/pull/
> 87#issuecomment-385536587
>
> I am not against the proposal, but in the interest of fighting
> extension fatigue I’d like to draw your attention to this (which I had
> just posted at https://github.com/ghc-proposals/ghc-proposals/pull/
> 87#issuecomment-385581915)
>
>
> If the motivation is really mainly about subexports lists, then we
> could simply tell GHC to accept
>
>    module Foo
>        (
>        Foo(A),
>        Foo(B),
>        )
>    where
>
> without warning about the duplicate export of `Foo`.
>
>
> Is this good enough to solve the subexport list problem for CPP users?
> (probably yes)
>
> Do we still want ExtraCommas, because it is also useful in lists and
> other syntactic constructs?
> (probably probably; I could be swayed either way).
>
>
> Cheers,
> Joachim
>
> --
> Joachim Breitner
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20180503/1b9e1df3/attachment.html>

From iavor.diatchki at gmail.com  Thu May  3 17:14:26 2018
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Thu, 03 May 2018 17:14:26 +0000
Subject: [ghc-steering-committee] Extra Commas (#87), Recommend: accept
In-Reply-To: <CANsrgPJG9XZygba1Tmg3+1mSs6Ok=ND+VkPLvRXrc3JEZpD7+w@mail.gmail.com>
References: <CADnndOpYDrL-BVn69seXAya0cSwm9N=xqLnsDKHTyoD5MGzAVA@mail.gmail.com>
 <c07a4db8535287683f9de45307a62b58c6c3fce1.camel@joachim-breitner.de>
 <CANsrgPJG9XZygba1Tmg3+1mSs6Ok=ND+VkPLvRXrc3JEZpD7+w@mail.gmail.com>
Message-ID: <CAGK9nuo8yx_qcNwJb89Uz38HWC6-_qTuLheK9RZFFY3+FODMXw@mail.gmail.com>

I don't like this proposal.  I guess it is mostly a matter of taste, but I
think that comas should be used a separator and not a terminator.   I don't
really buy either the CPP or "cleaner diffs" motivation.

Joachim's proposal about the export warnings does make sense though.

Cheers,
-Iavor



On Thu, May 3, 2018 at 2:38 AM Simon Marlow <marlowsd at gmail.com> wrote:

> I support both adding ExtraCommas (minus constraint tuples) and Joachim's
> suggestion to modify the warning for duplicate exports.  Both  of these are
> useful.
>
> The "cleaner diffs" motivation is more compelling than the CPP argument,
> in my opinion. I often have to work with Python where it's common practice
> to include trailing commas in multiline lists, and I miss it in Haskell.
>
> Cheers
> Simon
>
> On 1 May 2018 at 03:59, Joachim Breitner <mail at joachim-breitner.de> wrote:
>
>> Hi,
>>
>>
>> Am Montag, den 30.04.2018, 19:20 -0500 schrieb Christopher Allen:
>> > https://github.com/ghc-proposals/ghc-proposals/pull/87
>> >
>> > With the provisos mentioned by Simon starting here in mind:
>> >
>> https://github.com/ghc-proposals/ghc-proposals/pull/87#issuecomment-385536587
>>
>> I am not against the proposal, but in the interest of fighting
>> extension fatigue I’d like to draw your attention to this (which I had
>> just posted at
>> https://github.com/ghc-proposals/ghc-proposals/pull/87#issuecomment-385581915
>> )
>>
>>
>> If the motivation is really mainly about subexports lists, then we
>> could simply tell GHC to accept
>>
>>    module Foo
>>        (
>>        Foo(A),
>>        Foo(B),
>>        )
>>    where
>>
>> without warning about the duplicate export of `Foo`.
>>
>>
>> Is this good enough to solve the subexport list problem for CPP users?
>> (probably yes)
>>
>> Do we still want ExtraCommas, because it is also useful in lists and
>> other syntactic constructs?
>> (probably probably; I could be swayed either way).
>>
>>
>> Cheers,
>> Joachim
>>
>> --
>> Joachim Breitner
>>   mail at joachim-breitner.de
>>   http://www.joachim-breitner.de/
>>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
>>
> _______________________________________________
> 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/20180503/f335972b/attachment.html>

From marlowsd at gmail.com  Fri May  4 19:42:53 2018
From: marlowsd at gmail.com (Simon Marlow)
Date: Fri, 4 May 2018 20:42:53 +0100
Subject: [ghc-steering-committee] Resurrect Pattern Signatures (#119),
 Recommendation: accept
In-Reply-To: <CADnndOp6Rx0DLXwQV-6pRY8m63Qg1rPP+9jr2m3_Zej73x4Knw@mail.gmail.com>
References: <CADnndOp6Rx0DLXwQV-6pRY8m63Qg1rPP+9jr2m3_Zej73x4Knw@mail.gmail.com>
Message-ID: <CANsrgPJLdCP8sCJ+TKiykg=kZ85C733H9HMPdViixG0GHZu13Q@mail.gmail.com>

I'm slightly against this proposal.  I think the reasons you gave *are*
sufficient to reject it, moreover there's the additional overhead of
another extension - complexity in the compiler, and cognitive overhead for
programmers. Extensions aren't cheap, or at least they're not cheap enough
to justify making extensions for subsets of existing extensions to cover
narrow use cases like this.

Yes ScopedTypeVariables might break some code if you enable it, but I think
we should all just enable it everywhere and move on. That leaves the cases
where you might be working in some legacy codebase where you want to make a
small change and are tempted to enable PatternSignatures because
ScopedTypeVariables breaks the code somewhere else - just do without it, or
enable ScopedTypeVariables and fix the breakage. I am not sympathetic to
your plight :)

Cheers
Simon

On 1 May 2018 at 01:13, Christopher Allen <cma at bitemyapp.com> wrote:

> This proposal splits out the faculty for assigning type signatures to
> variables destructured out of a pattern from ScopedTypeVariables.
>
> https://github.com/ghc-proposals/ghc-proposals/pull/119/
>
> My recommendation is to accept the proposal, with some reservations.
>
> ScopedTypeVariables is one of the more popular candidates for "this
> should always be on regardless." The cases in which STV would be
> useful greatly outnumber the downsides Gundry cited in my experience.
> My impression of this upheld by my industrial experience and that of
> the other industrial programmers I've talked to in the past about
> ScopedTypeVariables. Almost any time it is brought up almost
> invariably the conversation touches on, "why isn't this on by
> default?"
>
> I understand STV could break programs with overlapping names that are
> intended to be independent type variables, I don't presume to litigate
> or resolve that issue here.
>
> Extension fatigue is wearing on the Haskell users I regularly interact
> with, especially as it's unclear if Haskell Prime will convene and
> consolidate commonly used extensions into the core language.
>
> In my view these aren't sufficient reason to reject the proposed
> extension on the merits so my recommendation is to accept it as-is. I
> think the case for this proposal is particularly strong as it would
> clean up the extension's presently somewhat confusing relationship
> with STV.
>
> If no objections are raised, it should be assumed that this has the
> assent of the committee.
>
> --
> Chris Allen
> _______________________________________________
> 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/20180504/b11a9e92/attachment.html>

From cma at bitemyapp.com  Fri May  4 22:01:36 2018
From: cma at bitemyapp.com (Christopher Allen)
Date: Fri, 4 May 2018 17:01:36 -0500
Subject: [ghc-steering-committee] Resurrect Pattern Signatures (#119),
 Recommendation: accept
In-Reply-To: <CANsrgPJLdCP8sCJ+TKiykg=kZ85C733H9HMPdViixG0GHZu13Q@mail.gmail.com>
References: <CADnndOp6Rx0DLXwQV-6pRY8m63Qg1rPP+9jr2m3_Zej73x4Knw@mail.gmail.com>
 <CANsrgPJLdCP8sCJ+TKiykg=kZ85C733H9HMPdViixG0GHZu13Q@mail.gmail.com>
Message-ID: <CADnndOpsAJv_=vinWSvKwkBTGg3oPJ-U543pD2QSFYM7miguAw@mail.gmail.com>

I'd be happy rejecting this. I didn't expect much support or sympathy
for the ScopedTypeVariables users or for the on-going problem of
extension sprawl.

On Fri, May 4, 2018 at 2:42 PM, Simon Marlow <marlowsd at gmail.com> wrote:
> I'm slightly against this proposal.  I think the reasons you gave *are*
> sufficient to reject it, moreover there's the additional overhead of another
> extension - complexity in the compiler, and cognitive overhead for
> programmers. Extensions aren't cheap, or at least they're not cheap enough
> to justify making extensions for subsets of existing extensions to cover
> narrow use cases like this.
>
> Yes ScopedTypeVariables might break some code if you enable it, but I think
> we should all just enable it everywhere and move on. That leaves the cases
> where you might be working in some legacy codebase where you want to make a
> small change and are tempted to enable PatternSignatures because
> ScopedTypeVariables breaks the code somewhere else - just do without it, or
> enable ScopedTypeVariables and fix the breakage. I am not sympathetic to
> your plight :)
>
> Cheers
> Simon
>
> On 1 May 2018 at 01:13, Christopher Allen <cma at bitemyapp.com> wrote:
>>
>> This proposal splits out the faculty for assigning type signatures to
>> variables destructured out of a pattern from ScopedTypeVariables.
>>
>> https://github.com/ghc-proposals/ghc-proposals/pull/119/
>>
>> My recommendation is to accept the proposal, with some reservations.
>>
>> ScopedTypeVariables is one of the more popular candidates for "this
>> should always be on regardless." The cases in which STV would be
>> useful greatly outnumber the downsides Gundry cited in my experience.
>> My impression of this upheld by my industrial experience and that of
>> the other industrial programmers I've talked to in the past about
>> ScopedTypeVariables. Almost any time it is brought up almost
>> invariably the conversation touches on, "why isn't this on by
>> default?"
>>
>> I understand STV could break programs with overlapping names that are
>> intended to be independent type variables, I don't presume to litigate
>> or resolve that issue here.
>>
>> Extension fatigue is wearing on the Haskell users I regularly interact
>> with, especially as it's unclear if Haskell Prime will convene and
>> consolidate commonly used extensions into the core language.
>>
>> In my view these aren't sufficient reason to reject the proposed
>> extension on the merits so my recommendation is to accept it as-is. I
>> think the case for this proposal is particularly strong as it would
>> clean up the extension's presently somewhat confusing relationship
>> with STV.
>>
>> If no objections are raised, it should be assumed that this has the
>> assent of the committee.
>>
>> --
>> Chris Allen
>> _______________________________________________
>> 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 cma at bitemyapp.com  Sat May  5 01:14:12 2018
From: cma at bitemyapp.com (Christopher Allen)
Date: Fri, 4 May 2018 20:14:12 -0500
Subject: [ghc-steering-committee] Resurrect Pattern Signatures (#119),
 Recommendation: accept
In-Reply-To: <CANsrgPJLdCP8sCJ+TKiykg=kZ85C733H9HMPdViixG0GHZu13Q@mail.gmail.com>
References: <CADnndOp6Rx0DLXwQV-6pRY8m63Qg1rPP+9jr2m3_Zej73x4Knw@mail.gmail.com>
 <CANsrgPJLdCP8sCJ+TKiykg=kZ85C733H9HMPdViixG0GHZu13Q@mail.gmail.com>
Message-ID: <CADnndOpCunyKH5+ORo4tyBSO4_mrbiYQnbkYO0ocO=qdo=AnXw@mail.gmail.com>

Sidebar: scoped type variables is the default in Rust as far as I know.

This post demonstrates something that wouldn't work were that not the
case: https://matklad.github.io/2018/05/04/encapsulating-lifetime-of-the-field.html

They need scoped polymorphic type variables not only for ordinary type
variables, but also for polymorphic lifetimes.

On Fri, May 4, 2018 at 2:42 PM, Simon Marlow <marlowsd at gmail.com> wrote:
> I'm slightly against this proposal.  I think the reasons you gave *are*
> sufficient to reject it, moreover there's the additional overhead of another
> extension - complexity in the compiler, and cognitive overhead for
> programmers. Extensions aren't cheap, or at least they're not cheap enough
> to justify making extensions for subsets of existing extensions to cover
> narrow use cases like this.
>
> Yes ScopedTypeVariables might break some code if you enable it, but I think
> we should all just enable it everywhere and move on. That leaves the cases
> where you might be working in some legacy codebase where you want to make a
> small change and are tempted to enable PatternSignatures because
> ScopedTypeVariables breaks the code somewhere else - just do without it, or
> enable ScopedTypeVariables and fix the breakage. I am not sympathetic to
> your plight :)
>
> Cheers
> Simon
>
> On 1 May 2018 at 01:13, Christopher Allen <cma at bitemyapp.com> wrote:
>>
>> This proposal splits out the faculty for assigning type signatures to
>> variables destructured out of a pattern from ScopedTypeVariables.
>>
>> https://github.com/ghc-proposals/ghc-proposals/pull/119/
>>
>> My recommendation is to accept the proposal, with some reservations.
>>
>> ScopedTypeVariables is one of the more popular candidates for "this
>> should always be on regardless." The cases in which STV would be
>> useful greatly outnumber the downsides Gundry cited in my experience.
>> My impression of this upheld by my industrial experience and that of
>> the other industrial programmers I've talked to in the past about
>> ScopedTypeVariables. Almost any time it is brought up almost
>> invariably the conversation touches on, "why isn't this on by
>> default?"
>>
>> I understand STV could break programs with overlapping names that are
>> intended to be independent type variables, I don't presume to litigate
>> or resolve that issue here.
>>
>> Extension fatigue is wearing on the Haskell users I regularly interact
>> with, especially as it's unclear if Haskell Prime will convene and
>> consolidate commonly used extensions into the core language.
>>
>> In my view these aren't sufficient reason to reject the proposed
>> extension on the merits so my recommendation is to accept it as-is. I
>> think the case for this proposal is particularly strong as it would
>> clean up the extension's presently somewhat confusing relationship
>> with STV.
>>
>> If no objections are raised, it should be assumed that this has the
>> assent of the committee.
>>
>> --
>> Chris Allen
>> _______________________________________________
>> 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 chak at justtesting.org  Sat May  5 03:12:27 2018
From: chak at justtesting.org (Manuel M T Chakravarty)
Date: Sat, 5 May 2018 13:12:27 +1000
Subject: [ghc-steering-committee] Resurrect Pattern Signatures (#119),
 Recommendation: accept
In-Reply-To: <CANsrgPJLdCP8sCJ+TKiykg=kZ85C733H9HMPdViixG0GHZu13Q@mail.gmail.com>
References: <CADnndOp6Rx0DLXwQV-6pRY8m63Qg1rPP+9jr2m3_Zej73x4Knw@mail.gmail.com>
 <CANsrgPJLdCP8sCJ+TKiykg=kZ85C733H9HMPdViixG0GHZu13Q@mail.gmail.com>
Message-ID: <81D074D9-55B2-4C35-BF96-4D107052C973@justtesting.org>

I agree with Simon’s position.

Cheers,
Manuel

> Am 05.05.2018 um 05:42 schrieb Simon Marlow <marlowsd at gmail.com>:
> 
> I'm slightly against this proposal.  I think the reasons you gave *are* sufficient to reject it, moreover there's the additional overhead of another extension - complexity in the compiler, and cognitive overhead for programmers. Extensions aren't cheap, or at least they're not cheap enough to justify making extensions for subsets of existing extensions to cover narrow use cases like this.
> 
> Yes ScopedTypeVariables might break some code if you enable it, but I think we should all just enable it everywhere and move on. That leaves the cases where you might be working in some legacy codebase where you want to make a small change and are tempted to enable PatternSignatures because ScopedTypeVariables breaks the code somewhere else - just do without it, or enable ScopedTypeVariables and fix the breakage. I am not sympathetic to your plight :)
> 
> Cheers
> Simon
> 
> On 1 May 2018 at 01:13, Christopher Allen <cma at bitemyapp.com <mailto:cma at bitemyapp.com>> wrote:
> This proposal splits out the faculty for assigning type signatures to
> variables destructured out of a pattern from ScopedTypeVariables.
> 
> https://github.com/ghc-proposals/ghc-proposals/pull/119/ <https://github.com/ghc-proposals/ghc-proposals/pull/119/>
> 
> My recommendation is to accept the proposal, with some reservations.
> 
> ScopedTypeVariables is one of the more popular candidates for "this
> should always be on regardless." The cases in which STV would be
> useful greatly outnumber the downsides Gundry cited in my experience.
> My impression of this upheld by my industrial experience and that of
> the other industrial programmers I've talked to in the past about
> ScopedTypeVariables. Almost any time it is brought up almost
> invariably the conversation touches on, "why isn't this on by
> default?"
> 
> I understand STV could break programs with overlapping names that are
> intended to be independent type variables, I don't presume to litigate
> or resolve that issue here.
> 
> Extension fatigue is wearing on the Haskell users I regularly interact
> with, especially as it's unclear if Haskell Prime will convene and
> consolidate commonly used extensions into the core language.
> 
> In my view these aren't sufficient reason to reject the proposed
> extension on the merits so my recommendation is to accept it as-is. I
> think the case for this proposal is particularly strong as it would
> clean up the extension's presently somewhat confusing relationship
> with STV.
> 
> If no objections are raised, it should be assumed that this has the
> assent of the committee.
> 
> --
> Chris Allen
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> 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/20180505/2260ead5/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 874 bytes
Desc: Message signed with OpenPGP
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20180505/2260ead5/attachment-0001.sig>

From mail at joachim-breitner.de  Sat May  5 21:01:29 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sat, 05 May 2018 17:01:29 -0400
Subject: [ghc-steering-committee] Deriving via (#120),
 Recommendation: accept
In-Reply-To: <VI1PR83MB01741E31C164DC895C5D0DD3AD880@VI1PR83MB0174.EURPRD83.prod.outlook.com>
References: <b009873da7627da212ce0be8b4fe8f5eb2fdd504.camel@joachim-breitner.de>
 <VI1PR83MB01741E31C164DC895C5D0DD3AD880@VI1PR83MB0174.EURPRD83.prod.outlook.com>
Message-ID: <1120f3f6e9e401d18f1fe783df469bd50daa80ec.camel@joachim-breitner.de>

Hi,

there seems to be mainly consensus here.

Am Dienstag, den 24.04.2018, 20:41 +0000 schrieb Simon Peyton Jones:
> But I have added a comment to the main thread asking for some changes
> to the presentation.  And an open question about syntax.

The discussion there seems to have ebbed down. I am happy with the
syntax in the proposal (deriving via … instance …) and accept it as it
is.

Cheers,
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/20180505/7a478267/attachment.sig>

From mail at joachim-breitner.de  Sat May  5 21:06:11 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sat, 05 May 2018 17:06:11 -0400
Subject: [ghc-steering-committee] Please review: Mutable constructor
 fields, Shepherd: Ryan Newton
In-Reply-To: <CACYs5AbW2d7wuYQ5fEyH8Kdtxv3b4srPhn74e8MDQYpSC7=vtw@mail.gmail.com>
References: <1500034660.7133.5.camel@joachim-breitner.de>
 <CACYs5AbW2d7wuYQ5fEyH8Kdtxv3b4srPhn74e8MDQYpSC7=vtw@mail.gmail.com>
Message-ID: <ac1e19fab015bdb230a32a3b2901445c64277536.camel@joachim-breitner.de>

Dear Ryan,

what is the status of this proposal? It seems that it was not met with
enthusiasm, but also not with opposition? Shall I mark it as accept?

Cheers,
Joachim


Am Sonntag, den 11.02.2018, 00:43 -0500 schrieb Ryan Newton:
> Reboot!  This has long sat idle, but I propose to now formally start the committee discussion period: mandatory 4 weeks, closing at end of day March 10th, or earlier if consensus occurs.  Let's use this email thread for that discussion.  In this mail I summarize public discussion and argue for "accept".
> 
> In short, the proposal adds a way to have multiple mutable fields within a data-constructor, without the indirection of using IORef.  Second to "linear types", this proposal generated the most total comments during public discussion (107).  This level of discussion was good -- given that accepted GHC proposals so far are mostly syntactic (or API tweaks), this would be the first with major compiler backend & runtime consequences.  
> 
> Ed Kmett and Ryan Yates have demonstrated the applicability of this concept to data-structure implementation.  (Indeed, I think there's a good reason that almost all languages mutation with mutation are implemented so as to allow a single heap object to have multiple mutable fields within it.) During the public discussion, questions were raised about interactions with other features and implementation strategy -- in particularly changes to core.  But I believe that all major concerns were eventually answered.
> 
>   -Ryan
> 
> P.S. Iavor, Trevor, and Ryan Yates were all working on implementation of this feature at various points.  Not sure what the current status of implementation efforts are.
> 
> 
> On Fri, Jul 14, 2017 at 8:17 AM, Joachim Breitner <mail at joachim-breitner.de> wrote:
> > Dear Committee,
> > 
> > this is your secretary speaking:
> > 
> > https://github.com/ghc-proposals/ghc-proposals/pull/8
> > was brought before the committee, by our own Simon Marlow.
> > 
> > I propose Ryan Newton as the Shepherd, because he asked for it :-)
> > 
> > Ryan, please reach consensus as described in
> > https://github.com/ghc-proposals/ghc-proposals#committee-process
> > 
> > I suggest you make a recommendation about the decision, maybe point out
> > debatable points, and assume that anyone who stays quiet agrees with
> > you.
> > 
> > 
> > Greetings,
> > Joachim
> > 
> > 
> > --
> > Joachim Breitner
> >   mail at joachim-breitner.de
> >   http://www.joachim-breitner.de/
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
-- 
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/20180505/092e98fe/attachment.sig>

From mail at joachim-breitner.de  Sat May  5 21:08:18 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sat, 05 May 2018 17:08:18 -0400
Subject: [ghc-steering-committee] Committee Discussion : Lazy unboxed
 tuples
In-Reply-To: <CACYs5AZuYERT0LkPDp=WLV8hXwwfe+9YnGJAL5p75+hbDWxVrg@mail.gmail.com>
References: <CACYs5AYSCHWs3LyLmm-UVzafrr=GtSEPeKJMhnz5RbMvvLpiCQ@mail.gmail.com>
 <8CA10C38-8087-4C59-AA48-E1C4AF34DE64@justtesting.org>
 <B6E2D595-576E-4884-9EDB-03685427512F@cs.brynmawr.edu>
 <B15A9F32-3B7B-4A1A-9689-01B3CF02F003@justtesting.org>
 <B57AEF0F-936C-4802-96C0-BB909A60A843@cs.brynmawr.edu>
 <CACYs5AZuYERT0LkPDp=WLV8hXwwfe+9YnGJAL5p75+hbDWxVrg@mail.gmail.com>
Message-ID: <d13a50896466854b33649a32d73b45a09f299b3e.camel@joachim-breitner.de>

Hi Ryan,

maybe this fell of your plate, but we should finish this almost year
old proposal.

I believe you have not actually made a recommendation yet. 

Cheers,
Joachim

Am Mittwoch, den 12.07.2017, 10:07 -0400 schrieb Ryan Newton:
> Dear committee,
> 
> Thanks Manuel, I will try to follow those points of process is the future.  On this proposal, I'll discuss further on the github thread and come back to the committee with a default recommendation in a bit.  
> 
> I think we may as well start the timer though -- say, finish with this proposal by August 8th.
> 
> Best,
>   -Ryan
> 
> erg <rae at cs.brynmawr.edu> wrote:
> > > On Jul 11, 2017, at 9:27 PM, Manuel M T Chakravarty <chak at justtesting.org> wrote:
> > > 
> > > We had that situation before with a proposal by Joachim. IIRC Joachim did respond to technical points in the discussion, but he did not participate in the discussion itself. I think, that is fine.
> > 
> > Thanks for jogging my memory. No one complained then, so I'll assume the same stance.
> > 
> > - On alternatives to the original proposal: Yes, the proposal is for Simon PJ's (1), but (2) is considered in the Alternatives section. It's my understanding that the committee can choose to accept a model put forth in the Alternatives section of a proposal (or make other changes). So, you can suppose that both (1) and (2) are being put forth for a decision.
> > 
> > - On Ryan's question about bangs on variables: yes, that's true that the lack of requirement for a bang on a bare variable of unlifted type is an exception to the rule. Note that this inconsistency affects only the warning that GHC might emit about an unlifted-variable binding, not the semantics of the match itself.
> > 
> > Richard
> > 
> > > Manuel
> > > 
> > > > Richard Eisenberg <rae at cs.brynmawr.edu>:
> > > > 
> > > > Point of process: is it allowed for me to participate in this thread? Most proposal authors would not have this privilege.
> > > > 
> > > > My own answer to that question is to generally allow committee members to participate in the discussion. The committee will know who the author is and that he is biased, and will take that bias into account when reading the author's comments. But I don't want to respond to the points below if that would seem like an insider's advantage.
> > > > 
> > > > So, what do we think about this point of process?
> > > > 
> > > > Thanks,
> > > > Richard
> > > > 
> > > > > On Jul 11, 2017, at 9:01 PM, Manuel M T Chakravarty <chak at justtesting.org> wrote:
> > > > > 
> > > > > Ryan,
> > > > > 
> > > > > I am generally in favour of this proposal — it appears to be a useful clean up.
> > > > > 
> > > > > However, I like to make two remarks on the process here — sorry if that appears nitpicky, but I think, it makes a difference.
> > > > > 
> > > > > (1) To keep the committee discussion smooth and quick, we did agree that the committee discussion is only on the proposal document. If any public discussion is relevant to the committee decision, it ought to be integrated into the proposal document (by the person who wrote the proposal) before the committee discussion. Specifically, I have no idea what you are talking about with Options (1) - (4) on that thread.
> > > > > 
> > > > > (2) The Shepherd ought to propose a decision in favour or against the proposal. This is the default decision if nobody on the committee disagrees. I think, this is a useful policy as it serves as a forcing function for the discussion. So, what is your default decision?
> > > > > 
> > > > > Manuel
> > > > > 
> > > > > > Ryan Newton <rrnewton at indiana.edu>:
> > > > > > 
> > > > > > Dear Committee,
> > > > > > 
> > > > > > The public discussion for this one has happened, now for 4 weeks of committee discussion and final accept/reject.
> > > > > > 
> > > > > > In that public discussion, you can see on Jan 11 options broken down as (1),(2),(3), with this proposal being (1).  This seems to have stopped in a weird place where there was some substantial argument for (2) and (3) in the latter half of the comments, but the proposal is for (1).
> > > > > > 
> > > > > > Richard, one bit that threw me off was this:
> > > > > > 
> > > > > > "we should require the bang even on bare variables, but that would break a lot of code I think."
> > > > > > 
> > > > > > Because that makes it seem like in spite of this cleaning-up proposal, GHC still has a basically inconsistent position on how to interpret variable-bindings of unlifted kind in patterns.
> > > > > > 
> > > > > > Discuss?
> > > > > > 
> > > > > >   -Ryan
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > On Tue, Jul 11, 2017 at 11:08 AM, Joachim Breitner <mail at joachim-breitner.de> wrote:
> > > > > > > Hi,
> > > > > > > 
> > > > > > > it is by Richard, I just got the URL wrong. The right pull request is
> > > > > > > https://github.com/ghc-proposals/ghc-proposals/pull/35
> > > > > > > sorry for that.
> > > > > > > 
> > > > > > > Using this thread is fine.
> > > > > > > 
> > > > > > > Joachim
> > > > > > > 
> > > > > > > Am Dienstag, den 11.07.2017, 10:58 -0400 schrieb Ryan Newton:
> > > > > > > > Just to clarify, this is proposed by a user "winterland".  I.e. not
> > > > > > > > Richard, right? In the process document it is the author that "brings
> > > > > > > > it before the committee" correct?
> > > > > > > >
> > > > > > > > I checked and it looks like our process document does not specify the
> > > > > > > > means of our committee discussion.  I propose we discuss this one
> > > > > > > > right here on this thread, which we've already got sitting in our
> > > > > > > > inboxes.
> > > > > > > >
> > > > > > > > Best,
> > > > > > > >   -Ryan
> > > > > > > >
> > > > > > > >
> > > > > > > > On Tue, Jul 11, 2017 at 2:58 AM, Joachim Breitner <mail at joachim-breit
> > > > > > > > ner.de> wrote:
> > > > > > > > > Dear Committee,
> > > > > > > > >
> > > > > > > > > this is your secretary speaking:
> > > > > > > > >
> > > > > > > > > https://github.com/ghc-proposals/ghc-proposals/pull/45
> > > > > > > > > was brought before the committee, by our own Richard.
> > > > > > > > >
> > > > > > > > > I propose Ryan Newton as the Shepherd, just to rotate this role
> > > > > > > > > properly.
> > > > > > > > >
> > > > > > > > > Ryan, please reach consensus as described in
> > > > > > > > > https://github.com/ghc-proposals/ghc-proposals#committee-process
> > > > > > > > >
> > > > > > > > > I suggest you make a recommendation about the decision, maybe point
> > > > > > > > > out
> > > > > > > > > debatable points, and assume that anyone who stays quiet agrees
> > > > > > > > > with
> > > > > > > > > you.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Greetings,
> > > > > > > > > Joachim
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Joachim Breitner
> > > > > > > > >   mail at joachim-breitner.de
> > > > > > > > >   http://www.joachim-breitner.de/
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > --
> > > > > > > Joachim “nomeata” Breitner
> > > > > > >   mail at joachim-breitner.de • https://www.joachim-breitner.de/
> > > > > > >   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
> > > > > > > 
> > > > > > 
> > > > > > _______________________________________________
> > > > > > ghc-steering-committee mailing list
> > > > > > ghc-steering-committee at haskell.org
> > > > > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> > > > 
> > > > _______________________________________________
> > > > ghc-steering-committee mailing list
> > > > ghc-steering-committee at haskell.org
> > > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> > 
> > 
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> > 
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
-- 
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/20180505/e051e228/attachment.sig>

From mail at joachim-breitner.de  Sat May  5 21:10:57 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sat, 05 May 2018 17:10:57 -0400
Subject: [ghc-steering-committee] Please Review: Top-level kind
 signatures, Shepherd: Roman Leshchinskiy
In-Reply-To: <c31107d1f8f1c73ace721564c84fe86907d4fd12.camel@joachim-breitner.de>
References: <c31107d1f8f1c73ace721564c84fe86907d4fd12.camel@joachim-breitner.de>
Message-ID: <592f9727dc42b71aaae45bf701911302f5c15098.camel@joachim-breitner.de>

Hi Roman,

just a reminder that there is a proposal waiting.

Cheers,
Joachim

Am Montag, den 16.04.2018, 10:39 -0700 schrieb Joachim Breitner:
> Dear Committee,
> 
> this is your secretary speaking:
> 
> Top-level kind signatures by Richard has been proposed:
> https://github.com/ghc-proposals/ghc-proposals/pull/54
> 
> I propose Roman Leshchinskiy as the shepherd, who is already
> shepherding the closely related proposal #81. 
> 
> Roman, please reach consensus as described in
> https://github.com/ghc-proposals/ghc-proposals#committee-process
> 
> I suggest you make a recommendation, in a new e-mail thread, about the
> decision, maybe point out debatable points, and assume that anyone who
> stays quiet agrees with you.
> 
> Thanks,
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/
-------------- 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/20180505/17bceb74/attachment.sig>

From mail at joachim-breitner.de  Sat May  5 21:12:33 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sat, 05 May 2018 17:12:33 -0400
Subject: [ghc-steering-committee] Proposal: Syntax for visible dependent
 quantification (#81)
In-Reply-To: <4704D092-353A-4113-9B2F-482FD3F7D1AF@cs.brynmawr.edu>
References: <CAADqg9bZktCwGik=4G9DJh0jb5VDPrWdSPE1U4_C4MXZoHmHbw@mail.gmail.com>
 <30B357D6-E03C-4A03-8D6C-F5BF22BF0E13@cs.brynmawr.edu>
 <88AAAB4F-4C45-43EF-B4A4-D095982FCBDF@cs.brynmawr.edu>
 <4704D092-353A-4113-9B2F-482FD3F7D1AF@cs.brynmawr.edu>
Message-ID: <52a0e1ee2494f5514ddda0984b31844dcf7b76a2.camel@joachim-breitner.de>

Hi,

indeed, we should make progress here. Roman, with #102 discussed
(albeit not decided), what is your recommendation about #81?

Cheers,
Joachim

Am Sonntag, den 15.04.2018, 23:09 -0400 schrieb Richard Eisenberg:
> Hi committee,
> 
> I'd like to reboot this discussion, now that #102 has been written, debated, and tabled. As a reminder, this proposal is blocking #54, which will cure real bugs GHC is plagued by.
> 
> Thanks!
> Richard
> 
> > On Jan 5, 2018, at 8:37 PM, Richard Eisenberg <rae at cs.brynmawr.edu> wrote:
> > 
> > OK. I've posted proposal #102 (https://github.com/goldfirere/ghc-proposals/blob/pi/proposals/0000-pi.rst) which describes the full set of quantifiers for Dependent Haskell.
> > 
> > I continue to think that #81 can stand alone, but those who want a larger picture can see #102 for that larger picture.
> > 
> > Thanks,
> > Richard
> > 
> > > On Dec 21, 2017, at 9:15 AM, Richard Eisenberg <rae at cs.brynmawr.edu> wrote:
> > > 
> > > These are good suggestions. Thanks. While I'm writing all these proposals, it's about time I introduce pi proper -- the proposal for pi can go further than reserve syntax, because there are already places in the language that support real pi-types (the kinds of type families [assuming #54 is accepted] and the kinds of datatypes).
> > > 
> > > I'll put together yet another proposal. :)
> > > 
> > > Regardless, I don't want to shut down debate on this proposal in isolation. In particular, I'd love new syntax suggestions, as I agree that the proposed syntax is a little subtle.
> > > 
> > > Thanks,
> > > Richard
> > > 
> > > > On Dec 20, 2017, at 3:35 PM, Roman Leshchinskiy <rleshchinskiy at gmail.com> wrote:
> > > > 
> > > > Hi everyone,
> > > > 
> > > > The proposal is about adding support for dependent quantification to
> > > > kind signatures:
> > > > 
> > > > https://github.com/ghc-proposals/ghc-proposals/pull/81
> > > > 
> > > > Consider the following declaration (example lifted from the proposal):
> > > > 
> > > > data T k (a :: k)
> > > > 
> > > > GHC accepts this but it can't be given an explicit kind. Internally,
> > > > it is assigned a kind which is rendered as
> > > > 
> > > > forall k -> k -> *
> > > > 
> > > > but this isn't accepted in source code. Note that in applications of
> > > > T, k must be specified explicitly (e.g., T Type Int) which is why T
> > > > does *not* have the kind
> > > > 
> > > > forall k. k -> *
> > > > 
> > > > Moreover, k is mentioned later in the kind which is why something like
> > > > Type -> k -> * doesn't work, either.
> > > > 
> > > > The proposal is to allow forall k -> k -> * and similar kinds to
> > > > appear in source code.
> > > > 
> > > > This is actually intended as the first in a series of proposals
> > > > driving us towards dependent types in Haskell as described in
> > > > Richard's thesis
> > > > (https://www.cis.upenn.edu/~sweirich/papers/eisenberg-thesis.pdf).
> > > > Ultimately, the intention is to have all of the following (cf. Chapter
> > > > 4 of the thesis):
> > > > 
> > > > forall a. t
> > > > forall a -> t
> > > > pi a. t
> > > > pi a -> t
> > > > 
> > > > Here, forall and pi express relevance (does it exist at runtime) and .
> > > > and -> express visibility (does it have to be specified explicitly).
> > > > 
> > > > Because of this, my recommendation is to strongly encourage the author
> > > > to submit an extended proposal which reserves (but doesn't specify the
> > > > semantics of) the above syntax wholesale.
> > > > 
> > > > This would allow us to ensure that various bits of Dependent Haskell
> > > > use consistent syntax and language extensions once implemented. I find
> > > > it quite difficult to discuss just this specific bit of syntax in
> > > > isolation. Indeed, the public discussion was rather confused without
> > > > an explanation of the roadmap
> > > > (https://github.com/ghc-proposals/ghc-proposals/pull/81#issuecomment-336892922).
> > > > 
> > > > Alternatively, we could just agree on the roadmap ourselves, without
> > > > public discussion. This would somewhat circumvent the process, though.
> > > > 
> > > > If we decide to discuss just the proposal as is, though, then I'd be
> > > > weakly against the proposed syntax as it is too subtle for my taste
> > > > and abuses familiar mathematical notation somewhat. I'd probably
> > > > prefer something like:
> > > > 
> > > > type a -> t
> > > > 
> > > > The proposal also doesn't specify what language extension would turn
> > > > on support for the syntax so this would have to be rectified.
> > > > 
> > > > Thanks,
> > > > 
> > > > Roman
> > > > _______________________________________________
> > > > ghc-steering-committee mailing list
> > > > ghc-steering-committee at haskell.org
> > > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> > > 
> > > _______________________________________________
> > > ghc-steering-committee mailing list
> > > ghc-steering-committee at haskell.org
> > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
-- 
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/20180505/00a40a88/attachment-0001.sig>

From mail at joachim-breitner.de  Sat May  5 21:13:57 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sat, 05 May 2018 17:13:57 -0400
Subject: [ghc-steering-committee] Treat kind and type vars identically
 with `forall` #103
In-Reply-To: <720B3F27-9A49-4F31-BE42-B35AD5A73531@cs.brynmawr.edu>
References: <AM5PR83MB016352A1E70E1B8F8B3DDE08ADA90@AM5PR83MB0163.EURPRD83.prod.outlook.com>
 <F75EF69C-8C57-4391-9315-40795483EA4A@cs.brynmawr.edu>
 <dc18ac6b5e75c2fe6de745159f719476b79ba0c4.camel@joachim-breitner.de>
 <720B3F27-9A49-4F31-BE42-B35AD5A73531@cs.brynmawr.edu>
Message-ID: <6b07f048d66cb3c7c8d11aa804b41ff79f06ba62.camel@joachim-breitner.de>

Hi,

Am Sonntag, den 15.04.2018, 23:11 -0400 schrieb Richard Eisenberg:
> On Apr 13, 2018, at 7:48 PM, Joachim Breitner <mail at joachim-breitner.de> wrote:
> > what does this mean for this proposal? Is there disagreement over
> > quickly the proposal will be implemented?
> 
> Yes, I believe there has been disagreement here, with Simon
> advocating for a sooner implementation, and Manuel and I arguing for
> a more delayed implementation (specifically, 2 releases after #83 is
> implemented).

can you work towards a consensus? Simon, since you are the Shepherd I’d
kindly ask you to drive this discussion.

Cheers,
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/20180505/aa2fabc4/attachment.sig>

From mail at joachim-breitner.de  Sat May  5 21:14:56 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sat, 05 May 2018 17:14:56 -0400
Subject: [ghc-steering-committee] Please Review: Kinds Without Promotion,
 Shepherd: Ryan Newton
In-Reply-To: <597ac8a627675358f27c8faafc96e5b4044078a5.camel@joachim-breitner.de>
References: <597ac8a627675358f27c8faafc96e5b4044078a5.camel@joachim-breitner.de>
Message-ID: <2c3c8fd11ae1c0e4c53f9a294dab6bf0b41b5bd0.camel@joachim-breitner.de>

Hi Ryan,

just a reminder that here is another proposal, and Iavor is surely
eager to learn about your recommendation.

Cheers,
Joachim

Am Dienstag, den 10.04.2018, 13:31 -0400 schrieb Joachim Breitner:
> Dear Committee,
> 
> this is your secretary speaking:
> 
> Kinds Without Promotion by Yavor
> https://github.com/ghc-proposals/ghc-proposals/pull/106
> 
> I propose Ryan Newton as the shepherd.
> 
> Ryan, please reach consensus as described in
> https://github.com/ghc-proposals/ghc-proposals#committee-process
> 
> I suggest you make a recommendation, in a new e-mail thread, about the
> decision, maybe point out debatable points, and assume that anyone who
> stays quiet agrees with you.
> 
> Thanks,
> Joachim
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/
-------------- 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/20180505/678bc176/attachment.sig>

From mail at joachim-breitner.de  Sun May  6 03:48:33 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sat, 05 May 2018 23:48:33 -0400
Subject: [ghc-steering-committee] Discussion on proposal #99: forall {k}
In-Reply-To: <0BCE745C-7B82-4F25-9F86-3858398EA3C3@cs.brynmawr.edu>
References: <CAGK9nuqSLUuf6FuzDHhr0PofG=KpjRVGee0J_j2LU+p4kt76rg@mail.gmail.com>
 <AM5PR83MB01638A81718CBB12CA0BCE45AD810@AM5PR83MB0163.EURPRD83.prod.outlook.com>
 <CAGK9nuqEyHcrt9YZoMg+kawhNJ8jH7YFRyf1cJDNYyVgaMYsLw@mail.gmail.com>
 <7EB6937A-086F-415C-81DC-C44BCA716DFB@cs.brynmawr.edu>
 <ad6d92eb536d12c18fc79bdf27a16ecfa6b3f115.camel@joachim-breitner.de>
 <D79E106D-D788-4FEC-8388-A6EFDD6B7AF4@cs.brynmawr.edu>
 <41f153f3940391752bdddc40b07c54fdc23d6ee9.camel@joachim-breitner.de>
 <0BCE745C-7B82-4F25-9F86-3858398EA3C3@cs.brynmawr.edu>
Message-ID: <12800fff0ea2e9fd819402bbaac2e31d7fbddf1d.camel@joachim-breitner.de>

Hi,

Am Mittwoch, den 02.05.2018, 16:10 -0400 schrieb Richard Eisenberg:
> Joachim, you are always a fount of interesting ideas.
> 
> > On May 2, 2018, at 2:51 PM, Joachim Breitner <mail at joachim-breitner
> > .de> wrote:
> > 
> >   class C k (a : k) where meth :: a
> >   meth :: forall {k} a. C k a -> k -> Constraint
> 
> I think this is brilliant. But not only for this proposal! Imagine
> this:
> 
> class Num a where
>   fromInteger :: Integer -> a
> 
> fromInteger :: Integer -> forall a. Num a => a
> 
> If we do that, then #129 is essentially solved, at no further cost to
> anyone. (Note that in all Haskell98-style code, no one will ever be
> able to notice the changed type of fromInteger.)
> 
> This approach also allows for the possibility of reordering
> quantified type variables for Haskell98-style constructors, if anyone
> should want to do it.
> 
> And it allows for updated types (including quantified variable
> ordering, etc.) for record selectors.
> 
> And it allows (maybe?) for giving good types to GADT record
> selectors:
> 
> data X a where
>   Foo :: { bar :: Int } -> X Int
>   Quux :: { bar :: Bool } -> X Bool
> bar :: X a -> a
> 
> GHC currently rejects the declaration for X, but it could be accepted
> if only we could specify the correct type of bar. And now we can. I
> don't particularly want to cook up the typing rules here, but I don't
> think I'm totally crazy.
> 
> GADT record selectors aside, the rule for these could be that the
> top-level type signature must be equivalent w.r.t. the subtype
> relation with the original type signature. That is, if the new
> signature is t1 and the old was t2, then t1 <: t2 and t2 <: t1. Easy
> enough to check for. The implementation would probably do a little
> worker/wrapper stunt.

I smell a new proposal… what does this mean for #99? Will you want to
revise it?

Cheers,
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/20180505/865c1056/attachment.sig>

From mail at joachim-breitner.de  Sun May  6 14:25:34 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sun, 06 May 2018 10:25:34 -0400
Subject: [ghc-steering-committee] TypeApplications for Overloaded Literals
 (#129), Recommendation: accept
Message-ID: <f14d2e97e2eaaac98a8dcaaa868db5176f1d6433.camel@joachim-breitner.de>

Dear Committee,

this is your secretary speaking:

Sandy Maguire proposes to change the desugaring of overloaded literals
so that they work nicely with type applications
https://github.com/ghc-proposals/ghc-proposals/pull/129
rendered at
https://github.com/isovector/ghc-proposals/blob/type-apps/proposals/0000-type-apply-literals.rst

I’ll shepherd that myself.

The proposal is a good example for a working proposal system here. The
original version of the proposal was rather complex, reshuffling type
arguments and stuff. But community input distilled this much smaller
change, which can be summarized: 

   Desugar `5` into `integerLit (5 :: Integer)` where

   integerLit :: Integer -> forall a. Num a => a
   integerLit = fromInteger

This allows `5 @Int` to work just fine.

The proposal does not require a language extension, and does not change
 what happens in the light of `RebindableSyntax`.

I therefore recommend that we accept this proposal.

Cheers,
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/20180506/ef2c30b5/attachment.sig>

From mail at joachim-breitner.de  Sun May  6 14:28:27 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sun, 06 May 2018 10:28:27 -0400
Subject: [ghc-steering-committee] Please Review: Type annotated quoters
 (#125), Shepherd: Simon Peyton Jones
Message-ID: <6652d90f8d991d1ff72031ba042bf7613e3a99ce.camel@joachim-breitner.de>

Dear Committee,

this is your secretary speaking:

Type annotated quoters have been proposed by Winterland
https://github.com/ghc-proposals/ghc-proposals/pull/125

I propose Simon Peyton Jones as the shepherd, as he has already looked at this.

Simon, please reach consensus as described in
https://github.com/ghc-proposals/ghc-proposals#committee-process
I suggest you make a recommendation, in a new e-mail thread with the
proposal number in the subject, about the decision, maybe point out
debatable points, and assume that anyone who stays quiet agrees with
you.

Thanks,
-- 
Joachim 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/20180506/a4d233a1/attachment.sig>

From iavor.diatchki at gmail.com  Sun May  6 15:42:19 2018
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Sun, 06 May 2018 15:42:19 +0000
Subject: [ghc-steering-committee] TypeApplications for Overloaded
 Literals (#129), Recommendation: accept
In-Reply-To: <f14d2e97e2eaaac98a8dcaaa868db5176f1d6433.camel@joachim-breitner.de>
References: <f14d2e97e2eaaac98a8dcaaa868db5176f1d6433.camel@joachim-breitner.de>
Message-ID: <CAGK9nuqsTCxpjHAT2UFxqaBn=oXDrVSa1NUT0uXCwbiO0yRM7A@mail.gmail.com>

Is there a reason why we should write `5 @Int` as opposed to `5 :: Int`?

Also, there appears to be a typo in the spec, the part which specifies
translations for integers (1 turned into 0?)

-Iavor

On Sun, May 6, 2018 at 7:25 AM Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Dear Committee,
>
> this is your secretary speaking:
>
> Sandy Maguire proposes to change the desugaring of overloaded literals
> so that they work nicely with type applications
> https://github.com/ghc-proposals/ghc-proposals/pull/129
> rendered at
>
> https://github.com/isovector/ghc-proposals/blob/type-apps/proposals/0000-type-apply-literals.rst
>
> I’ll shepherd that myself.
>
> The proposal is a good example for a working proposal system here. The
> original version of the proposal was rather complex, reshuffling type
> arguments and stuff. But community input distilled this much smaller
> change, which can be summarized:
>
>    Desugar `5` into `integerLit (5 :: Integer)` where
>
>    integerLit :: Integer -> forall a. Num a => a
>    integerLit = fromInteger
>
> This allows `5 @Int` to work just fine.
>
> The proposal does not require a language extension, and does not change
>  what happens in the light of `RebindableSyntax`.
>
> I therefore recommend that we accept this proposal.
>
> Cheers,
> Joachim
>
>
> --
> Joachim Breitner
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20180506/baaf7d80/attachment.html>

From mail at joachim-breitner.de  Sun May  6 15:47:22 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sun, 06 May 2018 11:47:22 -0400
Subject: [ghc-steering-committee] TypeApplications for Overloaded
 Literals (#129), Recommendation: accept
In-Reply-To: <CAGK9nuqsTCxpjHAT2UFxqaBn=oXDrVSa1NUT0uXCwbiO0yRM7A@mail.gmail.com>
References: <f14d2e97e2eaaac98a8dcaaa868db5176f1d6433.camel@joachim-breitner.de>
 <CAGK9nuqsTCxpjHAT2UFxqaBn=oXDrVSa1NUT0uXCwbiO0yRM7A@mail.gmail.com>
Message-ID: <9c8fd6398e89c1ea940a5e1fab666157a67c0e88.camel@joachim-breitner.de>

Hi,

Am Sonntag, den 06.05.2018, 15:42 +0000 schrieb Iavor Diatchki:
> Is there a reason why we should write `5 @Int` as opposed to `5 :: Int`?

Because we can. Or rather, we should can, because 

   Prelude> :t 5
   5 :: Num t => t
   Prelude> :t 5 @Double
   <interactive>:1:1: error:
       • Cannot apply expression of type ‘t0’
         to a visible type argument ‘Double’
       • In the expression: 5 @Double

is confusing and inconsistent with the user’s expectation after
learning about when they can use ExplicitTypeApplications (unless one
knows about the syntactic sugar involved.)

> Also, there appears to be a typo in the spec, the part which specifies translations for integers (1 turned into 0?)

thanks, fixed.


(BTW, all of you are owners of the repository and should have the
necessary permissions to edit pull requests directly.)

Cheers,
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/20180506/826ba6da/attachment.sig>

From iavor.diatchki at gmail.com  Sun May  6 16:27:07 2018
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Sun, 06 May 2018 16:27:07 +0000
Subject: [ghc-steering-committee] TypeApplications for Overloaded
 Literals (#129), Recommendation: accept
In-Reply-To: <9c8fd6398e89c1ea940a5e1fab666157a67c0e88.camel@joachim-breitner.de>
References: <f14d2e97e2eaaac98a8dcaaa868db5176f1d6433.camel@joachim-breitner.de>
 <CAGK9nuqsTCxpjHAT2UFxqaBn=oXDrVSa1NUT0uXCwbiO0yRM7A@mail.gmail.com>
 <9c8fd6398e89c1ea940a5e1fab666157a67c0e88.camel@joachim-breitner.de>
Message-ID: <CAGK9nuqiXWPFzh5LMCAwCn_kUw2766yX=w69V2MHYTJBsRqSWg@mail.gmail.com>

I am not convinced, if that's the sole motivation.  By that reasoning you
might expect that `(-5) @Int` or `(5+1) @Int` would also work, but they
wouldn't.



On Sun, May 6, 2018 at 8:47 AM Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Hi,
>
> Am Sonntag, den 06.05.2018, 15:42 +0000 schrieb Iavor Diatchki:
> > Is there a reason why we should write `5 @Int` as opposed to `5 :: Int`?
>
> Because we can. Or rather, we should can, because
>
>    Prelude> :t 5
>    5 :: Num t => t
>    Prelude> :t 5 @Double
>    <interactive>:1:1: error:
>        • Cannot apply expression of type ‘t0’
>          to a visible type argument ‘Double’
>        • In the expression: 5 @Double
>
> is confusing and inconsistent with the user’s expectation after
> learning about when they can use ExplicitTypeApplications (unless one
> knows about the syntactic sugar involved.)
>
> > Also, there appears to be a typo in the spec, the part which specifies
> translations for integers (1 turned into 0?)
>
> thanks, fixed.
>
>
> (BTW, all of you are owners of the repository and should have the
> necessary permissions to edit pull requests directly.)
>
> Cheers,
> Joachim
>
> --
> Joachim Breitner
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20180506/4823d555/attachment.html>

From rae at cs.brynmawr.edu  Sun May  6 19:26:53 2018
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Sun, 6 May 2018 15:26:53 -0400
Subject: [ghc-steering-committee] TypeApplications for Overloaded
 Literals (#129), Recommendation: accept
In-Reply-To: <CAGK9nuqiXWPFzh5LMCAwCn_kUw2766yX=w69V2MHYTJBsRqSWg@mail.gmail.com>
References: <f14d2e97e2eaaac98a8dcaaa868db5176f1d6433.camel@joachim-breitner.de>
 <CAGK9nuqsTCxpjHAT2UFxqaBn=oXDrVSa1NUT0uXCwbiO0yRM7A@mail.gmail.com>
 <9c8fd6398e89c1ea940a5e1fab666157a67c0e88.camel@joachim-breitner.de>
 <CAGK9nuqiXWPFzh5LMCAwCn_kUw2766yX=w69V2MHYTJBsRqSWg@mail.gmail.com>
Message-ID: <1089D9C9-303F-464C-8E1E-075FE569186F@cs.brynmawr.edu>

I'm also unconvinced about this proposal. It's hard to specify, requiring that Prelude.fromInteger be magical. Note that if someone defined a separate Num class (under -XNoImplicitPrelude -XRebindableSyntax) that's fully equivalent to Prelude.Num, it wouldn't work. Also, Joachim's point about `:t 5` is a poor motivation: `:t` does not give you helpful information w.r.t. type applications. You need `:t +v`. With -fprint-explicit-foralls,

λ> :t +v 5
5 :: forall {p}. Num p => p

The appearance of the braces in the output means that 5 is not available for visible type application (the variable p is *inferred*). So if there's any unexpected behavior in the current implementation, that's due to ill-informed expectations, not misbehavior.

In the end, I would prefer to reject this proposal in favor of Joachim's casual proposal here: https://mail.haskell.org/pipermail/ghc-steering-committee/2018-May/000541.html (and expanded upon by my subsequent post).

Richard

> On May 6, 2018, at 12:27 PM, Iavor Diatchki <iavor.diatchki at gmail.com> wrote:
> 
> I am not convinced, if that's the sole motivation.  By that reasoning you might expect that `(-5) @Int` or `(5+1) @Int` would also work, but they wouldn't. 
> 
> 
> 
> On Sun, May 6, 2018 at 8:47 AM Joachim Breitner <mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>> wrote:
> Hi,
> 
> Am Sonntag, den 06.05.2018, 15:42 +0000 schrieb Iavor Diatchki:
> > Is there a reason why we should write `5 @Int` as opposed to `5 :: Int`?
> 
> Because we can. Or rather, we should can, because 
> 
>    Prelude> :t 5
>    5 :: Num t => t
>    Prelude> :t 5 @Double
>    <interactive>:1:1: error:
>        • Cannot apply expression of type ‘t0’
>          to a visible type argument ‘Double’
>        • In the expression: 5 @Double
> 
> is confusing and inconsistent with the user’s expectation after
> learning about when they can use ExplicitTypeApplications (unless one
> knows about the syntactic sugar involved.)
> 
> > Also, there appears to be a typo in the spec, the part which specifies translations for integers (1 turned into 0?)
> 
> thanks, fixed.
> 
> 
> (BTW, all of you are owners of the repository and should have the
> necessary permissions to edit pull requests directly.)
> 
> Cheers,
> Joachim
> 
> -- 
> Joachim Breitner
>   mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>
>   http://www.joachim-breitner.de/ <http://www.joachim-breitner.de/>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> 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/20180506/0d91cc0d/attachment-0001.html>

From simonpj at microsoft.com  Tue May  8 10:40:30 2018
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 8 May 2018 10:40:30 +0000
Subject: [ghc-steering-committee] TypeApplications for Overloaded
 Literals (#129), Recommendation: accept
In-Reply-To: <1089D9C9-303F-464C-8E1E-075FE569186F@cs.brynmawr.edu>
References: <f14d2e97e2eaaac98a8dcaaa868db5176f1d6433.camel@joachim-breitner.de>
 <CAGK9nuqsTCxpjHAT2UFxqaBn=oXDrVSa1NUT0uXCwbiO0yRM7A@mail.gmail.com>
 <9c8fd6398e89c1ea940a5e1fab666157a67c0e88.camel@joachim-breitner.de>
 <CAGK9nuqiXWPFzh5LMCAwCn_kUw2766yX=w69V2MHYTJBsRqSWg@mail.gmail.com>
 <1089D9C9-303F-464C-8E1E-075FE569186F@cs.brynmawr.edu>
Message-ID: <AM5PR83MB0163598FB966CCE33D7045E5AD9A0@AM5PR83MB0163.EURPRD83.prod.outlook.com>

I’m on the fence:

  *   Benefit: slight
  *   Cost: slight

But the spec is distressingly ad-hoc.  Magical behaviour if

  *   RebindableSyntax is no
  *   The ‘fromInteger’ in scope is not ‘Prelude.fromInteger’

So I lean to rejection.  Unless some stronger motivations emerge.

Simon

From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On Behalf Of Richard Eisenberg
Sent: 06 May 2018 20:27
To: Iavor Diatchki <iavor.diatchki at gmail.com>
Cc: ghc-steering-committee at haskell.org; Joachim Breitner <mail at joachim-breitner.de>
Subject: Re: [ghc-steering-committee] TypeApplications for Overloaded Literals (#129), Recommendation: accept

I'm also unconvinced about this proposal. It's hard to specify, requiring that Prelude.fromInteger be magical. Note that if someone defined a separate Num class (under -XNoImplicitPrelude -XRebindableSyntax) that's fully equivalent to Prelude.Num, it wouldn't work. Also, Joachim's point about `:t 5` is a poor motivation: `:t` does not give you helpful information w.r.t. type applications. You need `:t +v`. With -fprint-explicit-foralls,

λ> :t +v 5
5 :: forall {p}. Num p => p

The appearance of the braces in the output means that 5 is not available for visible type application (the variable p is *inferred*). So if there's any unexpected behavior in the current implementation, that's due to ill-informed expectations, not misbehavior.

In the end, I would prefer to reject this proposal in favor of Joachim's casual proposal here: https://mail.haskell.org/pipermail/ghc-steering-committee/2018-May/000541.html (and expanded upon by my subsequent post).

Richard


On May 6, 2018, at 12:27 PM, Iavor Diatchki <iavor.diatchki at gmail.com<mailto:iavor.diatchki at gmail.com>> wrote:

I am not convinced, if that's the sole motivation.  By that reasoning you might expect that `(-5) @Int` or `(5+1) @Int` would also work, but they wouldn't.



On Sun, May 6, 2018 at 8:47 AM Joachim Breitner <mail at joachim-breitner.de<mailto:mail at joachim-breitner.de>> wrote:
Hi,

Am Sonntag, den 06.05.2018, 15:42 +0000 schrieb Iavor Diatchki:
> Is there a reason why we should write `5 @Int` as opposed to `5 :: Int`?

Because we can. Or rather, we should can, because

   Prelude> :t 5
   5 :: Num t => t
   Prelude> :t 5 @Double
   <interactive>:1:1: error:
       • Cannot apply expression of type ‘t0’
         to a visible type argument ‘Double’
       • In the expression: 5 @Double

is confusing and inconsistent with the user’s expectation after
learning about when they can use ExplicitTypeApplications (unless one
knows about the syntactic sugar involved.)

> Also, there appears to be a typo in the spec, the part which specifies translations for integers (1 turned into 0?)

thanks, fixed.


(BTW, all of you are owners of the repository and should have the
necessary permissions to edit pull requests directly.)

Cheers,
Joachim

--
Joachim Breitner
  mail at joachim-breitner.de<mailto:mail at joachim-breitner.de>
  http://www.joachim-breitner.de/
_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

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

From mail at joachim-breitner.de  Tue May  8 12:20:24 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 08 May 2018 08:20:24 -0400
Subject: [ghc-steering-committee] TypeApplications for Overloaded
	Literals (#129), Recommendation: reject
In-Reply-To: <AM5PR83MB0163598FB966CCE33D7045E5AD9A0@AM5PR83MB0163.EURPRD83.prod.outlook.com>
References: <f14d2e97e2eaaac98a8dcaaa868db5176f1d6433.camel@joachim-breitner.de>
 <CAGK9nuqsTCxpjHAT2UFxqaBn=oXDrVSa1NUT0uXCwbiO0yRM7A@mail.gmail.com>
 <9c8fd6398e89c1ea940a5e1fab666157a67c0e88.camel@joachim-breitner.de>
 <CAGK9nuqiXWPFzh5LMCAwCn_kUw2766yX=w69V2MHYTJBsRqSWg@mail.gmail.com>
 <1089D9C9-303F-464C-8E1E-075FE569186F@cs.brynmawr.edu>
 <AM5PR83MB0163598FB966CCE33D7045E5AD9A0@AM5PR83MB0163.EURPRD83.prod.outlook.com>
Message-ID: <C0FBF733-E547-487B-AC9D-6C68E9EA8C0A@joachim-breitner.de>

Hi,

it seems this proposal does not get much support. I kinda like the high-level goal, but not enough to defend it vehemently. I am changing my recommendation to reject, to facilitate consensus.

I should give those time to speak up who were in silent agreement with my initial recommendation, and if nothing happens, will reject this proposal in a week's time.


Cheers,
Joachim




Am 8. Mai 2018 06:40:30 GMT-04:00 schrieb Simon Peyton Jones <simonpj at microsoft.com>:
>I’m on the fence:
>
>  *   Benefit: slight
>  *   Cost: slight
>
>But the spec is distressingly ad-hoc.  Magical behaviour if
>
>  *   RebindableSyntax is no
>  *   The ‘fromInteger’ in scope is not ‘Prelude.fromInteger’
>
>So I lean to rejection.  Unless some stronger motivations emerge.
>
>Simon
>
>From: ghc-steering-committee
><ghc-steering-committee-bounces at haskell.org> On Behalf Of Richard
>Eisenberg
>Sent: 06 May 2018 20:27
>To: Iavor Diatchki <iavor.diatchki at gmail.com>
>Cc: ghc-steering-committee at haskell.org; Joachim Breitner
><mail at joachim-breitner.de>
>Subject: Re: [ghc-steering-committee] TypeApplications for Overloaded
>Literals (#129), Recommendation: accept
>
>I'm also unconvinced about this proposal. It's hard to specify,
>requiring that Prelude.fromInteger be magical. Note that if someone
>defined a separate Num class (under -XNoImplicitPrelude
>-XRebindableSyntax) that's fully equivalent to Prelude.Num, it wouldn't
>work. Also, Joachim's point about `:t 5` is a poor motivation: `:t`
>does not give you helpful information w.r.t. type applications. You
>need `:t +v`. With -fprint-explicit-foralls,
>
>λ> :t +v 5
>5 :: forall {p}. Num p => p
>
>The appearance of the braces in the output means that 5 is not
>available for visible type application (the variable p is *inferred*).
>So if there's any unexpected behavior in the current implementation,
>that's due to ill-informed expectations, not misbehavior.
>
>In the end, I would prefer to reject this proposal in favor of
>Joachim's casual proposal here:
>https://mail.haskell.org/pipermail/ghc-steering-committee/2018-May/000541.html
>(and expanded upon by my subsequent post).
>
>Richard
>
>
>On May 6, 2018, at 12:27 PM, Iavor Diatchki
><iavor.diatchki at gmail.com<mailto:iavor.diatchki at gmail.com>> wrote:
>
>I am not convinced, if that's the sole motivation.  By that reasoning
>you might expect that `(-5) @Int` or `(5+1) @Int` would also work, but
>they wouldn't.
>
>
>
>On Sun, May 6, 2018 at 8:47 AM Joachim Breitner
><mail at joachim-breitner.de<mailto:mail at joachim-breitner.de>> wrote:
>Hi,
>
>Am Sonntag, den 06.05.2018, 15:42 +0000 schrieb Iavor Diatchki:
>> Is there a reason why we should write `5 @Int` as opposed to `5 ::
>Int`?
>
>Because we can. Or rather, we should can, because
>
>   Prelude> :t 5
>   5 :: Num t => t
>   Prelude> :t 5 @Double
>   <interactive>:1:1: error:
>       • Cannot apply expression of type ‘t0’
>         to a visible type argument ‘Double’
>       • In the expression: 5 @Double
>
>is confusing and inconsistent with the user’s expectation after
>learning about when they can use ExplicitTypeApplications (unless one
>knows about the syntactic sugar involved.)
>
>> Also, there appears to be a typo in the spec, the part which
>specifies translations for integers (1 turned into 0?)
>
>thanks, fixed.
>
>
>(BTW, all of you are owners of the repository and should have the
>necessary permissions to edit pull requests directly.)
>
>Cheers,
>Joachim
>
>--
>Joachim Breitner
>  mail at joachim-breitner.de<mailto:mail at joachim-breitner.de>
>  http://www.joachim-breitner.de/
>_______________________________________________
>ghc-steering-committee mailing list
>ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
>https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>_______________________________________________
>ghc-steering-committee mailing list
>ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
>https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

From marlowsd at gmail.com  Tue May  8 13:47:27 2018
From: marlowsd at gmail.com (Simon Marlow)
Date: Tue, 8 May 2018 14:47:27 +0100
Subject: [ghc-steering-committee] TypeApplications for Overloaded
 Literals (#129), Recommendation: accept
In-Reply-To: <CAGK9nuqiXWPFzh5LMCAwCn_kUw2766yX=w69V2MHYTJBsRqSWg@mail.gmail.com>
References: <f14d2e97e2eaaac98a8dcaaa868db5176f1d6433.camel@joachim-breitner.de>
 <CAGK9nuqsTCxpjHAT2UFxqaBn=oXDrVSa1NUT0uXCwbiO0yRM7A@mail.gmail.com>
 <9c8fd6398e89c1ea940a5e1fab666157a67c0e88.camel@joachim-breitner.de>
 <CAGK9nuqiXWPFzh5LMCAwCn_kUw2766yX=w69V2MHYTJBsRqSWg@mail.gmail.com>
Message-ID: <CANsrgPLzM8SQ0HfUf+eAe2J6Vqfpk5CjhjteyEMNUw1uaEeqjQ@mail.gmail.com>

On 6 May 2018 at 17:27, Iavor Diatchki <iavor.diatchki at gmail.com> wrote:

> I am not convinced, if that's the sole motivation.  By that reasoning you
> might expect that `(-5) @Int` or `(5+1) @Int` would also work, but they
> wouldn't.
>

I was about to make the same argument, but then I realised that there's a
counter argument - the user's intuition about TypeApplications is likely to
start with something like "look at the type of the function in the left
corner of this application". In the case of (-5), which is actually `negate
5`, the identifier is `negate`, and we've already lost the ability to use a
type application when we applied it to 5.  This is no different from
something like `read "3" @Int` which also doesn't work.

The problem with bare literals is that we can't see the function in the
corner, and the user will tend to think of the literal itself as the
function, so I think the confusion that Joachim mentions is real.

That said, I have no strong opinions here and I haven't read the forall {k}
proposal yet.

Cheers
Simon


>
>
> On Sun, May 6, 2018 at 8:47 AM Joachim Breitner <mail at joachim-breitner.de>
> wrote:
>
>> Hi,
>>
>> Am Sonntag, den 06.05.2018, 15:42 +0000 schrieb Iavor Diatchki:
>> > Is there a reason why we should write `5 @Int` as opposed to `5 :: Int`?
>>
>> Because we can. Or rather, we should can, because
>>
>>    Prelude> :t 5
>>    5 :: Num t => t
>>    Prelude> :t 5 @Double
>>    <interactive>:1:1: error:
>>        • Cannot apply expression of type ‘t0’
>>          to a visible type argument ‘Double’
>>        • In the expression: 5 @Double
>>
>> is confusing and inconsistent with the user’s expectation after
>> learning about when they can use ExplicitTypeApplications (unless one
>> knows about the syntactic sugar involved.)
>>
>> > Also, there appears to be a typo in the spec, the part which specifies
>> translations for integers (1 turned into 0?)
>>
>> thanks, fixed.
>>
>>
>> (BTW, all of you are owners of the repository and should have the
>> necessary permissions to edit pull requests directly.)
>>
>> Cheers,
>> Joachim
>>
>> --
>> Joachim Breitner
>>   mail at joachim-breitner.de
>>   http://www.joachim-breitner.de/
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
>
> _______________________________________________
> 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/20180508/13f22caa/attachment.html>

From marlowsd at gmail.com  Tue May  8 14:27:09 2018
From: marlowsd at gmail.com (Simon Marlow)
Date: Tue, 8 May 2018 15:27:09 +0100
Subject: [ghc-steering-committee] Please review: Mutable constructor
 fields, Shepherd: Ryan Newton
In-Reply-To: <ac1e19fab015bdb230a32a3b2901445c64277536.camel@joachim-breitner.de>
References: <1500034660.7133.5.camel@joachim-breitner.de>
 <CACYs5AbW2d7wuYQ5fEyH8Kdtxv3b4srPhn74e8MDQYpSC7=vtw@mail.gmail.com>
 <ac1e19fab015bdb230a32a3b2901445c64277536.camel@joachim-breitner.de>
Message-ID: <CANsrgP+hK9wHYxiCeVy5HT84aQ6YiwEmcbo6zed4kWAka7PviQ@mail.gmail.com>

I think the conclusion of the last round of discussion was to go ahead with
the implementation and use experience with that to understand the impact on
GHC and to refine the proposal.  We'll be in good shape if we can
demonstrate that mutable fields aren't too intrusive, and it'll need a
prototype implementation to be able to establish that.

The status of the proposal isn't blocking the implementation, I think the
limiting factor is cycles to work on it, that's all. I'm not sure what the
correct state to put the proposal in at this stage is - dormant perhaps?

Cheers
Simon

On 5 May 2018 at 22:06, Joachim Breitner <mail at joachim-breitner.de> wrote:

> Dear Ryan,
>
> what is the status of this proposal? It seems that it was not met with
> enthusiasm, but also not with opposition? Shall I mark it as accept?
>
> Cheers,
> Joachim
>
>
> Am Sonntag, den 11.02.2018, 00:43 -0500 schrieb Ryan Newton:
> > Reboot!  This has long sat idle, but I propose to now formally start the
> committee discussion period: mandatory 4 weeks, closing at end of day March
> 10th, or earlier if consensus occurs.  Let's use this email thread for that
> discussion.  In this mail I summarize public discussion and argue for
> "accept".
> >
> > In short, the proposal adds a way to have multiple mutable fields within
> a data-constructor, without the indirection of using IORef.  Second to
> "linear types", this proposal generated the most total comments during
> public discussion (107).  This level of discussion was good -- given that
> accepted GHC proposals so far are mostly syntactic (or API tweaks), this
> would be the first with major compiler backend & runtime consequences.
> >
> > Ed Kmett and Ryan Yates have demonstrated the applicability of this
> concept to data-structure implementation.  (Indeed, I think there's a good
> reason that almost all languages mutation with mutation are implemented so
> as to allow a single heap object to have multiple mutable fields within
> it.) During the public discussion, questions were raised about interactions
> with other features and implementation strategy -- in particularly changes
> to core.  But I believe that all major concerns were eventually answered.
> >
> >   -Ryan
> >
> > P.S. Iavor, Trevor, and Ryan Yates were all working on implementation of
> this feature at various points.  Not sure what the current status of
> implementation efforts are.
> >
> >
> > On Fri, Jul 14, 2017 at 8:17 AM, Joachim Breitner <
> mail at joachim-breitner.de> wrote:
> > > Dear Committee,
> > >
> > > this is your secretary speaking:
> > >
> > > https://github.com/ghc-proposals/ghc-proposals/pull/8
> > > was brought before the committee, by our own Simon Marlow.
> > >
> > > I propose Ryan Newton as the Shepherd, because he asked for it :-)
> > >
> > > Ryan, please reach consensus as described in
> > > https://github.com/ghc-proposals/ghc-proposals#committee-process
> > >
> > > I suggest you make a recommendation about the decision, maybe point out
> > > debatable points, and assume that anyone who stays quiet agrees with
> > > you.
> > >
> > >
> > > Greetings,
> > > Joachim
> > >
> > >
> > > --
> > > Joachim Breitner
> > >   mail at joachim-breitner.de
> > >   http://www.joachim-breitner.de/
> >
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> --
> Joachim Breitner
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20180508/8a44fe00/attachment.html>

From mail at joachim-breitner.de  Tue May  8 14:28:36 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 08 May 2018 10:28:36 -0400
Subject: [ghc-steering-committee] Please review: Mutable constructor
 fields, Shepherd: Ryan Newton
In-Reply-To: <CANsrgP+hK9wHYxiCeVy5HT84aQ6YiwEmcbo6zed4kWAka7PviQ@mail.gmail.com>
References: <1500034660.7133.5.camel@joachim-breitner.de>
 <CACYs5AbW2d7wuYQ5fEyH8Kdtxv3b4srPhn74e8MDQYpSC7=vtw@mail.gmail.com>
 <ac1e19fab015bdb230a32a3b2901445c64277536.camel@joachim-breitner.de>
 <CANsrgP+hK9wHYxiCeVy5HT84aQ6YiwEmcbo6zed4kWAka7PviQ@mail.gmail.com>
Message-ID: <4e098c535736d64a734c2055006b67643c05838b.camel@joachim-breitner.de>

Hi,

Am Dienstag, den 08.05.2018, 15:27 +0100 schrieb Simon Marlow:
> I'm not sure what the correct state to put the proposal in at this stage is - dormant perhaps?

Maybe “needs revision” (in the sense that it needs information that
comes from working on the implementation)?

Cheers,
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/20180508/8f10e419/attachment.sig>

From marlowsd at gmail.com  Tue May  8 15:53:26 2018
From: marlowsd at gmail.com (Simon Marlow)
Date: Tue, 8 May 2018 16:53:26 +0100
Subject: [ghc-steering-committee] Please review: Mutable constructor
 fields, Shepherd: Ryan Newton
In-Reply-To: <4e098c535736d64a734c2055006b67643c05838b.camel@joachim-breitner.de>
References: <1500034660.7133.5.camel@joachim-breitner.de>
 <CACYs5AbW2d7wuYQ5fEyH8Kdtxv3b4srPhn74e8MDQYpSC7=vtw@mail.gmail.com>
 <ac1e19fab015bdb230a32a3b2901445c64277536.camel@joachim-breitner.de>
 <CANsrgP+hK9wHYxiCeVy5HT84aQ6YiwEmcbo6zed4kWAka7PviQ@mail.gmail.com>
 <4e098c535736d64a734c2055006b67643c05838b.camel@joachim-breitner.de>
Message-ID: <CANsrgP+vT=F-t=wcxbEAxkAh-sdsGC6au_Tn03myrATqr9coXg@mail.gmail.com>

On 8 May 2018 at 15:28, Joachim Breitner <mail at joachim-breitner.de> wrote:

> Hi,
>
> Am Dienstag, den 08.05.2018, 15:27 +0100 schrieb Simon Marlow:
> > I'm not sure what the correct state to put the proposal in at this stage
> is - dormant perhaps?
>
> Maybe “needs revision” (in the sense that it needs information that
> comes from working on the implementation)?
>

Sounds good.

Simon




> Cheers,
> Joachim
> --
> Joachim Breitner
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20180508/7ff23582/attachment-0001.html>

From marlowsd at gmail.com  Tue May  8 16:16:35 2018
From: marlowsd at gmail.com (Simon Marlow)
Date: Tue, 8 May 2018 17:16:35 +0100
Subject: [ghc-steering-committee] Proposal UnliftedArray#: recommend
	acceptance
Message-ID: <CANsrgPKOvoqbZynO85Cq=r+21K=KfMSL+9MjqZd7HDtCz8PTng@mail.gmail.com>

UnliftedArray# has been proposed by Andrew Martin:
https://github.com/ghc-proposals/ghc-proposals/pull/112

In a nutshell, the proposal is to add new primitive types UnliftedArray#
and MutableUnliftedArray#

data UnliftedArray# :: TYPE 'UnliftedRep -> TYPE 'UnliftedRep
data MutableUnliftedArray# :: TYPE 'LiftedRep -> TYPE 'UnliftedRep -> TYPE
'UnliftedRep

with the appropriate set of primops, e.g.

indexUnliftedArray# :: forall (a :: TYPE 'UnliftedRep). UnliftedArray# a ->
Int# -> a

This makes complete sense and it is what we would have done from the start,
except that we only recently gained the ability to talk about type
variables that range over unlifted types.

UnliftedArray# subsumes some existing rather ugly sets of primops that were
added because we lacked the ability to define the more general version,
like ArrayArray# And ByteArrayArray#, also including the hilarious

indexArrayArrayArray# :: ArrayArray# -> Int# -> ArrayArray#

All of this can be defined in terms of the general UnliftedArray#. (the
migration will be easier if we can use UnliftedNewtypes to define
ArrayArray# in terms of UnliftedArray#, otherwise we have to keep the
original versions in the compiler, but I don't think the exact mechanism
matters all that much for the purposes of accepting or rejecting the
proposal).

Incidentally we might also want UnliftedMutVar#, UnliftedMVar#,
UnliftedTVar#, and maybe UnliftedStablePtr# but that's for another proposal.

I propose that we accept this. Any objections?

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

From iavor.diatchki at gmail.com  Tue May  8 20:37:53 2018
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Tue, 08 May 2018 20:37:53 +0000
Subject: [ghc-steering-committee] Proposal UnliftedArray#: recommend
	acceptance
In-Reply-To: <CANsrgPKOvoqbZynO85Cq=r+21K=KfMSL+9MjqZd7HDtCz8PTng@mail.gmail.com>
References: <CANsrgPKOvoqbZynO85Cq=r+21K=KfMSL+9MjqZd7HDtCz8PTng@mail.gmail.com>
Message-ID: <CAGK9nuqhTDnR7agUuy=Y=_z9fAZta2WzV7vWb+dK1DhXL-st1Q@mail.gmail.com>

Seems reasonable to me.

On Tue, May 8, 2018 at 9:17 AM Simon Marlow <marlowsd at gmail.com> wrote:

> UnliftedArray# has been proposed by Andrew Martin:
> https://github.com/ghc-proposals/ghc-proposals/pull/112
>
> In a nutshell, the proposal is to add new primitive types UnliftedArray#
> and MutableUnliftedArray#
>
> data UnliftedArray# :: TYPE 'UnliftedRep -> TYPE 'UnliftedRep
> data MutableUnliftedArray# :: TYPE 'LiftedRep -> TYPE 'UnliftedRep -> TYPE
> 'UnliftedRep
>
> with the appropriate set of primops, e.g.
>
> indexUnliftedArray# :: forall (a :: TYPE 'UnliftedRep). UnliftedArray# a
> -> Int# -> a
>
> This makes complete sense and it is what we would have done from the
> start, except that we only recently gained the ability to talk about type
> variables that range over unlifted types.
>
> UnliftedArray# subsumes some existing rather ugly sets of primops that
> were added because we lacked the ability to define the more general
> version, like ArrayArray# And ByteArrayArray#, also including the hilarious
>
> indexArrayArrayArray# :: ArrayArray# -> Int# -> ArrayArray#
>
> All of this can be defined in terms of the general UnliftedArray#. (the
> migration will be easier if we can use UnliftedNewtypes to define
> ArrayArray# in terms of UnliftedArray#, otherwise we have to keep the
> original versions in the compiler, but I don't think the exact mechanism
> matters all that much for the purposes of accepting or rejecting the
> proposal).
>
> Incidentally we might also want UnliftedMutVar#, UnliftedMVar#,
> UnliftedTVar#, and maybe UnliftedStablePtr# but that's for another proposal.
>
> I propose that we accept this. Any objections?
>
> Cheers
> Simon
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20180508/ed407eed/attachment.html>

From rae at cs.brynmawr.edu  Tue May  8 20:39:29 2018
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Tue, 8 May 2018 16:39:29 -0400
Subject: [ghc-steering-committee] Proposal UnliftedArray#: recommend
	acceptance
In-Reply-To: <CAGK9nuqhTDnR7agUuy=Y=_z9fAZta2WzV7vWb+dK1DhXL-st1Q@mail.gmail.com>
References: <CANsrgPKOvoqbZynO85Cq=r+21K=KfMSL+9MjqZd7HDtCz8PTng@mail.gmail.com>
 <CAGK9nuqhTDnR7agUuy=Y=_z9fAZta2WzV7vWb+dK1DhXL-st1Q@mail.gmail.com>
Message-ID: <0CE82159-7C36-4A33-AC4D-7F9DA02072D7@cs.brynmawr.edu>

Yay levity polymorphism.

+1 from me.

> On May 8, 2018, at 4:37 PM, Iavor Diatchki <iavor.diatchki at gmail.com> wrote:
> 
> Seems reasonable to me.
> 
> On Tue, May 8, 2018 at 9:17 AM Simon Marlow <marlowsd at gmail.com <mailto:marlowsd at gmail.com>> wrote:
> UnliftedArray# has been proposed by Andrew Martin:
> https://github.com/ghc-proposals/ghc-proposals/pull/112 <https://github.com/ghc-proposals/ghc-proposals/pull/112>
> 
> In a nutshell, the proposal is to add new primitive types UnliftedArray# and MutableUnliftedArray#
> 
> data UnliftedArray# :: TYPE 'UnliftedRep -> TYPE 'UnliftedRep
> data MutableUnliftedArray# :: TYPE 'LiftedRep -> TYPE 'UnliftedRep -> TYPE 'UnliftedRep
> 
> with the appropriate set of primops, e.g.
> 
> indexUnliftedArray# :: forall (a :: TYPE 'UnliftedRep). UnliftedArray# a -> Int# -> a
> 
> This makes complete sense and it is what we would have done from the start, except that we only recently gained the ability to talk about type variables that range over unlifted types.
> 
> UnliftedArray# subsumes some existing rather ugly sets of primops that were added because we lacked the ability to define the more general version, like ArrayArray# And ByteArrayArray#, also including the hilarious
> 
> indexArrayArrayArray# :: ArrayArray# -> Int# -> ArrayArray#
> 
> All of this can be defined in terms of the general UnliftedArray#. (the migration will be easier if we can use UnliftedNewtypes to define ArrayArray# in terms of UnliftedArray#, otherwise we have to keep the original versions in the compiler, but I don't think the exact mechanism matters all that much for the purposes of accepting or rejecting the proposal).
> 
> Incidentally we might also want UnliftedMutVar#, UnliftedMVar#, UnliftedTVar#, and maybe UnliftedStablePtr# but that's for another proposal.
> 
> I propose that we accept this. Any objections?
> 
> Cheers
> Simon
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> 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/20180508/0a325e81/attachment.html>

From ben at well-typed.com  Tue May  8 20:45:13 2018
From: ben at well-typed.com (Ben Gamari)
Date: Tue, 08 May 2018 16:45:13 -0400
Subject: [ghc-steering-committee] Proposal UnliftedArray#: recommend
	acceptance
In-Reply-To: <CANsrgPKOvoqbZynO85Cq=r+21K=KfMSL+9MjqZd7HDtCz8PTng@mail.gmail.com>
References: <CANsrgPKOvoqbZynO85Cq=r+21K=KfMSL+9MjqZd7HDtCz8PTng@mail.gmail.com>
Message-ID: <871selj2r0.fsf@smart-cactus.org>

Simon Marlow <marlowsd at gmail.com> writes:

...
> Incidentally we might also want UnliftedMutVar#, UnliftedMVar#,
> UnliftedTVar#, and maybe UnliftedStablePtr# but that's for another proposal.
>
> I propose that we accept this. Any objections?
>
Agreed, this is a great improvement over the status quo.

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/20180508/bd4fe95f/attachment.sig>

From simonpj at microsoft.com  Tue May  8 21:48:45 2018
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 8 May 2018 21:48:45 +0000
Subject: [ghc-steering-committee] Proposal UnliftedArray#:
	recommend	acceptance
In-Reply-To: <CANsrgPKOvoqbZynO85Cq=r+21K=KfMSL+9MjqZd7HDtCz8PTng@mail.gmail.com>
References: <CANsrgPKOvoqbZynO85Cq=r+21K=KfMSL+9MjqZd7HDtCz8PTng@mail.gmail.com>
Message-ID: <AM5PR83MB016362FE76544671FC7FA651AD9A0@AM5PR83MB0163.EURPRD83.prod.outlook.com>

Yes, looks good to me.

Simon

From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On Behalf Of Simon Marlow
Sent: 08 May 2018 17:17
To: ghc-steering-committee at haskell.org
Subject: [ghc-steering-committee] Proposal UnliftedArray#: recommend acceptance

UnliftedArray# has been proposed by Andrew Martin:
https://github.com/ghc-proposals/ghc-proposals/pull/112
In a nutshell, the proposal is to add new primitive types UnliftedArray# and MutableUnliftedArray#

data UnliftedArray# :: TYPE 'UnliftedRep -> TYPE 'UnliftedRep
data MutableUnliftedArray# :: TYPE 'LiftedRep -> TYPE 'UnliftedRep -> TYPE 'UnliftedRep
with the appropriate set of primops, e.g.

indexUnliftedArray# :: forall (a :: TYPE 'UnliftedRep). UnliftedArray# a -> Int# -> a
This makes complete sense and it is what we would have done from the start, except that we only recently gained the ability to talk about type variables that range over unlifted types.
UnliftedArray# subsumes some existing rather ugly sets of primops that were added because we lacked the ability to define the more general version, like ArrayArray# And ByteArrayArray#, also including the hilarious

indexArrayArrayArray# :: ArrayArray# -> Int# -> ArrayArray#
All of this can be defined in terms of the general UnliftedArray#. (the migration will be easier if we can use UnliftedNewtypes to define ArrayArray# in terms of UnliftedArray#, otherwise we have to keep the original versions in the compiler, but I don't think the exact mechanism matters all that much for the purposes of accepting or rejecting the proposal).
Incidentally we might also want UnliftedMutVar#, UnliftedMVar#, UnliftedTVar#, and maybe UnliftedStablePtr# but that's for another proposal.

I propose that we accept this. Any objections?
Cheers
Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20180508/c5d22bf6/attachment-0001.html>

From chak at justtesting.org  Wed May  9 02:33:33 2018
From: chak at justtesting.org (Manuel M T Chakravarty)
Date: Wed, 9 May 2018 12:33:33 +1000
Subject: [ghc-steering-committee] Proposal UnliftedArray#:
	recommend	acceptance
In-Reply-To: <CANsrgPKOvoqbZynO85Cq=r+21K=KfMSL+9MjqZd7HDtCz8PTng@mail.gmail.com>
References: <CANsrgPKOvoqbZynO85Cq=r+21K=KfMSL+9MjqZd7HDtCz8PTng@mail.gmail.com>
Message-ID: <F3BD3FF7-0E61-420D-934B-573FE427473E@justtesting.org>

+1

> Am 09.05.2018 um 02:16 schrieb Simon Marlow <marlowsd at gmail.com>:
> 
> UnliftedArray# has been proposed by Andrew Martin:
> https://github.com/ghc-proposals/ghc-proposals/pull/112 <https://github.com/ghc-proposals/ghc-proposals/pull/112>
> 
> In a nutshell, the proposal is to add new primitive types UnliftedArray# and MutableUnliftedArray#
> 
> data UnliftedArray# :: TYPE 'UnliftedRep -> TYPE 'UnliftedRep
> data MutableUnliftedArray# :: TYPE 'LiftedRep -> TYPE 'UnliftedRep -> TYPE 'UnliftedRep
> 
> with the appropriate set of primops, e.g.
> 
> indexUnliftedArray# :: forall (a :: TYPE 'UnliftedRep). UnliftedArray# a -> Int# -> a
> 
> This makes complete sense and it is what we would have done from the start, except that we only recently gained the ability to talk about type variables that range over unlifted types.
> 
> UnliftedArray# subsumes some existing rather ugly sets of primops that were added because we lacked the ability to define the more general version, like ArrayArray# And ByteArrayArray#, also including the hilarious
> 
> indexArrayArrayArray# :: ArrayArray# -> Int# -> ArrayArray#
> 
> All of this can be defined in terms of the general UnliftedArray#. (the migration will be easier if we can use UnliftedNewtypes to define ArrayArray# in terms of UnliftedArray#, otherwise we have to keep the original versions in the compiler, but I don't think the exact mechanism matters all that much for the purposes of accepting or rejecting the proposal).
> 
> Incidentally we might also want UnliftedMutVar#, UnliftedMVar#, UnliftedTVar#, and maybe UnliftedStablePtr# but that's for another proposal.
> 
> I propose that we accept this. Any objections?
> 
> Cheers
> Simon
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20180509/a27b7876/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 874 bytes
Desc: Message signed with OpenPGP
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20180509/a27b7876/attachment.sig>

From mail at joachim-breitner.de  Wed May  9 20:21:38 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 09 May 2018 16:21:38 -0400
Subject: [ghc-steering-committee] Volutneer shepherding for linear types
	sought
Message-ID: <9121eb03c4613bf3d192c64f563e534fff52c2c5.camel@joachim-breitner.de>

Hi committee,

usually, when a proposal has been submitted, I just pick a shepherd¹.
But I feel the linear types proposal, at
https://github.com/tweag/ghc-proposals/blob/linear-types2/proposals/0000-linear-types.rst
is not something I can just impose on any of you.

Therefore, I’d like to have a volunteer to step forward and claim this
one.


Any takers?

Joachim


¹ In case you are curious, I look at this data to make a pick:
  * Low number of pending proposals shepherded
  * Low number of total proposals handled
  * Prior activity on the proposal discussion
  * Expertise and interest, as perceived by me
  You can influence that easily by engaging in a proposal discussion
  before it is submitted; that’s a sure way of getting a proposal 
  assigned.

-- 
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/20180509/341fa9ef/attachment.sig>

From mail at joachim-breitner.de  Mon May 14 22:20:27 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 14 May 2018 18:20:27 -0400
Subject: [ghc-steering-committee] Proposal UnliftedArray#: recommend
 acceptance
In-Reply-To: <CANsrgPKOvoqbZynO85Cq=r+21K=KfMSL+9MjqZd7HDtCz8PTng@mail.gmail.com>
References: <CANsrgPKOvoqbZynO85Cq=r+21K=KfMSL+9MjqZd7HDtCz8PTng@mail.gmail.com>
Message-ID: <cd02089813f984a7d679336455fb90c7d49e0431.camel@joachim-breitner.de>

Hi,

the consensus was strong in this one; accepted!

Cheers,
Joachim


Am Dienstag, den 08.05.2018, 17:16 +0100 schrieb Simon Marlow:
> UnliftedArray# has been proposed by Andrew Martin:
> https://github.com/ghc-proposals/ghc-proposals/pull/112
> 
> In a nutshell, the proposal is to add new primitive types UnliftedArray# and MutableUnliftedArray#
> 
> data UnliftedArray# :: TYPE 'UnliftedRep -> TYPE 'UnliftedRep
> data MutableUnliftedArray# :: TYPE 'LiftedRep -> TYPE 'UnliftedRep -> TYPE 'UnliftedRep
> 
> with the appropriate set of primops, e.g.
> 
> indexUnliftedArray# :: forall (a :: TYPE 'UnliftedRep). UnliftedArray# a -> Int# -> a
> 
> This makes complete sense and it is what we would have done from the start, except that we only recently gained the ability to talk about type variables that range over unlifted types.
> 
> UnliftedArray# subsumes some existing rather ugly sets of primops that were added because we lacked the ability to define the more general version, like ArrayArray# And ByteArrayArray#, also including the hilarious
> 
> indexArrayArrayArray# :: ArrayArray# -> Int# -> ArrayArray#
> 
> All of this can be defined in terms of the general UnliftedArray#. (the migration will be easier if we can use UnliftedNewtypes to define ArrayArray# in terms of UnliftedArray#, otherwise we have to keep the original versions in the compiler, but I don't think the exact mechanism matters all that much for the purposes of accepting or rejecting the proposal).
> 
> Incidentally we might also want UnliftedMutVar#, UnliftedMVar#, UnliftedTVar#, and maybe UnliftedStablePtr# but that's for another proposal.
> 
> I propose that we accept this. Any objections?
> 
> Cheers
> Simon
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/
-------------- 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/20180514/6c12b1b8/attachment.sig>

From mail at joachim-breitner.de  Mon May 14 22:32:53 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 14 May 2018 18:32:53 -0400
Subject: [ghc-steering-committee] TypeApplications for Overloaded
 Literals (#129), Recommendation: reject
In-Reply-To: <C0FBF733-E547-487B-AC9D-6C68E9EA8C0A@joachim-breitner.de>
References: <f14d2e97e2eaaac98a8dcaaa868db5176f1d6433.camel@joachim-breitner.de>
 <CAGK9nuqsTCxpjHAT2UFxqaBn=oXDrVSa1NUT0uXCwbiO0yRM7A@mail.gmail.com>
 <9c8fd6398e89c1ea940a5e1fab666157a67c0e88.camel@joachim-breitner.de>
 <CAGK9nuqiXWPFzh5LMCAwCn_kUw2766yX=w69V2MHYTJBsRqSWg@mail.gmail.com>
 <1089D9C9-303F-464C-8E1E-075FE569186F@cs.brynmawr.edu>
 <AM5PR83MB0163598FB966CCE33D7045E5AD9A0@AM5PR83MB0163.EURPRD83.prod.outlook.com>
 <C0FBF733-E547-487B-AC9D-6C68E9EA8C0A@joachim-breitner.de>
Message-ID: <363d08ec9c33de2a4ff123db198c4c6892451772.camel@joachim-breitner.de>

Hi,

guess this one goes down as rejected. Will close it with a rationale.

Cheers,
Joachim

Am Dienstag, den 08.05.2018, 08:20 -0400 schrieb Joachim Breitner:
> Hi,
> 
> it seems this proposal does not get much support. I kinda like the
> high-level goal, but not enough to defend it vehemently. I am
> changing my recommendation to reject, to facilitate consensus.
> 
> I should give those time to speak up who were in silent agreement
> with my initial recommendation, and if nothing happens, will reject
> this proposal in a week's time.
> 
> 
> 
> Am 8. Mai 2018 06:40:30 GMT-04:00 schrieb Simon Peyton Jones <simonpj at microsoft.com>:
> > I’m on the fence:
> > 
> >  *   Benefit: slight
> >  *   Cost: slight
> > 
> > But the spec is distressingly ad-hoc.  Magical behaviour if
> > 
> >  *   RebindableSyntax is no
> >  *   The ‘fromInteger’ in scope is not ‘Prelude.fromInteger’
> > 
> > So I lean to rejection.  Unless some stronger motivations emerge.
> > 
> > Simon
> > 
> > From: ghc-steering-committee
> > <ghc-steering-committee-bounces at haskell.org> On Behalf Of Richard
> > Eisenberg
> > Sent: 06 May 2018 20:27
> > To: Iavor Diatchki <iavor.diatchki at gmail.com>
> > Cc: ghc-steering-committee at haskell.org; Joachim Breitner
> > <mail at joachim-breitner.de>
> > Subject: Re: [ghc-steering-committee] TypeApplications for Overloaded
> > Literals (#129), Recommendation: accept
> > 
> > I'm also unconvinced about this proposal. It's hard to specify,
> > requiring that Prelude.fromInteger be magical. Note that if someone
> > defined a separate Num class (under -XNoImplicitPrelude
> > -XRebindableSyntax) that's fully equivalent to Prelude.Num, it wouldn't
> > work. Also, Joachim's point about `:t 5` is a poor motivation: `:t`
> > does not give you helpful information w.r.t. type applications. You
> > need `:t +v`. With -fprint-explicit-foralls,
> > 
> > λ> :t +v 5
> > 5 :: forall {p}. Num p => p
> > 
> > The appearance of the braces in the output means that 5 is not
> > available for visible type application (the variable p is *inferred*).
> > So if there's any unexpected behavior in the current implementation,
> > that's due to ill-informed expectations, not misbehavior.
> > 
> > In the end, I would prefer to reject this proposal in favor of
> > Joachim's casual proposal here:
> > https://mail.haskell.org/pipermail/ghc-steering-committee/2018-May/000541.html
> > (and expanded upon by my subsequent post).
> > 
> > Richard
> > 
> > 
> > On May 6, 2018, at 12:27 PM, Iavor Diatchki
> > <iavor.diatchki at gmail.com<mailto:iavor.diatchki at gmail.com>> wrote:
> > 
> > I am not convinced, if that's the sole motivation.  By that reasoning
> > you might expect that `(-5) @Int` or `(5+1) @Int` would also work, but
> > they wouldn't.
> > 
> > 
> > 
> > On Sun, May 6, 2018 at 8:47 AM Joachim Breitner
> > <mail at joachim-breitner.de<mailto:mail at joachim-breitner.de>> wrote:
> > Hi,
> > 
> > Am Sonntag, den 06.05.2018, 15:42 +0000 schrieb Iavor Diatchki:
> > > Is there a reason why we should write `5 @Int` as opposed to `5 ::
> > 
> > Int`?
> > 
> > Because we can. Or rather, we should can, because
> > 
> >   Prelude> :t 5
> >   5 :: Num t => t
> >   Prelude> :t 5 @Double
> >   <interactive>:1:1: error:
> >       • Cannot apply expression of type ‘t0’
> >         to a visible type argument ‘Double’
> >       • In the expression: 5 @Double
> > 
> > is confusing and inconsistent with the user’s expectation after
> > learning about when they can use ExplicitTypeApplications (unless one
> > knows about the syntactic sugar involved.)
> > 
> > > Also, there appears to be a typo in the spec, the part which
> > 
> > specifies translations for integers (1 turned into 0?)
> > 
> > thanks, fixed.
> > 
> > 
> > (BTW, all of you are owners of the repository and should have the
> > necessary permissions to edit pull requests directly.)
> > 
> > Cheers,
> > Joachim
> > 
> > --
> > Joachim Breitner
> >  mail at joachim-breitner.de<mailto:mail at joachim-breitner.de>
> >  http://www.joachim-breitner.de/
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/
-------------- 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/20180514/3b96d717/attachment.sig>

From mail at joachim-breitner.de  Mon May 14 22:37:42 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 14 May 2018 18:37:42 -0400
Subject: [ghc-steering-committee] Please Review: Type annotated quoters
 (#125), Shepherd: Manuel
In-Reply-To: <6652d90f8d991d1ff72031ba042bf7613e3a99ce.camel@joachim-breitner.de>
References: <6652d90f8d991d1ff72031ba042bf7613e3a99ce.camel@joachim-breitner.de>
Message-ID: <294b2c96e9b04fc5e235eb55fb8a9bfcbbf784e1.camel@joachim-breitner.de>

JFTR, Manuel has volunteered to take over shepherding this one.

Am Sonntag, den 06.05.2018, 10:28 -0400 schrieb Joachim Breitner:
> Dear Committee,
> 
> this is your secretary speaking:
> 
> Type annotated quoters have been proposed by Winterland
> https://github.com/ghc-proposals/ghc-proposals/pull/125
> 
> I propose Simon Peyton Jones as the shepherd, as he has already looked at this.
> 
> Simon, please reach consensus as described in
> https://github.com/ghc-proposals/ghc-proposals#committee-process
> I suggest you make a recommendation, in a new e-mail thread with the
> proposal number in the subject, about the decision, maybe point out
> debatable points, and assume that anyone who stays quiet agrees with
> you.

-- 
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/20180514/7ca1deaf/attachment.sig>

From mail at joachim-breitner.de  Tue May 15 16:08:22 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 15 May 2018 12:08:22 -0400
Subject: [ghc-steering-committee] Please Review: bundling patterns with type
 synonyms (#28), Shepherd: Chris Allen
Message-ID: <721785e8976177cdd9f4800bb8a2999fb58256ac.camel@joachim-breitner.de>

Dear Committee,

this is your secretary speaking:

bundling patterns with type synonyms by Bertram Felgenhauer and Joe Hermaszewski
https://github.com/ghc-proposals/ghc-proposals/pull/28

I propose Chris Allen as the shepherd, as he has already looked at this.

Chris, please reach consensus as described in
https://github.com/ghc-proposals/ghc-proposals#committee-process
I suggest you make a recommendation, in a new e-mail thread with the
proposal number in the subject, about the decision, maybe point out
debatable points, and assume that anyone who stays quiet agrees with
you.

Thanks,
Joachim
-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/
-------------- 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/20180515/47978bcd/attachment.sig>

From marlowsd at gmail.com  Fri May 18 08:24:02 2018
From: marlowsd at gmail.com (Simon Marlow)
Date: Fri, 18 May 2018 09:24:02 +0100
Subject: [ghc-steering-committee] Array resizing primitives (#121),
	proposal: accept with modifications
Message-ID: <CANsrgP+MiBu6q_JgPuO1ffceQipywekC_RpxtAV_-aNz0gbSew@mail.gmail.com>

I propose that we accept https://github.com/ghc-
proposals/ghc-proposals/pull/121
With one modification (below).

In summary, this proposal suggests adding primitives for resizing
(shrinking or expanding) primitives mutable arrays of pointers. See the
proposal for motivation. There would be two primitives per array type:

shrinkArray# :: MutableArray# s a -> Int# -> State# s -> State# s
resizeArray# :: MutableArray# s a -> Int# -> a -> State# s -> (# State# s,
MutableArray# s a #)

(these mirror the existing shrink and resize primitives we have for
ByteArray#, with the same rationale)

The biggest downside is that we currently have

  sizeOfMutableArray# :: MutableArray# s a -> Int #

which would need to be replaced by a stateful operation

  getSizeOfMutableArray# :: MutableArray# s a -> State# s -> (# State# s,
Int# #)

So we would need to deprecate the old primops, update any code we have that
uses them, and clearly indicate the unsafety in the docs. But this has
knock-on effects in Data.Primitive:

sizeofMutableArray :: MutableArray s a -> Int

this would need to be deprecated and replaced by a PrimMonad operation.
The pure version would be unsafe in the sense that it could return the
wrong size, and a future indexing operation relying on the incorrect size
could access an out-of-bounds element.

Suggested modifications:
* Remove the ArrayArray# primitives, add UniftedArray# primitives instead
(see
https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0021-unlifted-array.rst
)

Cheers
Simon


On 1 May 2018 at 13:12, Joachim Breitner <mail at joachim-breitner.de> wrote:

> Dear Committee,
>
> this is your secretary speaking:
>
> Array resizing primitives have been proposed by David Feuer:
> https://github.com/ghc-proposals/ghc-proposals/pull/121
>
> I propose Simon Marlow as the shepherd.
>
> Simon, please reach consensus as described in
> https://github.com/ghc-proposals/ghc-proposals#committee-process
>
> I suggest you make a recommendation, in a new e-mail thread with the
> proposal number in the subject, about the decision, maybe point out
> debatable points, and assume that anyone who stays quiet agrees with
> you.
>
> Thanks,
> --
> Joachim Breitner
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20180518/0de25b2f/attachment.html>

From simonpj at microsoft.com  Fri May 18 12:25:08 2018
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 18 May 2018 12:25:08 +0000
Subject: [ghc-steering-committee] Array resizing primitives (#121),
	proposal: accept with modifications
In-Reply-To: <CANsrgP+MiBu6q_JgPuO1ffceQipywekC_RpxtAV_-aNz0gbSew@mail.gmail.com>
References: <CANsrgP+MiBu6q_JgPuO1ffceQipywekC_RpxtAV_-aNz0gbSew@mail.gmail.com>
Message-ID: <AM5PR83MB01630B8477AF154DBFA8415FAD900@AM5PR83MB0163.EURPRD83.prod.outlook.com>

Looks OK to me; but I’m no expert.

Simon

From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On Behalf Of Simon Marlow
Sent: 18 May 2018 09:24
To: Joachim Breitner <mail at joachim-breitner.de>
Cc: ghc-steering-committee at haskell.org
Subject: [ghc-steering-committee] Array resizing primitives (#121), proposal: accept with modifications

I propose that we accept https://github.com/ghc-proposals/ghc-proposals/pull/121
With one modification (below).

In summary, this proposal suggests adding primitives for resizing (shrinking or expanding) primitives mutable arrays of pointers. See the proposal for motivation. There would be two primitives per array type:

shrinkArray# :: MutableArray# s a -> Int# -> State# s -> State# s
resizeArray# :: MutableArray# s a -> Int# -> a -> State# s -> (# State# s, MutableArray# s a #)
(these mirror the existing shrink and resize primitives we have for ByteArray#, with the same rationale)

The biggest downside is that we currently have

  sizeOfMutableArray# :: MutableArray# s a -> Int #
which would need to be replaced by a stateful operation

  getSizeOfMutableArray# :: MutableArray# s a -> State# s -> (# State# s, Int# #)
So we would need to deprecate the old primops, update any code we have that uses them, and clearly indicate the unsafety in the docs. But this has knock-on effects in Data.Primitive:

sizeofMutableArray :: MutableArray s a -> Int

this would need to be deprecated and replaced by a PrimMonad operation.  The pure version would be unsafe in the sense that it could return the wrong size, and a future indexing operation relying on the incorrect size could access an out-of-bounds element.

Suggested modifications:
* Remove the ArrayArray# primitives, add UniftedArray# primitives instead (see https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0021-unlifted-array.rst)

Cheers
Simon

On 1 May 2018 at 13:12, Joachim Breitner <mail at joachim-breitner.de<mailto:mail at joachim-breitner.de>> wrote:
Dear Committee,

this is your secretary speaking:

Array resizing primitives have been proposed by David Feuer:
https://github.com/ghc-proposals/ghc-proposals/pull/121

I propose Simon Marlow as the shepherd.

Simon, please reach consensus as described in
https://github.com/ghc-proposals/ghc-proposals#committee-process

I suggest you make a recommendation, in a new e-mail thread with the
proposal number in the subject, about the decision, maybe point out
debatable points, and assume that anyone who stays quiet agrees with
you.

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

_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

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

From mail at joachim-breitner.de  Fri May 18 15:41:13 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Fri, 18 May 2018 11:41:13 -0400
Subject: [ghc-steering-committee] Resurrect Pattern Signatures (#119),
 Recommendation: accept
In-Reply-To: <CADnndOpsAJv_=vinWSvKwkBTGg3oPJ-U543pD2QSFYM7miguAw@mail.gmail.com>
References: <CADnndOp6Rx0DLXwQV-6pRY8m63Qg1rPP+9jr2m3_Zej73x4Knw@mail.gmail.com>
 <CANsrgPJLdCP8sCJ+TKiykg=kZ85C733H9HMPdViixG0GHZu13Q@mail.gmail.com>
 <CADnndOpsAJv_=vinWSvKwkBTGg3oPJ-U543pD2QSFYM7miguAw@mail.gmail.com>
Message-ID: <6be7569f6b219feaeaf37f7817ddbe4b28c308f3.camel@joachim-breitner.de>

Hi,

Am Freitag, den 04.05.2018, 17:01 -0500 schrieb Christopher Allen:
> I'd be happy rejecting this.

ok, this seems to be consensus. Marking it as rejected.

Cheers,
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/20180518/3287b94f/attachment.sig>

From mail at joachim-breitner.de  Sat May 19 18:45:29 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sat, 19 May 2018 14:45:29 -0400
Subject: [ghc-steering-committee] Volutneer shepherding for linear types
 sought
In-Reply-To: <9121eb03c4613bf3d192c64f563e534fff52c2c5.camel@joachim-breitner.de>
References: <9121eb03c4613bf3d192c64f563e534fff52c2c5.camel@joachim-breitner.de>
Message-ID: <2dea26a1d05e7a3716bfa0bab24048b183d14911.camel@joachim-breitner.de>

Hi,

this has been met with dead silence … here is a loaded question: Who
here cares about linear types? :-)

Cheers,
Joachim

Am Mittwoch, den 09.05.2018, 16:21 -0400 schrieb Joachim Breitner:
> Hi committee,
> 
> usually, when a proposal has been submitted, I just pick a shepherd¹.
> But I feel the linear types proposal, at
> https://github.com/tweag/ghc-proposals/blob/linear-types2/proposals/0000-linear-types.rst
> is not something I can just impose on any of you.
> 
> Therefore, I’d like to have a volunteer to step forward and claim this
> one.
> 
> 
> Any takers?
> 
> Joachim
> 
> 
> ¹ In case you are curious, I look at this data to make a pick:
>   * Low number of pending proposals shepherded
>   * Low number of total proposals handled
>   * Prior activity on the proposal discussion
>   * Expertise and interest, as perceived by me
>   You can influence that easily by engaging in a proposal discussion
>   before it is submitted; that’s a sure way of getting a proposal 
>   assigned.
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/
-------------- 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/20180519/7872bedb/attachment.sig>

From simonpj at microsoft.com  Mon May 21 09:01:16 2018
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 21 May 2018 09:01:16 +0000
Subject: [ghc-steering-committee] Volutneer shepherding for linear types
 sought
In-Reply-To: <2dea26a1d05e7a3716bfa0bab24048b183d14911.camel@joachim-breitner.de>
References: <9121eb03c4613bf3d192c64f563e534fff52c2c5.camel@joachim-breitner.de>
 <2dea26a1d05e7a3716bfa0bab24048b183d14911.camel@joachim-breitner.de>
Message-ID: <AM5PR83MB0163CE2DD9296597D59EB38DAD950@AM5PR83MB0163.EURPRD83.prod.outlook.com>

I care about them -- but I'm implicated in the proposal.

I suspect the silence is mostly to do with the fact that it’s a substantial proposal.  It's certainly much more far-reaching than most of the proposals that we devote our time to.  That's good -- but it's also daunting.

Simon

|  -----Original Message-----
|  From: ghc-steering-committee <ghc-steering-committee-
|  bounces at haskell.org> On Behalf Of Joachim Breitner
|  Sent: 19 May 2018 19:45
|  To: ghc-steering-committee at haskell.org
|  Subject: Re: [ghc-steering-committee] Volutneer shepherding for linear
|  types sought
|  
|  Hi,
|  
|  this has been met with dead silence … here is a loaded question: Who
|  here cares about linear types? :-)
|  
|  Cheers,
|  Joachim
|  
|  Am Mittwoch, den 09.05.2018, 16:21 -0400 schrieb Joachim Breitner:
|  > Hi committee,
|  >
|  > usually, when a proposal has been submitted, I just pick a
|  shepherd¹.
|  > But I feel the linear types proposal, at
|  > https://github.com/tweag/ghc-proposals/blob/linear-
|  types2/proposals/00
|  > 00-linear-types.rst is not something I can just impose on any of
|  you.
|  >
|  > Therefore, I’d like to have a volunteer to step forward and claim
|  this
|  > one.
|  >
|  >
|  > Any takers?
|  >
|  > Joachim
|  >
|  >
|  > ¹ In case you are curious, I look at this data to make a pick:
|  >   * Low number of pending proposals shepherded
|  >   * Low number of total proposals handled
|  >   * Prior activity on the proposal discussion
|  >   * Expertise and interest, as perceived by me
|  >   You can influence that easily by engaging in a proposal discussion
|  >   before it is submitted; that’s a sure way of getting a proposal
|  >   assigned.
|  >
|  > _______________________________________________
|  > ghc-steering-committee mailing list
|  > ghc-steering-committee at haskell.org
|  > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-
|  committ
|  > ee
|  --
|  Joachim Breitner
|    mail at joachim-breitner.de
|    http://www.joachim-breitner.de/

From ben at well-typed.com  Mon May 21 13:29:49 2018
From: ben at well-typed.com (Ben Gamari)
Date: Mon, 21 May 2018 09:29:49 -0400
Subject: [ghc-steering-committee] Volutneer shepherding for linear types
	sought
In-Reply-To: <AM5PR83MB0163CE2DD9296597D59EB38DAD950@AM5PR83MB0163.EURPRD83.prod.outlook.com>
References: <9121eb03c4613bf3d192c64f563e534fff52c2c5.camel@joachim-breitner.de>
 <2dea26a1d05e7a3716bfa0bab24048b183d14911.camel@joachim-breitner.de>
 <AM5PR83MB0163CE2DD9296597D59EB38DAD950@AM5PR83MB0163.EURPRD83.prod.outlook.com>
Message-ID: <87603hdtmg.fsf@smart-cactus.org>

Simon Peyton Jones <simonpj at microsoft.com> writes:

> I care about them -- but I'm implicated in the proposal.
>
> I suspect the silence is mostly to do with the fact that it’s a
> substantial proposal. It's certainly much more far-reaching than most
> of the proposals that we devote our time to. That's good -- but it's
> also daunting.
>
Indeed, I'll admit that I am a tad intimidated by its size and potential
subtlety.

-------------- 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/20180521/87f9257b/attachment.sig>

From rae at cs.brynmawr.edu  Mon May 21 14:44:13 2018
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Mon, 21 May 2018 10:44:13 -0400
Subject: [ghc-steering-committee] Volutneer shepherding for linear types
 sought
In-Reply-To: <87603hdtmg.fsf@smart-cactus.org>
References: <9121eb03c4613bf3d192c64f563e534fff52c2c5.camel@joachim-breitner.de>
 <2dea26a1d05e7a3716bfa0bab24048b183d14911.camel@joachim-breitner.de>
 <AM5PR83MB0163CE2DD9296597D59EB38DAD950@AM5PR83MB0163.EURPRD83.prod.outlook.com>
 <87603hdtmg.fsf@smart-cactus.org>
Message-ID: <A026FE24-2AA0-4FED-B1FF-E2EDBF7BDCC8@cs.brynmawr.edu>

Sucker for punishment that I am, I'll take it. I'd like to learn more about it anyway. But no further action this week on it -- it's supposed to be vacation for me! :)

Richard

> On May 21, 2018, at 9:29 AM, Ben Gamari <ben at well-typed.com> wrote:
> 
> Simon Peyton Jones <simonpj at microsoft.com> writes:
> 
>> I care about them -- but I'm implicated in the proposal.
>> 
>> I suspect the silence is mostly to do with the fact that it’s a
>> substantial proposal. It's certainly much more far-reaching than most
>> of the proposals that we devote our time to. That's good -- but it's
>> also daunting.
>> 
> Indeed, I'll admit that I am a tad intimidated by its size and potential
> subtlety.
> 
> _______________________________________________
> 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  Mon May 21 14:46:33 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 21 May 2018 10:46:33 -0400
Subject: [ghc-steering-committee] Volutneer shepherding for linear types
 sought
In-Reply-To: <A026FE24-2AA0-4FED-B1FF-E2EDBF7BDCC8@cs.brynmawr.edu>
References: <9121eb03c4613bf3d192c64f563e534fff52c2c5.camel@joachim-breitner.de>
 <2dea26a1d05e7a3716bfa0bab24048b183d14911.camel@joachim-breitner.de>
 <AM5PR83MB0163CE2DD9296597D59EB38DAD950@AM5PR83MB0163.EURPRD83.prod.outlook.com>
 <87603hdtmg.fsf@smart-cactus.org>
 <A026FE24-2AA0-4FED-B1FF-E2EDBF7BDCC8@cs.brynmawr.edu>
Message-ID: <72ba6a30e674b071a3fc7774f5f4b61f1ee1defe.camel@joachim-breitner.de>

Hi,

yay! You got it :-)


Cheers,
Joachim

Am Montag, den 21.05.2018, 10:44 -0400 schrieb Richard Eisenberg:
> Sucker for punishment that I am, I'll take it. I'd like to learn more about it anyway. But no further action this week on it -- it's supposed to be vacation for me! :)
> 
> Richard
> 
> > On May 21, 2018, at 9:29 AM, Ben Gamari <ben at well-typed.com> wrote:
> > 
> > Simon Peyton Jones <simonpj at microsoft.com> writes:
> > 
> > > I care about them -- but I'm implicated in the proposal.
> > > 
> > > I suspect the silence is mostly to do with the fact that it’s a
> > > substantial proposal. It's certainly much more far-reaching than most
> > > of the proposals that we devote our time to. That's good -- but it's
> > > also daunting.
> > > 
> > 
> > Indeed, I'll admit that I am a tad intimidated by its size and potential
> > subtlety.
> > 
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/
-------------- 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/20180521/ac8d9de7/attachment.sig>

From mail at joachim-breitner.de  Tue May 22 12:22:04 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 22 May 2018 08:22:04 -0400
Subject: [ghc-steering-committee] Deriving via (#120),
 Recommendation: accept
In-Reply-To: <1120f3f6e9e401d18f1fe783df469bd50daa80ec.camel@joachim-breitner.de>
References: <b009873da7627da212ce0be8b4fe8f5eb2fdd504.camel@joachim-breitner.de>
 <VI1PR83MB01741E31C164DC895C5D0DD3AD880@VI1PR83MB0174.EURPRD83.prod.outlook.com>
 <1120f3f6e9e401d18f1fe783df469bd50daa80ec.camel@joachim-breitner.de>
Message-ID: <6f08932576155a9ca8a059006147798fb7ea98b4.camel@joachim-breitner.de>

Hi,

Am Samstag, den 05.05.2018, 17:01 -0400 schrieb Joachim Breitner:
> there seems to be mainly consensus here.

no complains: Accepted!

Cheers,
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/20180522/d3cd9aa5/attachment.sig>

From simonpj at microsoft.com  Tue May 22 16:34:08 2018
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 22 May 2018 16:34:08 +0000
Subject: [ghc-steering-committee] Treat kind and type vars identically
 with `forall` #103
In-Reply-To: <6b07f048d66cb3c7c8d11aa804b41ff79f06ba62.camel@joachim-breitner.de>
References: <AM5PR83MB016352A1E70E1B8F8B3DDE08ADA90@AM5PR83MB0163.EURPRD83.prod.outlook.com>
 <F75EF69C-8C57-4391-9315-40795483EA4A@cs.brynmawr.edu>
 <dc18ac6b5e75c2fe6de745159f719476b79ba0c4.camel@joachim-breitner.de>
 <720B3F27-9A49-4F31-BE42-B35AD5A73531@cs.brynmawr.edu>
 <6b07f048d66cb3c7c8d11aa804b41ff79f06ba62.camel@joachim-breitner.de>
Message-ID: <AM5PR83MB0163D6EABA6ACEB543D66A29AD940@AM5PR83MB0163.EURPRD83.prod.outlook.com>

Dear committee

> > I strongly propose that we accept
> >             Treat kind and type vars identically with `forall` #103
> 
> Agreed, unsurprisingly.

There seems to be consensus.  We accept!

I proposed this:

> > Moreover, I propose that we adopt it without a 3-release wait after
> > #83 – see under Alternatives.   Any programs that are rejected by
> > #103 can be fixed by adding some extra forall k’s.  And that change
> > will be accepted NOW if you add -XTypeInType. 

But Richard and Manual disagreed:

> Here I disagree. Enabling -XTypeInType has two unfortunate knock-on
> effects:
>  - * is no longer available in kinds, without import Data.Kind.
> Happily, GHC gives a good error message upon a forgotten `import
> Data.Kind`, so this isn't so bad, but it will bite very widely.
>  - More troublesomely, the CUSK rules are different with -XTypeInType
> than without. This means that turning on -XTypeInType can turn some
> CUSKs into non-CUSKs, producing utterly befuddling error messages.
> Maybe this won't bite so often, but when it does, it will take a
> developer a long time to sort out the problem.
> 
> After #83, these problems melt away, but I think it will be painful
> for users to support multiple versions in the meantime.

So let's accept the proposal as-is, i.e. with the 3-release wait.

Simon

From mail at joachim-breitner.de  Tue May 22 16:43:23 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 22 May 2018 12:43:23 -0400
Subject: [ghc-steering-committee] Treat kind and type vars identically
 with `forall` #103
In-Reply-To: <AM5PR83MB0163D6EABA6ACEB543D66A29AD940@AM5PR83MB0163.EURPRD83.prod.outlook.com>
References: <AM5PR83MB016352A1E70E1B8F8B3DDE08ADA90@AM5PR83MB0163.EURPRD83.prod.outlook.com>
 <F75EF69C-8C57-4391-9315-40795483EA4A@cs.brynmawr.edu>
 <dc18ac6b5e75c2fe6de745159f719476b79ba0c4.camel@joachim-breitner.de>
 <720B3F27-9A49-4F31-BE42-B35AD5A73531@cs.brynmawr.edu>
 <6b07f048d66cb3c7c8d11aa804b41ff79f06ba62.camel@joachim-breitner.de>
 <AM5PR83MB0163D6EABA6ACEB543D66A29AD940@AM5PR83MB0163.EURPRD83.prod.outlook.com>
Message-ID: <54d8c113a19a62c80674388eebb9268e306ff4bd.camel@joachim-breitner.de>

Hi,


Am Dienstag, den 22.05.2018, 16:34 +0000 schrieb Simon Peyton Jones:
> There seems to be consensus.  We accept!

yay, merged!

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/20180522/cb33f815/attachment.sig>

From mail at joachim-breitner.de  Thu May 24 10:23:19 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 24 May 2018 12:23:19 +0200
Subject: [ghc-steering-committee] Deprecating Exports (#134);
	Recommendation: accept
Message-ID: <4190e462230660bd0e95c781a5473bbd4dd47cbd.camel@joachim-breitner.de>

Hi,

alanasp has proposed a Deprecating Exports mechanism:
https://github.com/alanasp/ghc-proposals/blob/patch-2/proposals/deprecating_exports_proposal.rst

The gist is explained by this:

   module Data.List
   (  ...
       {-# DEPRECATE lines "Exported from Data.String instead" #-}
       , lines
       ...t
   ) where

i.e. DEPRECATE pragmas in export lists cause warning when some other
module uses the deprecated symbol when it is imported (only) via some
deprecated export.

This is a GSOC 2018 project, mentored by Matthew Pickering and Erik de
Castro Lopo.

The feature has a clear use-case, is self-contained and David Feuer
(the containers maintainer) has already confirmed that there is a real
demand for this. I suggest acceptance!


As always, I will understand silence as tactic consensus.

Cheers,
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/20180524/04c20bd8/attachment.sig>

From iavor.diatchki at gmail.com  Thu May 24 17:04:45 2018
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Thu, 24 May 2018 10:04:45 -0700
Subject: [ghc-steering-committee] Deprecating Exports (#134);
 Recommendation: accept
In-Reply-To: <4190e462230660bd0e95c781a5473bbd4dd47cbd.camel@joachim-breitner.de>
References: <4190e462230660bd0e95c781a5473bbd4dd47cbd.camel@joachim-breitner.de>
Message-ID: <CAGK9nuqnZ6AoS0hQKytX6qOQgC8B+1vcskSHjVJF9MGJY_kDzA@mail.gmail.com>

I have a bunch of question about this proposal, but I wrote them on the
proposal discussion page, as this is what folks asked for, last time I had
some questions.   I think answering them would make the proposal more
clear.

It seems to me that the use of this extension is somewhat limited, but it
could be useful on occasion so I could take it or leave it.    It's been a
while since I've looked at the GHC source, but I don't think that
implementing this would be completely trivial, as I don't thing GHC
currently cares about *how* names came to in scope, just what they refer
to.   But, I believe this is usually not a big factor in our discussions,
just though I'd mention it.

-Iavor




On Thu, May 24, 2018 at 3:23 AM Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Hi,
>
> alanasp has proposed a Deprecating Exports mechanism:
>
> https://github.com/alanasp/ghc-proposals/blob/patch-2/proposals/deprecating_exports_proposal.rst
>
> The gist is explained by this:
>
>    module Data.List
>    (  ...
>        {-# DEPRECATE lines "Exported from Data.String instead" #-}
>        , lines
>        ...t
>    ) where
>
> i.e. DEPRECATE pragmas in export lists cause warning when some other
> module uses the deprecated symbol when it is imported (only) via some
> deprecated export.
>
> This is a GSOC 2018 project, mentored by Matthew Pickering and Erik de
> Castro Lopo.
>
> The feature has a clear use-case, is self-contained and David Feuer
> (the containers maintainer) has already confirmed that there is a real
> demand for this. I suggest acceptance!
>
>
> As always, I will understand silence as tactic consensus.
>
> Cheers,
> Joachim
>
>
> --
> Joachim Breitner
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20180524/a684ddf4/attachment.html>

From mail at joachim-breitner.de  Thu May 24 17:35:47 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 24 May 2018 19:35:47 +0200
Subject: [ghc-steering-committee] Deprecating Exports (#134);
	Recommendation: accept
In-Reply-To: <CAGK9nuqnZ6AoS0hQKytX6qOQgC8B+1vcskSHjVJF9MGJY_kDzA@mail.gmail.com>
References: <4190e462230660bd0e95c781a5473bbd4dd47cbd.camel@joachim-breitner.de>
 <CAGK9nuqnZ6AoS0hQKytX6qOQgC8B+1vcskSHjVJF9MGJY_kDzA@mail.gmail.com>
Message-ID: <535267C4-4E81-4411-B4F7-801753F5E6B9@joachim-breitner.de>

Hi,

in fact, GHC knows how something is imported; it uses this information to report redundant imports. So I can optimistically hope that the implementation effort is reasonable.

Cheers,
Joachim


Am 24. Mai 2018 19:04:45 MESZ schrieb Iavor Diatchki <iavor.diatchki at gmail.com>:
>I have a bunch of question about this proposal, but I wrote them on the
>proposal discussion page, as this is what folks asked for, last time I
>had
>some questions.   I think answering them would make the proposal more
>clear.
>
>It seems to me that the use of this extension is somewhat limited, but
>it
>could be useful on occasion so I could take it or leave it.    It's
>been a
>while since I've looked at the GHC source, but I don't think that
>implementing this would be completely trivial, as I don't thing GHC
>currently cares about *how* names came to in scope, just what they
>refer
>to.   But, I believe this is usually not a big factor in our
>discussions,
>just though I'd mention it.
>
>-Iavor
>
>
>
>
>On Thu, May 24, 2018 at 3:23 AM Joachim Breitner
><mail at joachim-breitner.de>
>wrote:
>
>> Hi,
>>
>> alanasp has proposed a Deprecating Exports mechanism:
>>
>>
>https://github.com/alanasp/ghc-proposals/blob/patch-2/proposals/deprecating_exports_proposal.rst
>>
>> The gist is explained by this:
>>
>>    module Data.List
>>    (  ...
>>        {-# DEPRECATE lines "Exported from Data.String instead" #-}
>>        , lines
>>        ...t
>>    ) where
>>
>> i.e. DEPRECATE pragmas in export lists cause warning when some other
>> module uses the deprecated symbol when it is imported (only) via some
>> deprecated export.
>>
>> This is a GSOC 2018 project, mentored by Matthew Pickering and Erik
>de
>> Castro Lopo.
>>
>> The feature has a clear use-case, is self-contained and David Feuer
>> (the containers maintainer) has already confirmed that there is a
>real
>> demand for this. I suggest acceptance!
>>
>>
>> As always, I will understand silence as tactic consensus.
>>
>> Cheers,
>> Joachim
>>
>>
>> --
>> Joachim Breitner
>>   mail at joachim-breitner.de
>>   http://www.joachim-breitner.de/
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>>
>https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>

From iavor.diatchki at gmail.com  Thu May 24 17:47:57 2018
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Thu, 24 May 2018 10:47:57 -0700
Subject: [ghc-steering-committee] Deprecating Exports (#134);
 Recommendation: accept
In-Reply-To: <535267C4-4E81-4411-B4F7-801753F5E6B9@joachim-breitner.de>
References: <4190e462230660bd0e95c781a5473bbd4dd47cbd.camel@joachim-breitner.de>
 <CAGK9nuqnZ6AoS0hQKytX6qOQgC8B+1vcskSHjVJF9MGJY_kDzA@mail.gmail.com>
 <535267C4-4E81-4411-B4F7-801753F5E6B9@joachim-breitner.de>
Message-ID: <CAGK9nuovrzCmeoOF9Ao0iXiS_rEt7BZj9KNOT7UxHwr0UH5O-w@mail.gmail.com>

Aha, yes, I see that `GlobalRdrElement` has a list of imports that caused
it to come in scope.  I guess then the main change in types would be to
`IfaceExport`, which is currently just an `AvailInfo` to something that
would keep track of what's deprecated.  Seems doable.

On Thu, May 24, 2018 at 10:35 AM Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Hi,
>
> in fact, GHC knows how something is imported; it uses this information to
> report redundant imports. So I can optimistically hope that the
> implementation effort is reasonable.
>
> Cheers,
> Joachim
>
>
> Am 24. Mai 2018 19:04:45 MESZ schrieb Iavor Diatchki <
> iavor.diatchki at gmail.com>:
> >I have a bunch of question about this proposal, but I wrote them on the
> >proposal discussion page, as this is what folks asked for, last time I
> >had
> >some questions.   I think answering them would make the proposal more
> >clear.
> >
> >It seems to me that the use of this extension is somewhat limited, but
> >it
> >could be useful on occasion so I could take it or leave it.    It's
> >been a
> >while since I've looked at the GHC source, but I don't think that
> >implementing this would be completely trivial, as I don't thing GHC
> >currently cares about *how* names came to in scope, just what they
> >refer
> >to.   But, I believe this is usually not a big factor in our
> >discussions,
> >just though I'd mention it.
> >
> >-Iavor
> >
> >
> >
> >
> >On Thu, May 24, 2018 at 3:23 AM Joachim Breitner
> ><mail at joachim-breitner.de>
> >wrote:
> >
> >> Hi,
> >>
> >> alanasp has proposed a Deprecating Exports mechanism:
> >>
> >>
> >
> https://github.com/alanasp/ghc-proposals/blob/patch-2/proposals/deprecating_exports_proposal.rst
> >>
> >> The gist is explained by this:
> >>
> >>    module Data.List
> >>    (  ...
> >>        {-# DEPRECATE lines "Exported from Data.String instead" #-}
> >>        , lines
> >>        ...t
> >>    ) where
> >>
> >> i.e. DEPRECATE pragmas in export lists cause warning when some other
> >> module uses the deprecated symbol when it is imported (only) via some
> >> deprecated export.
> >>
> >> This is a GSOC 2018 project, mentored by Matthew Pickering and Erik
> >de
> >> Castro Lopo.
> >>
> >> The feature has a clear use-case, is self-contained and David Feuer
> >> (the containers maintainer) has already confirmed that there is a
> >real
> >> demand for this. I suggest acceptance!
> >>
> >>
> >> As always, I will understand silence as tactic consensus.
> >>
> >> Cheers,
> >> Joachim
> >>
> >>
> >> --
> >> Joachim Breitner
> >>   mail at joachim-breitner.de
> >>   http://www.joachim-breitner.de/
> >> _______________________________________________
> >> ghc-steering-committee mailing list
> >> ghc-steering-committee at haskell.org
> >>
> >https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> >>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20180524/b7b95e54/attachment.html>

From iavor.diatchki at gmail.com  Thu May 24 17:54:47 2018
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Thu, 24 May 2018 10:54:47 -0700
Subject: [ghc-steering-committee] Discussion on proposal #99: forall {k}
In-Reply-To: <12800fff0ea2e9fd819402bbaac2e31d7fbddf1d.camel@joachim-breitner.de>
References: <CAGK9nuqSLUuf6FuzDHhr0PofG=KpjRVGee0J_j2LU+p4kt76rg@mail.gmail.com>
 <AM5PR83MB01638A81718CBB12CA0BCE45AD810@AM5PR83MB0163.EURPRD83.prod.outlook.com>
 <CAGK9nuqEyHcrt9YZoMg+kawhNJ8jH7YFRyf1cJDNYyVgaMYsLw@mail.gmail.com>
 <7EB6937A-086F-415C-81DC-C44BCA716DFB@cs.brynmawr.edu>
 <ad6d92eb536d12c18fc79bdf27a16ecfa6b3f115.camel@joachim-breitner.de>
 <D79E106D-D788-4FEC-8388-A6EFDD6B7AF4@cs.brynmawr.edu>
 <41f153f3940391752bdddc40b07c54fdc23d6ee9.camel@joachim-breitner.de>
 <0BCE745C-7B82-4F25-9F86-3858398EA3C3@cs.brynmawr.edu>
 <12800fff0ea2e9fd819402bbaac2e31d7fbddf1d.camel@joachim-breitner.de>
Message-ID: <CAGK9nupt_1uc5V1pqeH69jRqoJZ74ojP=iLPg9VXy+r7f_r5FQ@mail.gmail.com>

Hello,

based on the discussion so far, it seems that #99 in its current form might
not be exactly what we want, so I'd say that we should reject it for the
moment.   Overall, I agree that it would be nice to come up with a
consistent notation for things that are currently happening in GHC but we
can't write, so perhaps we could revisit this with a revised proposal at a
later time?

-Iavor




On Sat, May 5, 2018 at 8:48 PM Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Hi,
>
> Am Mittwoch, den 02.05.2018, 16:10 -0400 schrieb Richard Eisenberg:
> > Joachim, you are always a fount of interesting ideas.
> >
> > > On May 2, 2018, at 2:51 PM, Joachim Breitner <mail at joachim-breitner
> > > .de> wrote:
> > >
> > >   class C k (a : k) where meth :: a
> > >   meth :: forall {k} a. C k a -> k -> Constraint
> >
> > I think this is brilliant. But not only for this proposal! Imagine
> > this:
> >
> > class Num a where
> >   fromInteger :: Integer -> a
> >
> > fromInteger :: Integer -> forall a. Num a => a
> >
> > If we do that, then #129 is essentially solved, at no further cost to
> > anyone. (Note that in all Haskell98-style code, no one will ever be
> > able to notice the changed type of fromInteger.)
> >
> > This approach also allows for the possibility of reordering
> > quantified type variables for Haskell98-style constructors, if anyone
> > should want to do it.
> >
> > And it allows for updated types (including quantified variable
> > ordering, etc.) for record selectors.
> >
> > And it allows (maybe?) for giving good types to GADT record
> > selectors:
> >
> > data X a where
> >   Foo :: { bar :: Int } -> X Int
> >   Quux :: { bar :: Bool } -> X Bool
> > bar :: X a -> a
> >
> > GHC currently rejects the declaration for X, but it could be accepted
> > if only we could specify the correct type of bar. And now we can. I
> > don't particularly want to cook up the typing rules here, but I don't
> > think I'm totally crazy.
> >
> > GADT record selectors aside, the rule for these could be that the
> > top-level type signature must be equivalent w.r.t. the subtype
> > relation with the original type signature. That is, if the new
> > signature is t1 and the old was t2, then t1 <: t2 and t2 <: t1. Easy
> > enough to check for. The implementation would probably do a little
> > worker/wrapper stunt.
>
> I smell a new proposal… what does this mean for #99? Will you want to
> revise it?
>
> Cheers,
> Joachim
> --
> Joachim Breitner
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20180524/e2ca2881/attachment-0001.html>

From marlowsd at gmail.com  Thu May 24 18:13:21 2018
From: marlowsd at gmail.com (Simon Marlow)
Date: Thu, 24 May 2018 19:13:21 +0100
Subject: [ghc-steering-committee] Deprecating Exports (#134);
 Recommendation: accept
In-Reply-To: <CAGK9nuqnZ6AoS0hQKytX6qOQgC8B+1vcskSHjVJF9MGJY_kDzA@mail.gmail.com>
References: <4190e462230660bd0e95c781a5473bbd4dd47cbd.camel@joachim-breitner.de>
 <CAGK9nuqnZ6AoS0hQKytX6qOQgC8B+1vcskSHjVJF9MGJY_kDzA@mail.gmail.com>
Message-ID: <CANsrgPJ27gVH27e3V_7_LS09-3KYRq8SPRkuALkuXk+nWpJ_2Q@mail.gmail.com>

I'm ok with acceptance (I recall this idea has come up several times in the
past, it's definitely useful sometimes). But I agree with Iavor that the
proposal needs some details to be nailed down.

Cheers
Simon

On 24 May 2018 at 18:04, Iavor Diatchki <iavor.diatchki at gmail.com> wrote:

> I have a bunch of question about this proposal, but I wrote them on the
> proposal discussion page, as this is what folks asked for, last time I had
> some questions.   I think answering them would make the proposal more
> clear.
>
> It seems to me that the use of this extension is somewhat limited, but it
> could be useful on occasion so I could take it or leave it.    It's been a
> while since I've looked at the GHC source, but I don't think that
> implementing this would be completely trivial, as I don't thing GHC
> currently cares about *how* names came to in scope, just what they refer
> to.   But, I believe this is usually not a big factor in our discussions,
> just though I'd mention it.
>
> -Iavor
>
>
>
>
> On Thu, May 24, 2018 at 3:23 AM Joachim Breitner <mail at joachim-breitner.de>
> wrote:
>
>> Hi,
>>
>> alanasp has proposed a Deprecating Exports mechanism:
>> https://github.com/alanasp/ghc-proposals/blob/patch-2/
>> proposals/deprecating_exports_proposal.rst
>>
>> The gist is explained by this:
>>
>>    module Data.List
>>    (  ...
>>        {-# DEPRECATE lines "Exported from Data.String instead" #-}
>>        , lines
>>        ...t
>>    ) where
>>
>> i.e. DEPRECATE pragmas in export lists cause warning when some other
>> module uses the deprecated symbol when it is imported (only) via some
>> deprecated export.
>>
>> This is a GSOC 2018 project, mentored by Matthew Pickering and Erik de
>> Castro Lopo.
>>
>> The feature has a clear use-case, is self-contained and David Feuer
>> (the containers maintainer) has already confirmed that there is a real
>> demand for this. I suggest acceptance!
>>
>>
>> As always, I will understand silence as tactic consensus.
>>
>> Cheers,
>> Joachim
>>
>>
>> --
>> Joachim Breitner
>>   mail at joachim-breitner.de
>>   http://www.joachim-breitner.de/
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
>
> _______________________________________________
> 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/20180524/9c748374/attachment.html>

From rae at cs.brynmawr.edu  Thu May 24 20:16:46 2018
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Thu, 24 May 2018 16:16:46 -0400
Subject: [ghc-steering-committee] Discussion on proposal #99: forall {k}
In-Reply-To: <CAGK9nupt_1uc5V1pqeH69jRqoJZ74ojP=iLPg9VXy+r7f_r5FQ@mail.gmail.com>
References: <CAGK9nuqSLUuf6FuzDHhr0PofG=KpjRVGee0J_j2LU+p4kt76rg@mail.gmail.com>
 <AM5PR83MB01638A81718CBB12CA0BCE45AD810@AM5PR83MB0163.EURPRD83.prod.outlook.com>
 <CAGK9nuqEyHcrt9YZoMg+kawhNJ8jH7YFRyf1cJDNYyVgaMYsLw@mail.gmail.com>
 <7EB6937A-086F-415C-81DC-C44BCA716DFB@cs.brynmawr.edu>
 <ad6d92eb536d12c18fc79bdf27a16ecfa6b3f115.camel@joachim-breitner.de>
 <D79E106D-D788-4FEC-8388-A6EFDD6B7AF4@cs.brynmawr.edu>
 <41f153f3940391752bdddc40b07c54fdc23d6ee9.camel@joachim-breitner.de>
 <0BCE745C-7B82-4F25-9F86-3858398EA3C3@cs.brynmawr.edu>
 <12800fff0ea2e9fd819402bbaac2e31d7fbddf1d.camel@joachim-breitner.de>
 <CAGK9nupt_1uc5V1pqeH69jRqoJZ74ojP=iLPg9VXy+r7f_r5FQ@mail.gmail.com>
Message-ID: <092EA358-6508-4942-A8AF-61E52A1342DB@cs.brynmawr.edu>

I do plan on turning Joachim's recent suggestion into a separate proposal, and then to modify #99. But the modification would remove only the bit about classes, not the feature overall. I don't have time to do this now, though -- will do next week.

Richard

> On May 24, 2018, at 1:54 PM, Iavor Diatchki <iavor.diatchki at gmail.com> wrote:
> 
> Hello,
> 
> based on the discussion so far, it seems that #99 in its current form might not be exactly what we want, so I'd say that we should reject it for the moment.   Overall, I agree that it would be nice to come up with a consistent notation for things that are currently happening in GHC but we can't write, so perhaps we could revisit this with a revised proposal at a later time?
> 
> -Iavor
> 
> 
> 
> 
> On Sat, May 5, 2018 at 8:48 PM Joachim Breitner <mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>> wrote:
> Hi,
> 
> Am Mittwoch, den 02.05.2018, 16:10 -0400 schrieb Richard Eisenberg:
> > Joachim, you are always a fount of interesting ideas.
> > 
> > > On May 2, 2018, at 2:51 PM, Joachim Breitner <mail at joachim-breitner
> > > .de> wrote:
> > > 
> > >   class C k (a : k) where meth :: a
> > >   meth :: forall {k} a. C k a -> k -> Constraint
> > 
> > I think this is brilliant. But not only for this proposal! Imagine
> > this:
> > 
> > class Num a where
> >   fromInteger :: Integer -> a
> > 
> > fromInteger :: Integer -> forall a. Num a => a
> > 
> > If we do that, then #129 is essentially solved, at no further cost to
> > anyone. (Note that in all Haskell98-style code, no one will ever be
> > able to notice the changed type of fromInteger.)
> > 
> > This approach also allows for the possibility of reordering
> > quantified type variables for Haskell98-style constructors, if anyone
> > should want to do it.
> > 
> > And it allows for updated types (including quantified variable
> > ordering, etc.) for record selectors.
> > 
> > And it allows (maybe?) for giving good types to GADT record
> > selectors:
> > 
> > data X a where
> >   Foo :: { bar :: Int } -> X Int
> >   Quux :: { bar :: Bool } -> X Bool
> > bar :: X a -> a
> > 
> > GHC currently rejects the declaration for X, but it could be accepted
> > if only we could specify the correct type of bar. And now we can. I
> > don't particularly want to cook up the typing rules here, but I don't
> > think I'm totally crazy.
> > 
> > GADT record selectors aside, the rule for these could be that the
> > top-level type signature must be equivalent w.r.t. the subtype
> > relation with the original type signature. That is, if the new
> > signature is t1 and the old was t2, then t1 <: t2 and t2 <: t1. Easy
> > enough to check for. The implementation would probably do a little
> > worker/wrapper stunt.
> 
> I smell a new proposal… what does this mean for #99? Will you want to
> revise it?
> 
> Cheers,
> Joachim
> -- 
> Joachim Breitner
>   mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>
>   http://www.joachim-breitner.de/ <http://www.joachim-breitner.de/>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> 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/20180524/25c6f819/attachment.html>

From simonpj at microsoft.com  Fri May 25 09:02:51 2018
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 25 May 2018 09:02:51 +0000
Subject: [ghc-steering-committee] Discussion on proposal #99: forall {k}
In-Reply-To: <092EA358-6508-4942-A8AF-61E52A1342DB@cs.brynmawr.edu>
References: <CAGK9nuqSLUuf6FuzDHhr0PofG=KpjRVGee0J_j2LU+p4kt76rg@mail.gmail.com>
 <AM5PR83MB01638A81718CBB12CA0BCE45AD810@AM5PR83MB0163.EURPRD83.prod.outlook.com>
 <CAGK9nuqEyHcrt9YZoMg+kawhNJ8jH7YFRyf1cJDNYyVgaMYsLw@mail.gmail.com>
 <7EB6937A-086F-415C-81DC-C44BCA716DFB@cs.brynmawr.edu>
 <ad6d92eb536d12c18fc79bdf27a16ecfa6b3f115.camel@joachim-breitner.de>
 <D79E106D-D788-4FEC-8388-A6EFDD6B7AF4@cs.brynmawr.edu>
 <41f153f3940391752bdddc40b07c54fdc23d6ee9.camel@joachim-breitner.de>
 <0BCE745C-7B82-4F25-9F86-3858398EA3C3@cs.brynmawr.edu>
 <12800fff0ea2e9fd819402bbaac2e31d7fbddf1d.camel@joachim-breitner.de>
 <CAGK9nupt_1uc5V1pqeH69jRqoJZ74ojP=iLPg9VXy+r7f_r5FQ@mail.gmail.com>
 <092EA358-6508-4942-A8AF-61E52A1342DB@cs.brynmawr.edu>
Message-ID: <AM5PR83MB01635CBB0899A45249AA73B4AD690@AM5PR83MB0163.EURPRD83.prod.outlook.com>

I’m keen to get #99 into GHC in some form.

My motivation (which could be a fourth bullet in the proposal) is that it should be possible for a programmer to write a fully-explicit type signature for anything GHC can infer.  But currently we can’t.  For typeRep1 GHC infers the signature shown for typeRep3; but we can’t write it down.

based on the discussion so far, it seems that #99 in its current form might not be exactly what we want

Can you summarise the reasons it might not be exactly what we want?

Simon

From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On Behalf Of Richard Eisenberg
Sent: 24 May 2018 21:17
To: Iavor Diatchki <iavor.diatchki at gmail.com>
Cc: ghc-steering-committee at haskell.org; Joachim Breitner <mail at joachim-breitner.de>
Subject: Re: [ghc-steering-committee] Discussion on proposal #99: forall {k}

I do plan on turning Joachim's recent suggestion into a separate proposal, and then to modify #99. But the modification would remove only the bit about classes, not the feature overall. I don't have time to do this now, though -- will do next week.

Richard


On May 24, 2018, at 1:54 PM, Iavor Diatchki <iavor.diatchki at gmail.com<mailto:iavor.diatchki at gmail.com>> wrote:

Hello,

based on the discussion so far, it seems that #99 in its current form might not be exactly what we want, so I'd say that we should reject it for the moment.   Overall, I agree that it would be nice to come up with a consistent notation for things that are currently happening in GHC but we can't write, so perhaps we could revisit this with a revised proposal at a later time?

-Iavor




On Sat, May 5, 2018 at 8:48 PM Joachim Breitner <mail at joachim-breitner.de<mailto:mail at joachim-breitner.de>> wrote:
Hi,

Am Mittwoch, den 02.05.2018, 16:10 -0400 schrieb Richard Eisenberg:
> Joachim, you are always a fount of interesting ideas.
>
> > On May 2, 2018, at 2:51 PM, Joachim Breitner <mail at joachim-breitner
> > .de> wrote:
> >
> >   class C k (a : k) where meth :: a
> >   meth :: forall {k} a. C k a -> k -> Constraint
>
> I think this is brilliant. But not only for this proposal! Imagine
> this:
>
> class Num a where
>   fromInteger :: Integer -> a
>
> fromInteger :: Integer -> forall a. Num a => a
>
> If we do that, then #129 is essentially solved, at no further cost to
> anyone. (Note that in all Haskell98-style code, no one will ever be
> able to notice the changed type of fromInteger.)
>
> This approach also allows for the possibility of reordering
> quantified type variables for Haskell98-style constructors, if anyone
> should want to do it.
>
> And it allows for updated types (including quantified variable
> ordering, etc.) for record selectors.
>
> And it allows (maybe?) for giving good types to GADT record
> selectors:
>
> data X a where
>   Foo :: { bar :: Int } -> X Int
>   Quux :: { bar :: Bool } -> X Bool
> bar :: X a -> a
>
> GHC currently rejects the declaration for X, but it could be accepted
> if only we could specify the correct type of bar. And now we can. I
> don't particularly want to cook up the typing rules here, but I don't
> think I'm totally crazy.
>
> GADT record selectors aside, the rule for these could be that the
> top-level type signature must be equivalent w.r.t. the subtype
> relation with the original type signature. That is, if the new
> signature is t1 and the old was t2, then t1 <: t2 and t2 <: t1. Easy
> enough to check for. The implementation would probably do a little
> worker/wrapper stunt.

I smell a new proposal… what does this mean for #99? Will you want to
revise it?

Cheers,
Joachim
--
Joachim Breitner
  mail at joachim-breitner.de<mailto:mail at joachim-breitner.de>
  http://www.joachim-breitner.de/<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Ca43c362fd18e4163aeba08d5c1b34be2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636627898179266033&sdata=1cwPEVKXCcP3DuCHXOFuA%2BbEBniRLjcKI%2BAZji5vR4Q%3D&reserved=0>
_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

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

From iavor.diatchki at gmail.com  Fri May 25 17:56:47 2018
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Fri, 25 May 2018 10:56:47 -0700
Subject: [ghc-steering-committee] Discussion on proposal #99: forall {k}
In-Reply-To: <AM5PR83MB01635CBB0899A45249AA73B4AD690@AM5PR83MB0163.EURPRD83.prod.outlook.com>
References: <CAGK9nuqSLUuf6FuzDHhr0PofG=KpjRVGee0J_j2LU+p4kt76rg@mail.gmail.com>
 <AM5PR83MB01638A81718CBB12CA0BCE45AD810@AM5PR83MB0163.EURPRD83.prod.outlook.com>
 <CAGK9nuqEyHcrt9YZoMg+kawhNJ8jH7YFRyf1cJDNYyVgaMYsLw@mail.gmail.com>
 <7EB6937A-086F-415C-81DC-C44BCA716DFB@cs.brynmawr.edu>
 <ad6d92eb536d12c18fc79bdf27a16ecfa6b3f115.camel@joachim-breitner.de>
 <D79E106D-D788-4FEC-8388-A6EFDD6B7AF4@cs.brynmawr.edu>
 <41f153f3940391752bdddc40b07c54fdc23d6ee9.camel@joachim-breitner.de>
 <0BCE745C-7B82-4F25-9F86-3858398EA3C3@cs.brynmawr.edu>
 <12800fff0ea2e9fd819402bbaac2e31d7fbddf1d.camel@joachim-breitner.de>
 <CAGK9nupt_1uc5V1pqeH69jRqoJZ74ojP=iLPg9VXy+r7f_r5FQ@mail.gmail.com>
 <092EA358-6508-4942-A8AF-61E52A1342DB@cs.brynmawr.edu>
 <AM5PR83MB01635CBB0899A45249AA73B4AD690@AM5PR83MB0163.EURPRD83.prod.outlook.com>
Message-ID: <CAGK9nur9HO1Avi52WbKUAk4yKfUJgVRh_0KrAfin+48ezZAa=g@mail.gmail.com>

Hello,

well, I thought that Richard was going to write a new proposal based on the
feedback here, but it sounds like he is planning to revise #99, and then
write a separate new one.    I guess we should discuss the proposal again
once the changes are in.   I would encourage Richard to add some text and
examples to clarify exactly what's in the proposal and what's not, and how
things are supposed to work.  Here are some examples, for which it would be
illuminating (to me) to see the types/kinds of all names introduced.

data T1 a = C1 a
data T2 (a :: k) = C2 { f2 :: Proxy a }
data T3 a where C3 :: forall k (a::k). Proxy a -> T3 a
data T4 a where C4 :: forall {k} (a::k). Proxy a -> T3 a
data T5 k a where C5 :: forall k (a::k). Proxy a -> T5 k a
data T6 k a where C6 :: forall {k} (a::k). Proxy a -> T6 k a

-Iavor


On Fri, May 25, 2018 at 2:02 AM Simon Peyton Jones <simonpj at microsoft.com>
wrote:

> I’m keen to get #99 into GHC in some form.
>
>
>
> My motivation (which could be a fourth bullet in the proposal) is that it
> should be possible for a programmer to write a fully-explicit type
> signature for anything GHC can infer.  But currently we can’t.  For
> typeRep1 GHC infers the signature shown for typeRep3; but we can’t write it
> down.
>
>
>
> based on the discussion so far, it seems that #99 in its current form
> might not be exactly what we want
>
>
>
> Can you summarise the reasons it might not be exactly what we want?
>
>
>
> Simon
>
>
>
> *From:* ghc-steering-committee <ghc-steering-committee-bounces at haskell.org>
> *On Behalf Of *Richard Eisenberg
> *Sent:* 24 May 2018 21:17
> *To:* Iavor Diatchki <iavor.diatchki at gmail.com>
> *Cc:* ghc-steering-committee at haskell.org; Joachim Breitner <
> mail at joachim-breitner.de>
> *Subject:* Re: [ghc-steering-committee] Discussion on proposal #99:
> forall {k}
>
>
>
> I do plan on turning Joachim's recent suggestion into a separate proposal,
> and then to modify #99. But the modification would remove only the bit
> about classes, not the feature overall. I don't have time to do this now,
> though -- will do next week.
>
>
>
> Richard
>
>
>
> On May 24, 2018, at 1:54 PM, Iavor Diatchki <iavor.diatchki at gmail.com>
> wrote:
>
>
>
> Hello,
>
>
>
> based on the discussion so far, it seems that #99 in its current form
> might not be exactly what we want, so I'd say that we should reject it for
> the moment.   Overall, I agree that it would be nice to come up with a
> consistent notation for things that are currently happening in GHC but we
> can't write, so perhaps we could revisit this with a revised proposal at a
> later time?
>
>
>
> -Iavor
>
>
>
>
>
>
>
>
>
> On Sat, May 5, 2018 at 8:48 PM Joachim Breitner <mail at joachim-breitner.de>
> wrote:
>
> Hi,
>
> Am Mittwoch, den 02.05.2018, 16:10 -0400 schrieb Richard Eisenberg:
> > Joachim, you are always a fount of interesting ideas.
> >
> > > On May 2, 2018, at 2:51 PM, Joachim Breitner <mail at joachim-breitner
> > > .de> wrote:
> > >
> > >   class C k (a : k) where meth :: a
> > >   meth :: forall {k} a. C k a -> k -> Constraint
> >
> > I think this is brilliant. But not only for this proposal! Imagine
> > this:
> >
> > class Num a where
> >   fromInteger :: Integer -> a
> >
> > fromInteger :: Integer -> forall a. Num a => a
> >
> > If we do that, then #129 is essentially solved, at no further cost to
> > anyone. (Note that in all Haskell98-style code, no one will ever be
> > able to notice the changed type of fromInteger.)
> >
> > This approach also allows for the possibility of reordering
> > quantified type variables for Haskell98-style constructors, if anyone
> > should want to do it.
> >
> > And it allows for updated types (including quantified variable
> > ordering, etc.) for record selectors.
> >
> > And it allows (maybe?) for giving good types to GADT record
> > selectors:
> >
> > data X a where
> >   Foo :: { bar :: Int } -> X Int
> >   Quux :: { bar :: Bool } -> X Bool
> > bar :: X a -> a
> >
> > GHC currently rejects the declaration for X, but it could be accepted
> > if only we could specify the correct type of bar. And now we can. I
> > don't particularly want to cook up the typing rules here, but I don't
> > think I'm totally crazy.
> >
> > GADT record selectors aside, the rule for these could be that the
> > top-level type signature must be equivalent w.r.t. the subtype
> > relation with the original type signature. That is, if the new
> > signature is t1 and the old was t2, then t1 <: t2 and t2 <: t1. Easy
> > enough to check for. The implementation would probably do a little
> > worker/wrapper stunt.
>
> I smell a new proposal… what does this mean for #99? Will you want to
> revise it?
>
> Cheers,
> Joachim
> --
> Joachim Breitner
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Ca43c362fd18e4163aeba08d5c1b34be2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636627898179266033&sdata=1cwPEVKXCcP3DuCHXOFuA%2BbEBniRLjcKI%2BAZji5vR4Q%3D&reserved=0>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20180525/2dd310be/attachment.html>

From rae at cs.brynmawr.edu  Tue May 29 19:59:11 2018
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Tue, 29 May 2018 15:59:11 -0400
Subject: [ghc-steering-committee] Need more Trac tickets
Message-ID: <249C4C71-370F-43C0-8CC9-36BD2799F07F@cs.brynmawr.edu>

Hi all,

Ryan Scott very helpfully this morning labeled the Trac tickets that have grown from proposals. However, there remain a good many proposals without corresponding Trac tickets.

I propose that we make it a shepherd's responsibility to make sure that a Trac ticket is created upon the acceptance of a proposal. Specifically: a shepherd should encourage the proposer to make the Trac ticket, and if this fails to happen, then for the shepherd to do it himself. (Why have the proposer do it? 1. To lessen the burden on the shepherd. 2. To subtly encourage the proposer to ponder the possibility of implementing.)

What do we think? We'll still have to make tickets for those accepted proposals but with not tickets...

Richard