From eric at seidel.io  Tue Aug  3 02:09:54 2021
From: eric at seidel.io (Eric Seidel)
Date: Mon, 02 Aug 2021 22:09:54 -0400
Subject: [ghc-steering-committee]
 =?utf-8?q?=23409=3A_Exportable_named_def?=
 =?utf-8?q?aults=2C_Recommendation=3A_Accept?=
In-Reply-To: <AM9PR83MB04818E9DD882DF19E0F0D80BAD159@AM9PR83MB0481.EURPRD83.prod.outlook.com>
References: <fc9e6b7d6e03228bf5a4badfb7748eee0c8b1b16.camel@joachim-breitner.de>
 <ddf47700-eb3c-4585-8291-4dad0d7e62a8@www.fastmail.com>
 <CAHnFXOuXc6K0ijRbRh+ZY8TkJToZ93Fur1=EOgfvPvWpP3GVGw@mail.gmail.com>
 <010f0179a51e4333-c762d7af-6f7e-4036-a04b-4ed60afd81ca-000000@us-east-2.amazonses.com>
 <1754f703-f87b-448b-bfd3-268226203b38@www.fastmail.com>
 <010f0179eca00f96-706787fc-ebda-4855-b38a-b7161d44f971-000000@us-east-2.amazonses.com>
 <77209cd3-2da0-4bda-8a09-a7870d7e9d22@www.fastmail.com>
 <CAH6fHQkhgd8Dz5nP6AkUzFnLNMFYdZMfnXLeEcfLztS+d5MeVw@mail.gmail.com>
 <7a913d64-b6a7-4d51-9b6c-7c6e9d2011d6@www.fastmail.com>
 <CAH6fHQ==r2iTfE7ZK3Yk_QDKXh4eMBzfdwTd_vWOM9ncGZW8yA@mail.gmail.com>
 <e427e7ad-1793-458b-a775-d3bc667e7071@www.fastmail.com>
 <5813a08c390adf628f215ee4ba3fd22ef5a77d51.camel@joachim-breitner.de>
 <010f017a5ac7ed07-92163998-1078-4d7c-85aa-a34e30335f99-000000@us-east-2.amazonses.com>
 <ce77c144-6c25-4dca-a7c6-6e46711c04af@www.fastmail.com>
 <a11afd53c242601f7e98c51c9fb352bd32fa2085.camel@joachim-breitner.de>
 <db2ca96c-dd32-49ad-b812-da27b5842a47@www.fastmail.com>
 <010f017a933fbbe9-f5144cde-aba7-4f6c-a2b9-3f3918c8c741-000000@us-east-2.amazonses.com>
 <AM9PR83MB04818E9DD882DF19E0F0D80BAD159@AM9PR83MB0481.EURPRD83.prod.outlook.com>
Message-ID: <8857909b-60e3-4bf9-84f0-aa5e2c54f07e@www.fastmail.com>

Committee,

Mario has updated the proposal following some discussion on GitHub around the question of implicit vs explicit export and import of default rules. The result is

1. *Implicit import*: any and all forms of `import M` also import any defaulting rules exported by M, like type classes.

2. *Explicit export*: defaulting rules must be explicitly exported like named things, mostly. The one exception is that 

    module M (module N) where { import N }

does not re-export any defaulting rules imported from N. Simon PJ argued strongly for this change on GitHub[1].

With that question settled, and with Simon and Richard's assent on GitHub, *I'd like to recommend that we accept the proposal*. However, I still do not see the need for a separate ImportedDefaults extension and would recommend that we enable the import behavior universally.

[1]: https://github.com/ghc-proposals/ghc-proposals/pull/409#issuecomment-882338794

On Mon, Jul 12, 2021, at 04:09, Simon Peyton Jones wrote:
>  
> I have added this as a comment in the GitHub repo, since others may 
> want to express an opinion
>  
> Simon
>  
> *From:* ghc-steering-committee 
> <ghc-steering-committee-bounces at haskell.org> *On Behalf Of *Richard 
> Eisenberg
> *Sent:* 11 July 2021 02:48
> *To:* Eric Seidel <eric at seidel.io>
> *Cc:* ghc-steering-committee at haskell.org
> *Subject:* Re: [ghc-steering-committee] #409: Exportable named 
> defaults, Recommendation: Partial Accept
>  
>  
> 
> 
> > On Jul 9, 2021, at 12:35 AM, Eric Seidel <eric at seidel.io> wrote:
> >  
> > On Thu, Jul 1, 2021, at 13:16, Joachim Breitner wrote:
> > 
> >> a different way to phrase that question might be: Do we want these
> >> defaulting declarations to behave just exactly like named things, or
> >> exactly like typeclass instances, or do we afford a new class with it’s
> >> own exporting/importing behavior. Is that a fair assessment?
> > 
> > Not entirely, I think. 
> > 
> > We currently have two types of import/export behavior:
> > named things, and typeclass instances. The proposal as currently
> > written places defaulting rules somewhere in between: defaulting
> > rules are exported like named things, but imported like class instances.
> > This is new, but not too foreign, as the behavior on both sides exactly
> > matches existing behavior we're familiar with. It's just the combination
> > that's new.
>  
> This doesn't match my understanding of the proposal. It looks to me 
> that, as written in the proposal, exports of a `default` would have to 
> be explicit. That is, a module starting with `module M where ...` would 
> not export any defaults. This fact is a bit implied in the proposal 
> ("This proposal does not modify that behaviour: a `default` declaration 
> by itself does not apply outside its module."), but it's my best 
> understanding. 
>  
> ---
>  
> Simon and I have discussed. We both came to an agreement that imports 
> should have to be explicit.
>  
> GHC currently has two import/export strategies.
>  
> Strategy 1: Always. In the Always strategy, an entity is always 
> exported from a module and always brought into scope from an imported 
> module. The Always strategy is used for type and class instances.
>  
> Strategy 2: Public. In the Public strategy, an entity is exported by 
> default (no export list) or when explicitly included in an export list. 
> It is brought into scope from an importing module by default (no import 
> list) or when explicitly included in an import list. A Public entity 
> may be excluded from scope by a `hiding` clause. All top-level named 
> entities are exported/imported via the Public strategy.
>  
> I propose (with Simon's support)
>  
> Strategy 3: Private. In the Private strategy. an entity is exported 
> only when explicitly included in an export list, and it is brought into 
> scope from an imported module only when explicitly included in the 
> import list. I propose we use Private for `default` declarations (only).
>  
> Reasons:
>  
> * Changing defaulting behavior really can launch the rockets. Suppose T 
> has a Num instance whose fromInteger uses unsafePerformIO to launch the 
> rockets. Then including T in an import list could make a very 
> innocent-looking `x = 5` declaration launch the rockets.
>  
> * GHC currently supports an option -ddump-minimal-imports, which 
> displays import lists describing what symbols must be brought into 
> scope from an imported module. If a `import M` import statement brought 
> defaulting behavior into scope, then going from `import M` to `import M 
> (foo, bar)` might deleteriously change defaulting behavior, thus 
> invalidating the work of -ddump-minimal-imports.
>  
> * The proposal as written does not describe how `module` exports work 
> with named defaults. For example, what happens in `module B (module A) 
> where import A`? Normally, that re-exports all names in scope both as 
> `A.blah` and as `blah`. But, of course, a default isn't named in this 
> way. So is the default exported? By requiring explicit inclusion in the 
> export list, the Private strategy sidesteps this question.
>  
> * This is a more conservative choice. We can always revisit this in the 
> light of experience. However, if defaults were always imported, it 
> would be much more disruptive to make them imported only by request.
>  
> We have rightly identified that using the Private strategy would 
> potentially reduce the usefulness of this idea, especially with 
> alternative Preludes. As far as I know, GHC does not currently 
> officially support having an alternative Prelude. That is, an 
> "alternative Prelude" is really just disabling the import of 
> base.Prelude and then importing some other module. However, we could 
> imagine a compiler flag that specifies another package (or module name) 
> to use as the Prelude... and then we could also specify how it is 
> imported. For example, we could say that the Prelude is imported with
>  
> > import Prelude
> > import Prelude ( default(..) )
>  
> where the second line says to grab all the defaults. I think this would 
> be reasonable, but not necessary in the first version of this current 
> proposal.
>  
> Richard

From arnaud.spiwack at tweag.io  Thu Aug  5 06:42:57 2021
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Thu, 5 Aug 2021 08:42:57 +0200
Subject: [ghc-steering-committee] #409: Exportable named defaults,
 Recommendation: Accept
In-Reply-To: <8857909b-60e3-4bf9-84f0-aa5e2c54f07e@www.fastmail.com>
References: <fc9e6b7d6e03228bf5a4badfb7748eee0c8b1b16.camel@joachim-breitner.de>
 <ddf47700-eb3c-4585-8291-4dad0d7e62a8@www.fastmail.com>
 <CAHnFXOuXc6K0ijRbRh+ZY8TkJToZ93Fur1=EOgfvPvWpP3GVGw@mail.gmail.com>
 <010f0179a51e4333-c762d7af-6f7e-4036-a04b-4ed60afd81ca-000000@us-east-2.amazonses.com>
 <1754f703-f87b-448b-bfd3-268226203b38@www.fastmail.com>
 <010f0179eca00f96-706787fc-ebda-4855-b38a-b7161d44f971-000000@us-east-2.amazonses.com>
 <77209cd3-2da0-4bda-8a09-a7870d7e9d22@www.fastmail.com>
 <CAH6fHQkhgd8Dz5nP6AkUzFnLNMFYdZMfnXLeEcfLztS+d5MeVw@mail.gmail.com>
 <7a913d64-b6a7-4d51-9b6c-7c6e9d2011d6@www.fastmail.com>
 <CAH6fHQ==r2iTfE7ZK3Yk_QDKXh4eMBzfdwTd_vWOM9ncGZW8yA@mail.gmail.com>
 <e427e7ad-1793-458b-a775-d3bc667e7071@www.fastmail.com>
 <5813a08c390adf628f215ee4ba3fd22ef5a77d51.camel@joachim-breitner.de>
 <010f017a5ac7ed07-92163998-1078-4d7c-85aa-a34e30335f99-000000@us-east-2.amazonses.com>
 <ce77c144-6c25-4dca-a7c6-6e46711c04af@www.fastmail.com>
 <a11afd53c242601f7e98c51c9fb352bd32fa2085.camel@joachim-breitner.de>
 <db2ca96c-dd32-49ad-b812-da27b5842a47@www.fastmail.com>
 <010f017a933fbbe9-f5144cde-aba7-4f6c-a2b9-3f3918c8c741-000000@us-east-2.amazonses.com>
 <AM9PR83MB04818E9DD882DF19E0F0D80BAD159@AM9PR83MB0481.EURPRD83.prod.outlook.com>
 <8857909b-60e3-4bf9-84f0-aa5e2c54f07e@www.fastmail.com>
Message-ID: <CAH6fHQmVOue6yvM9E2YknnBfJgVF0fuu1E8J+_EnXqA1rNH8Fg@mail.gmail.com>

I'm very supportive of this proposal. Thanks to everyone who participated
in the discussion. Like Eric, I don't see any value to the ImportedDefault
extension, and would rather we removed it.

On Tue, Aug 3, 2021 at 4:10 AM Eric Seidel <eric at seidel.io> wrote:

> Committee,
>
> Mario has updated the proposal following some discussion on GitHub around
> the question of implicit vs explicit export and import of default rules.
> The result is
>
> 1. *Implicit import*: any and all forms of `import M` also import any
> defaulting rules exported by M, like type classes.
>
> 2. *Explicit export*: defaulting rules must be explicitly exported like
> named things, mostly. The one exception is that
>
>     module M (module N) where { import N }
>
> does not re-export any defaulting rules imported from N. Simon PJ argued
> strongly for this change on GitHub[1].
>
> With that question settled, and with Simon and Richard's assent on GitHub,
> *I'd like to recommend that we accept the proposal*. However, I still do
> not see the need for a separate ImportedDefaults extension and would
> recommend that we enable the import behavior universally.
>
> [1]:
> https://github.com/ghc-proposals/ghc-proposals/pull/409#issuecomment-882338794
>
> On Mon, Jul 12, 2021, at 04:09, Simon Peyton Jones wrote:
> >
> > I have added this as a comment in the GitHub repo, since others may
> > want to express an opinion
> >
> > Simon
> >
> > *From:* ghc-steering-committee
> > <ghc-steering-committee-bounces at haskell.org> *On Behalf Of *Richard
> > Eisenberg
> > *Sent:* 11 July 2021 02:48
> > *To:* Eric Seidel <eric at seidel.io>
> > *Cc:* ghc-steering-committee at haskell.org
> > *Subject:* Re: [ghc-steering-committee] #409: Exportable named
> > defaults, Recommendation: Partial Accept
> >
> >
> >
> >
> > > On Jul 9, 2021, at 12:35 AM, Eric Seidel <eric at seidel.io> wrote:
> > >
> > > On Thu, Jul 1, 2021, at 13:16, Joachim Breitner wrote:
> > >
> > >> a different way to phrase that question might be: Do we want these
> > >> defaulting declarations to behave just exactly like named things, or
> > >> exactly like typeclass instances, or do we afford a new class with
> it’s
> > >> own exporting/importing behavior. Is that a fair assessment?
> > >
> > > Not entirely, I think.
> > >
> > > We currently have two types of import/export behavior:
> > > named things, and typeclass instances. The proposal as currently
> > > written places defaulting rules somewhere in between: defaulting
> > > rules are exported like named things, but imported like class
> instances.
> > > This is new, but not too foreign, as the behavior on both sides exactly
> > > matches existing behavior we're familiar with. It's just the
> combination
> > > that's new.
> >
> > This doesn't match my understanding of the proposal. It looks to me
> > that, as written in the proposal, exports of a `default` would have to
> > be explicit. That is, a module starting with `module M where ...` would
> > not export any defaults. This fact is a bit implied in the proposal
> > ("This proposal does not modify that behaviour: a `default` declaration
> > by itself does not apply outside its module."), but it's my best
> > understanding.
> >
> > ---
> >
> > Simon and I have discussed. We both came to an agreement that imports
> > should have to be explicit.
> >
> > GHC currently has two import/export strategies.
> >
> > Strategy 1: Always. In the Always strategy, an entity is always
> > exported from a module and always brought into scope from an imported
> > module. The Always strategy is used for type and class instances.
> >
> > Strategy 2: Public. In the Public strategy, an entity is exported by
> > default (no export list) or when explicitly included in an export list.
> > It is brought into scope from an importing module by default (no import
> > list) or when explicitly included in an import list. A Public entity
> > may be excluded from scope by a `hiding` clause. All top-level named
> > entities are exported/imported via the Public strategy.
> >
> > I propose (with Simon's support)
> >
> > Strategy 3: Private. In the Private strategy. an entity is exported
> > only when explicitly included in an export list, and it is brought into
> > scope from an imported module only when explicitly included in the
> > import list. I propose we use Private for `default` declarations (only).
> >
> > Reasons:
> >
> > * Changing defaulting behavior really can launch the rockets. Suppose T
> > has a Num instance whose fromInteger uses unsafePerformIO to launch the
> > rockets. Then including T in an import list could make a very
> > innocent-looking `x = 5` declaration launch the rockets.
> >
> > * GHC currently supports an option -ddump-minimal-imports, which
> > displays import lists describing what symbols must be brought into
> > scope from an imported module. If a `import M` import statement brought
> > defaulting behavior into scope, then going from `import M` to `import M
> > (foo, bar)` might deleteriously change defaulting behavior, thus
> > invalidating the work of -ddump-minimal-imports.
> >
> > * The proposal as written does not describe how `module` exports work
> > with named defaults. For example, what happens in `module B (module A)
> > where import A`? Normally, that re-exports all names in scope both as
> > `A.blah` and as `blah`. But, of course, a default isn't named in this
> > way. So is the default exported? By requiring explicit inclusion in the
> > export list, the Private strategy sidesteps this question.
> >
> > * This is a more conservative choice. We can always revisit this in the
> > light of experience. However, if defaults were always imported, it
> > would be much more disruptive to make them imported only by request.
> >
> > We have rightly identified that using the Private strategy would
> > potentially reduce the usefulness of this idea, especially with
> > alternative Preludes. As far as I know, GHC does not currently
> > officially support having an alternative Prelude. That is, an
> > "alternative Prelude" is really just disabling the import of
> > base.Prelude and then importing some other module. However, we could
> > imagine a compiler flag that specifies another package (or module name)
> > to use as the Prelude... and then we could also specify how it is
> > imported. For example, we could say that the Prelude is imported with
> >
> > > import Prelude
> > > import Prelude ( default(..) )
> >
> > where the second line says to grab all the defaults. I think this would
> > be reasonable, but not necessary in the first version of this current
> > proposal.
> >
> > Richard
> _______________________________________________
> 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/20210805/e051c6dd/attachment.html>

From mail at joachim-breitner.de  Fri Aug  6 15:11:40 2021
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Fri, 6 Aug 2021 15:11:40 +0000 (UTC)
Subject: [ghc-steering-committee] #409: Exportable named defaults,
 Recommendation: Accept
In-Reply-To: <CAH6fHQmVOue6yvM9E2YknnBfJgVF0fuu1E8J+_EnXqA1rNH8Fg@mail.gmail.com>
References: <ddf47700-eb3c-4585-8291-4dad0d7e62a8@www.fastmail.com>
 <CAHnFXOuXc6K0ijRbRh+ZY8TkJToZ93Fur1=EOgfvPvWpP3GVGw@mail.gmail.com>
 <010f0179a51e4333-c762d7af-6f7e-4036-a04b-4ed60afd81ca-000000@us-east-2.amazonses.com>
 <1754f703-f87b-448b-bfd3-268226203b38@www.fastmail.com>
 <010f0179eca00f96-706787fc-ebda-4855-b38a-b7161d44f971-000000@us-east-2.amazonses.com>
 <77209cd3-2da0-4bda-8a09-a7870d7e9d22@www.fastmail.com>
 <CAH6fHQkhgd8Dz5nP6AkUzFnLNMFYdZMfnXLeEcfLztS+d5MeVw@mail.gmail.com>
 <7a913d64-b6a7-4d51-9b6c-7c6e9d2011d6@www.fastmail.com>
 <CAH6fHQ==r2iTfE7ZK3Yk_QDKXh4eMBzfdwTd_vWOM9ncGZW8yA@mail.gmail.com>
 <e427e7ad-1793-458b-a775-d3bc667e7071@www.fastmail.com>
 <5813a08c390adf628f215ee4ba3fd22ef5a77d51.camel@joachim-breitner.de>
 <010f017a5ac7ed07-92163998-1078-4d7c-85aa-a34e30335f99-000000@us-east-2.amazonses.com>
 <ce77c144-6c25-4dca-a7c6-6e46711c04af@www.fastmail.com>
 <a11afd53c242601f7e98c51c9fb352bd32fa2085.camel@joachim-breitner.de>
 <db2ca96c-dd32-49ad-b812-da27b5842a47@www.f astmail.com>
 <010f017a933fbbe9-f5144cde-aba7-4f6c-a2b9-3f3918c8c741-000000@us-east-2.amazonses.com>
 <AM9PR83MB04818E9DD882DF19E0F0D80BAD159@AM9PR83MB0481.EURPRD83.prod.outlook.com>
 <8857909b-60e3-4bf9-84f0-aa5e2c54f07e@www.fastmail.com>
 <CAH6fHQmVOue6yvM9E2YknnBfJgVF0fuu1E8J+_EnXqA1rNH8Fg@mail.gmail.com>
Message-ID: <44d06e44-ff25-4e1c-b83d-55e38c4fbf7d@joachim-breitner.de>

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

From mail at joachim-breitner.de  Mon Aug  9 09:54:49 2021
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 09 Aug 2021 11:54:49 +0200
Subject: [ghc-steering-committee] Scoping of types
In-Reply-To: <CAHnFXOvj0njO=bPSD9RR4PxT+Sai4mOsW9=5k75MBxsK7jtJvg@mail.gmail.com>
References: <CAHnFXOuTyET6238R=2bXX=ew2t-3WESfYxgW0H8QdJjPLMe3qg@mail.gmail.com>
 <CAH6fHQnuop6w-tpS158jXVk8yFVDQKxWoNUnk1wsqD2=1-8GxQ@mail.gmail.com>
 <CAHnFXOvj0njO=bPSD9RR4PxT+Sai4mOsW9=5k75MBxsK7jtJvg@mail.gmail.com>
Message-ID: <3d7a61595cb3f600ff02bcefc1c7c2c00a2766d7.camel@joachim-breitner.de>

Hi,

I wasn’t technically asking you to shepherd it, merely to assign a
shephard and write the necessary mails and other red tape that I wasn’t
keen on doing on the phone while traveling. But now I have a proper
keyboard again, so I can do this. Or I can try…

There are three proposals in the air that are somewhat related, and
might be worth being shepherded together. We have done that before, and
it makes great sense. In fact, I would consider it within the powers of
a shepherd to take two related proposal and work them into one.

We have these proposals that related to “type variables and patterns”:
(summaries are mine and might be wrong)

#291: Simplify scoping for type applications in patterns

      This makes the “a” in a (Just @a _) pattern to always bind a new
      type variable, it is never an occurrence (as it would be under
      the accepted “#126 Type Varialbes in TPatterns”

#238: Introduce -XTypeAbstractions, limiting -XScopedTypeVariables 

      This refines/fixes “#155 Binding type variables in λ exprs”, 
      splits up ScopedTypeVariables, introduces a @(..) short-hand 
      (the dots are syntax, not metasyntax).

#420: no-implicit-binds: Adjust defaulting of -XPatternSignatureBinds 

      This modifies “#285 -XNoImplicitForAll, -
      XNoPatternSignatureBinds”, which itself partly breaks out
      existing behavior into two new extensions (ImplicitForAll,
      PatternSignatureBinds)

      Fun fact: #285 includes wording like “or, if #238 is accepted:”


So, if I see it correctly, we have _three_ accepted proposals related
to type variables (#126, #155, #285), which are all unimplemented. On
top of that, we have three open proposals modifying these… This is all
very confusing and doesn't feel quite effective to me. It’s not unusual
that proposals are accepted but don't get implemented for a while, but
it can be a sign that they are not quite right yet.

So I am almost of a mind to un-accept #126, #155, #285, and, together
with, #291, #238, #420 mark then at “needs unifiying revision”, and
asking the authors and all interested parties to come up with one (1)
unifying proposal that covers it all.

Well, maybe this is a bit too harsh, but in principle it seems more
productive to juggle this set of unimplemented proposals, proposal
modifying proposals and conditional proposals…

Or maybe all it needs is a single shepherd who is motivated to clear
this jungle for us.

What do you think, how should we proceed? Does anyone feel a calling to
guide this process to a conclusion?


Cheers,
Joachim

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



From simonpj at microsoft.com  Wed Aug 11 08:48:36 2021
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 11 Aug 2021 08:48:36 +0000
Subject: [ghc-steering-committee] Unlifted data types
Message-ID: <VI1PR83MB0269FC67F40ECAE0A2ED02FBADF89@VI1PR83MB0269.EURPRD83.prod.outlook.com>

I have just posted<https://github.com/ghc-proposals/ghc-proposals/pull/265#issuecomment-896626642> this, about unlifted data types.  Yikes!
Simon

In accepted proposal #265 on Unlifted Datatypes<https://github.com/ghc-proposals/ghc-proposals/pull/265>

I have just realised that in this accepted, and implemented proposal we have done something entirely new. Consider this (from https://gitlab.haskell.org/ghc/ghc/-/issues/20204)

type IntU ::  Bool -> Wombat



...LOTS OF CODE...



data IntU a b = IntU Int



...MORE CODE...



type Wombat =Type -> TYPE UnliftedRep

The kind signature for IntU completely changes the semantics of the data IntU declaration, and yet can be separate from it. That is new: generally, signatures can restrict the applicability of something, but don't change its semantics. (Yes, with overlapping instances, certainly incoherent instances, you could change semantics, but the general principal holds.)

Even if it is adjacent, the fact that it's unlifted is quite subtle... you have to look to the right of the arrows, and then through the distant (and perhaps imported) type synonym Wombat.

I'm not very happy with a distant kind signature having such a profound effect on the semantics of the data type. Indeed in my comment above<https://github.com/ghc-proposals/ghc-proposals/pull/265#issuecomment-525705557> I suggested a keyword

data unlifted IntU a b = IntU Int

to signal that it's an unlifted data type. But then I went AWOL and didn't pursue the matter. I don't know why I was so negligent.

So this post is to ask: does anyone else think this is bizarre? I'm inclined to make a proposal to add the keyword, but I thought I'd test the waters first.

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

From mail at joachim-breitner.de  Fri Aug 13 18:26:54 2021
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Fri, 13 Aug 2021 20:26:54 +0200
Subject: [ghc-steering-committee] Please review #425: Invisible binders in
 type declarations, Shepherd: Richard
Message-ID: <9d6b558172d6062bfb32477c297b24e45f9d66ca.camel@joachim-breitner.de>

Dear Committee,

this is your secretary speaking:

Invisible binders in type declarations
has been proposed by Vladislav
https://github.com/ghc-proposals/ghc-proposals/pull/425

https://github.com/serokell/ghc-proposals/blob/decl-invis-binders/proposals/0000-decl-invis-binders.rst

I propose Richard as the shepherd, simply because he already
scrutinized the proposal on Github.

Maybe that is a bit unfair: One could find it unfair towards other
committee members that they get fewer proposals assigned. Or unfair
towards Richard that he gets penalized for engaging with the community.
Up to your point of view. Best way to fix that would be if more
committee members are actively engaging with proposals even before they
are being submitted.

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

Thanks,
Joachim

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



From simonpj at microsoft.com  Sat Aug 14 15:40:02 2021
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Sat, 14 Aug 2021 15:40:02 +0000
Subject: [ghc-steering-committee] Scoping of types
In-Reply-To: <3d7a61595cb3f600ff02bcefc1c7c2c00a2766d7.camel@joachim-breitner.de>
References: <CAHnFXOuTyET6238R=2bXX=ew2t-3WESfYxgW0H8QdJjPLMe3qg@mail.gmail.com>
 <CAH6fHQnuop6w-tpS158jXVk8yFVDQKxWoNUnk1wsqD2=1-8GxQ@mail.gmail.com>
 <CAHnFXOvj0njO=bPSD9RR4PxT+Sai4mOsW9=5k75MBxsK7jtJvg@mail.gmail.com>
 <3d7a61595cb3f600ff02bcefc1c7c2c00a2766d7.camel@joachim-breitner.de>
Message-ID: <VI1PR83MB02694271E2D53AB177ACF533ADFB9@VI1PR83MB0269.EURPRD83.prod.outlook.com>

I spoke to Richard about this.  He is planning to respond to your call

|  What do you think, how should we proceed? Does anyone feel a calling to
|  guide this process to a conclusion?

Maybe his shepherding of #425 (invisible binders in type declarations)
is a good fit with that enterprise.

Thank you Richard!

Simon

|  -----Original Message-----
|  From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On
|  Behalf Of Joachim Breitner
|  Sent: 09 August 2021 10:55
|  To: ghc-steering-committee at haskell.org
|  Subject: Re: [ghc-steering-committee] Scoping of types
|  
|  Hi,
|  
|  I wasn't technically asking you to shepherd it, merely to assign a shephard
|  and write the necessary mails and other red tape that I wasn't keen on doing
|  on the phone while traveling. But now I have a proper keyboard again, so I
|  can do this. Or I can try.
|  
|  There are three proposals in the air that are somewhat related, and might be
|  worth being shepherded together. We have done that before, and it makes
|  great sense. In fact, I would consider it within the powers of a shepherd to
|  take two related proposal and work them into one.
|  
|  We have these proposals that related to "type variables and patterns":
|  (summaries are mine and might be wrong)
|  
|  #291: Simplify scoping for type applications in patterns
|  
|        This makes the "a" in a (Just @a _) pattern to always bind a new
|        type variable, it is never an occurrence (as it would be under
|        the accepted "#126 Type Varialbes in TPatterns"
|  
|  #238: Introduce -XTypeAbstractions, limiting -XScopedTypeVariables
|  
|        This refines/fixes "#155 Binding type variables in λ exprs",
|        splits up ScopedTypeVariables, introduces a @(..) short-hand
|        (the dots are syntax, not metasyntax).
|  
|  #420: no-implicit-binds: Adjust defaulting of -XPatternSignatureBinds
|  
|        This modifies "#285 -XNoImplicitForAll, -
|        XNoPatternSignatureBinds", which itself partly breaks out
|        existing behavior into two new extensions (ImplicitForAll,
|        PatternSignatureBinds)
|  
|        Fun fact: #285 includes wording like "or, if #238 is accepted:"
|  
|  
|  So, if I see it correctly, we have _three_ accepted proposals related to
|  type variables (#126, #155, #285), which are all unimplemented. On top of
|  that, we have three open proposals modifying these. This is all very
|  confusing and doesn't feel quite effective to me. It's not unusual that
|  proposals are accepted but don't get implemented for a while, but it can be
|  a sign that they are not quite right yet.
|  
|  So I am almost of a mind to un-accept #126, #155, #285, and, together with,
|  #291, #238, #420 mark then at "needs unifiying revision", and asking the
|  authors and all interested parties to come up with one (1) unifying proposal
|  that covers it all.
|  
|  Well, maybe this is a bit too harsh, but in principle it seems more
|  productive to juggle this set of unimplemented proposals, proposal modifying
|  proposals and conditional proposals.
|  
|  Or maybe all it needs is a single shepherd who is motivated to clear this
|  jungle for us.
|  
|  What do you think, how should we proceed? Does anyone feel a calling to
|  guide this process to a conclusion?
|  
|  
|  Cheers,
|  Joachim
|  
|  --
|  Joachim Breitner
|    mail at joachim-breitner.de
|  
|  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim
|  -
|  breitner.de%2F&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Cc73b2d6cfc814077
|  015d08d95b1bc947%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63764099718817
|  7261%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1
|  haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=nUxjVT1dUp8eizt7faWgnuF%2BWWPHj6e2Rug3K
|  d5usGU%3D&amp;reserved=0
|  
|  
|  _______________________________________________
|  ghc-steering-committee mailing list
|  ghc-steering-committee at haskell.org
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haske
|  ll.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
|  committee&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Cc73b2d6cfc814077015d0
|  8d95b1bc947%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637640997188177261%
|  7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi
|  LCJXVCI6Mn0%3D%7C1000&amp;sdata=BkvvfLPKEqhO24Q%2FLVJXnW2i%2F5YiesjTMcA6FXC2
|  zNI%3D&amp;reserved=0

From simonpj at microsoft.com  Sat Aug 14 15:40:53 2021
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Sat, 14 Aug 2021 15:40:53 +0000
Subject: [ghc-steering-committee] Please review #425: Invisible binders
 in type declarations, Shepherd: Richard
In-Reply-To: <9d6b558172d6062bfb32477c297b24e45f9d66ca.camel@joachim-breitner.de>
References: <9d6b558172d6062bfb32477c297b24e45f9d66ca.camel@joachim-breitner.de>
Message-ID: <VI1PR83MB026999E9DE6AAA29BBFC401FADFB9@VI1PR83MB0269.EURPRD83.prod.outlook.com>

I'm a big supporter of this proposal.  It fills out an important corner of GHC's design, and cleans up a couple of mis-features.

Simon

|  -----Original Message-----
|  From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On
|  Behalf Of Joachim Breitner
|  Sent: 13 August 2021 19:27
|  To: ghc-steering-committee at haskell.org
|  Subject: [ghc-steering-committee] Please review #425: Invisible binders in
|  type declarations, Shepherd: Richard
|  
|  Dear Committee,
|  
|  this is your secretary speaking:
|  
|  Invisible binders in type declarations
|  has been proposed by Vladislav
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com
|  %2Fghc-proposals%2Fghc-
|  proposals%2Fpull%2F425&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C5671f4de
|  1bf5451aaf9308d95e87ff72%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637644
|  760501359253%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJ
|  BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=QNAhYaueY8UcOdTDhG2GDw13K7F%2F1
|  5fIrW6kppM2%2FYc%3D&amp;reserved=0
|  
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com
|  %2Fserokell%2Fghc-proposals%2Fblob%2Fdecl-invis-binders%2Fproposals%2F0000-
|  decl-invis-
|  binders.rst&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C5671f4de1bf5451aaf9
|  308d95e87ff72%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63764476050136925
|  3%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haW
|  wiLCJXVCI6Mn0%3D%7C1000&amp;sdata=od3ToisQe2BKfSZp76pkW%2F2IvBrRsVyZ8vuw80on
|  S2Q%3D&amp;reserved=0
|  
|  I propose Richard as the shepherd, simply because he already scrutinized the
|  proposal on Github.
|  
|  Maybe that is a bit unfair: One could find it unfair towards other committee
|  members that they get fewer proposals assigned. Or unfair towards Richard
|  that he gets penalized for engaging with the community.
|  Up to your point of view. Best way to fix that would be if more committee
|  members are actively engaging with proposals even before they are being
|  submitted.
|  
|  Please guide us to a conclusion as outlined in
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com
|  %2Fghc-proposals%2Fghc-proposals%23committee-
|  process&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C5671f4de1bf5451aaf9308d
|  95e87ff72%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637644760501369253%7C
|  Unknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLC
|  JXVCI6Mn0%3D%7C1000&amp;sdata=T1orp07jrnmhysYLOdJkBMr6LsplTvreBFEZr%2BJSzsw%
|  3D&amp;reserved=0
|  
|  Thanks,
|  Joachim
|  
|  --
|  Joachim Breitner
|    mail at joachim-breitner.de
|  
|  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim
|  -
|  breitner.de%2F&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C5671f4de1bf5451a
|  af9308d95e87ff72%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63764476050136
|  9253%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1
|  haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=jSE8lx2MigdPN88%2BnvLCV7qacP6lQXimtR9pp
|  BhfwV0%3D&amp;reserved=0
|  
|  
|  _______________________________________________
|  ghc-steering-committee mailing list
|  ghc-steering-committee at haskell.org
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haske
|  ll.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
|  committee&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C5671f4de1bf5451aaf930
|  8d95e87ff72%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637644760501369253%
|  7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi
|  LCJXVCI6Mn0%3D%7C1000&amp;sdata=yDQB3aAPAQqy1KQYTNJ7g7fH4EJhxFGtt8Z7ijgpBAI%
|  3D&amp;reserved=0

From simonpj at microsoft.com  Sat Aug 14 17:57:49 2021
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Sat, 14 Aug 2021 17:57:49 +0000
Subject: [ghc-steering-committee] #409: Exportable named defaults,
 Recommendation: Accept
In-Reply-To: <CAH6fHQmVOue6yvM9E2YknnBfJgVF0fuu1E8J+_EnXqA1rNH8Fg@mail.gmail.com>
References: <fc9e6b7d6e03228bf5a4badfb7748eee0c8b1b16.camel@joachim-breitner.de>
 <ddf47700-eb3c-4585-8291-4dad0d7e62a8@www.fastmail.com>
 <CAHnFXOuXc6K0ijRbRh+ZY8TkJToZ93Fur1=EOgfvPvWpP3GVGw@mail.gmail.com>
 <010f0179a51e4333-c762d7af-6f7e-4036-a04b-4ed60afd81ca-000000@us-east-2.amazonses.com>
 <1754f703-f87b-448b-bfd3-268226203b38@www.fastmail.com>
 <010f0179eca00f96-706787fc-ebda-4855-b38a-b7161d44f971-000000@us-east-2.amazonses.com>
 <77209cd3-2da0-4bda-8a09-a7870d7e9d22@www.fastmail.com>
 <CAH6fHQkhgd8Dz5nP6AkUzFnLNMFYdZMfnXLeEcfLztS+d5MeVw@mail.gmail.com>
 <7a913d64-b6a7-4d51-9b6c-7c6e9d2011d6@www.fastmail.com>
 <CAH6fHQ==r2iTfE7ZK3Yk_QDKXh4eMBzfdwTd_vWOM9ncGZW8yA@mail.gmail.com>
 <e427e7ad-1793-458b-a775-d3bc667e7071@www.fastmail.com>
 <5813a08c390adf628f215ee4ba3fd22ef5a77d51.camel@joachim-breitner.de>
 <010f017a5ac7ed07-92163998-1078-4d7c-85aa-a34e30335f99-000000@us-east-2.amazonses.com>
 <ce77c144-6c25-4dca-a7c6-6e46711c04af@www.fastmail.com>
 <a11afd53c242601f7e98c51c9fb352bd32fa2085.camel@joachim-breitner.de>
 <db2ca96c-dd32-49ad-b812-da27b5842a47@www.fastmail.com>
 <010f017a933fbbe9-f5144cde-aba7-4f6c-a2b9-3f3918c8c741-000000@us-east-2.amazonses.com>
 <AM9PR83MB04818E9DD882DF19E0F0D80BAD159@AM9PR83MB0481.EURPRD83.prod.outlook.com>
 <8857909b-60e3-4bf9-84f0-aa5e2c54f07e@www.fastmail.com>
 <CAH6fHQmVOue6yvM9E2YknnBfJgVF0fuu1E8J+_EnXqA1rNH8Fg@mail.gmail.com>
Message-ID: <VI1PR83MB0269DB8E468F939EE67FD08AADFB9@VI1PR83MB0269.EURPRD83.prod.outlook.com>

Eric

I'm in support too - but I have added three small qns to the GitHub thread.

Simon

From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On Behalf Of Spiwack, Arnaud
Sent: 05 August 2021 07:43
To: Eric Seidel <eric at seidel.io>
Cc: ghc-steering-committee at haskell.org
Subject: Re: [ghc-steering-committee] #409: Exportable named defaults, Recommendation: Accept

I'm very supportive of this proposal. Thanks to everyone who participated in the discussion. Like Eric, I don't see any value to the ImportedDefault extension, and would rather we removed it.

On Tue, Aug 3, 2021 at 4:10 AM Eric Seidel <eric at seidel.io<mailto:eric at seidel.io>> wrote:
Committee,

Mario has updated the proposal following some discussion on GitHub around the question of implicit vs explicit export and import of default rules. The result is

1. *Implicit import*: any and all forms of `import M` also import any defaulting rules exported by M, like type classes.

2. *Explicit export*: defaulting rules must be explicitly exported like named things, mostly. The one exception is that

    module M (module N) where { import N }

does not re-export any defaulting rules imported from N. Simon PJ argued strongly for this change on GitHub[1].

With that question settled, and with Simon and Richard's assent on GitHub, *I'd like to recommend that we accept the proposal*. However, I still do not see the need for a separate ImportedDefaults extension and would recommend that we enable the import behavior universally.

[1]: https://github.com/ghc-proposals/ghc-proposals/pull/409#issuecomment-882338794<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F409%23issuecomment-882338794&data=04%7C01%7Csimonpj%40microsoft.com%7C4209473397bb4a1e123d08d957dc5f41%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637637426303882159%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=QimksAfoQFVo25E0UgtDwLiOUFKzUgl24h5P%2BvO26Oc%3D&reserved=0>

On Mon, Jul 12, 2021, at 04:09, Simon Peyton Jones wrote:
>
> I have added this as a comment in the GitHub repo, since others may
> want to express an opinion
>
> Simon
>
> *From:* ghc-steering-committee
> <ghc-steering-committee-bounces at haskell.org<mailto:ghc-steering-committee-bounces at haskell.org>> *On Behalf Of *Richard
> Eisenberg
> *Sent:* 11 July 2021 02:48
> *To:* Eric Seidel <eric at seidel.io<mailto:eric at seidel.io>>
> *Cc:* ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
> *Subject:* Re: [ghc-steering-committee] #409: Exportable named
> defaults, Recommendation: Partial Accept
>
>
>
>
> > On Jul 9, 2021, at 12:35 AM, Eric Seidel <eric at seidel.io<mailto:eric at seidel.io>> wrote:
> >
> > On Thu, Jul 1, 2021, at 13:16, Joachim Breitner wrote:
> >
> >> a different way to phrase that question might be: Do we want these
> >> defaulting declarations to behave just exactly like named things, or
> >> exactly like typeclass instances, or do we afford a new class with it's
> >> own exporting/importing behavior. Is that a fair assessment?
> >
> > Not entirely, I think.
> >
> > We currently have two types of import/export behavior:
> > named things, and typeclass instances. The proposal as currently
> > written places defaulting rules somewhere in between: defaulting
> > rules are exported like named things, but imported like class instances.
> > This is new, but not too foreign, as the behavior on both sides exactly
> > matches existing behavior we're familiar with. It's just the combination
> > that's new.
>
> This doesn't match my understanding of the proposal. It looks to me
> that, as written in the proposal, exports of a `default` would have to
> be explicit. That is, a module starting with `module M where ...` would
> not export any defaults. This fact is a bit implied in the proposal
> ("This proposal does not modify that behaviour: a `default` declaration
> by itself does not apply outside its module."), but it's my best
> understanding.
>
> ---
>
> Simon and I have discussed. We both came to an agreement that imports
> should have to be explicit.
>
> GHC currently has two import/export strategies.
>
> Strategy 1: Always. In the Always strategy, an entity is always
> exported from a module and always brought into scope from an imported
> module. The Always strategy is used for type and class instances.
>
> Strategy 2: Public. In the Public strategy, an entity is exported by
> default (no export list) or when explicitly included in an export list.
> It is brought into scope from an importing module by default (no import
> list) or when explicitly included in an import list. A Public entity
> may be excluded from scope by a `hiding` clause. All top-level named
> entities are exported/imported via the Public strategy.
>
> I propose (with Simon's support)
>
> Strategy 3: Private. In the Private strategy. an entity is exported
> only when explicitly included in an export list, and it is brought into
> scope from an imported module only when explicitly included in the
> import list. I propose we use Private for `default` declarations (only).
>
> Reasons:
>
> * Changing defaulting behavior really can launch the rockets. Suppose T
> has a Num instance whose fromInteger uses unsafePerformIO to launch the
> rockets. Then including T in an import list could make a very
> innocent-looking `x = 5` declaration launch the rockets.
>
> * GHC currently supports an option -ddump-minimal-imports, which
> displays import lists describing what symbols must be brought into
> scope from an imported module. If a `import M` import statement brought
> defaulting behavior into scope, then going from `import M` to `import M
> (foo, bar)` might deleteriously change defaulting behavior, thus
> invalidating the work of -ddump-minimal-imports.
>
> * The proposal as written does not describe how `module` exports work
> with named defaults. For example, what happens in `module B (module A)
> where import A`? Normally, that re-exports all names in scope both as
> `A.blah` and as `blah`. But, of course, a default isn't named in this
> way. So is the default exported? By requiring explicit inclusion in the
> export list, the Private strategy sidesteps this question.
>
> * This is a more conservative choice. We can always revisit this in the
> light of experience. However, if defaults were always imported, it
> would be much more disruptive to make them imported only by request.
>
> We have rightly identified that using the Private strategy would
> potentially reduce the usefulness of this idea, especially with
> alternative Preludes. As far as I know, GHC does not currently
> officially support having an alternative Prelude. That is, an
> "alternative Prelude" is really just disabling the import of
> base.Prelude and then importing some other module. However, we could
> imagine a compiler flag that specifies another package (or module name)
> to use as the Prelude... and then we could also specify how it is
> imported. For example, we could say that the Prelude is imported with
>
> > import Prelude
> > import Prelude ( default(..) )
>
> where the second line says to grab all the defaults. I think this would
> be reasonable, but not necessary in the first version of this current
> proposal.
>
> Richard
_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7C4209473397bb4a1e123d08d957dc5f41%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637637426303892149%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=UhgwhcfU2P5%2BBwQX0lokFK8wIlFnW5RC%2BdSCg24oSzE%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210814/7a512014/attachment-0001.html>

From rae at richarde.dev  Sun Aug 15 14:38:45 2021
From: rae at richarde.dev (Richard Eisenberg)
Date: Sun, 15 Aug 2021 14:38:45 +0000
Subject: [ghc-steering-committee] Scoping of types
In-Reply-To: <VI1PR83MB02694271E2D53AB177ACF533ADFB9@VI1PR83MB0269.EURPRD83.prod.outlook.com>
References: <CAHnFXOuTyET6238R=2bXX=ew2t-3WESfYxgW0H8QdJjPLMe3qg@mail.gmail.com>
 <CAH6fHQnuop6w-tpS158jXVk8yFVDQKxWoNUnk1wsqD2=1-8GxQ@mail.gmail.com>
 <CAHnFXOvj0njO=bPSD9RR4PxT+Sai4mOsW9=5k75MBxsK7jtJvg@mail.gmail.com>
 <3d7a61595cb3f600ff02bcefc1c7c2c00a2766d7.camel@joachim-breitner.de>
 <VI1PR83MB02694271E2D53AB177ACF533ADFB9@VI1PR83MB0269.EURPRD83.prod.outlook.com>
Message-ID: <010f017b4a402f63-2931300a-d31c-4dde-85ac-d52bbd6d8bbc-000000@us-east-2.amazonses.com>

Yes, indeed. Time is remarkably squeezed for me right now (which is why I'm working on a Sunday morning). Don't expect any action here before September. But I plan to synthesize this little bundle of proposals into something coherent soon. I don't expect any real changes over what's currently proposed -- just a more coherent & unified presentation, accompanied by typing rules.

Richard

> On Aug 14, 2021, at 11:40 AM, Simon Peyton Jones <simonpj at microsoft.com> wrote:
> 
> I spoke to Richard about this.  He is planning to respond to your call
> 
> |  What do you think, how should we proceed? Does anyone feel a calling to
> |  guide this process to a conclusion?
> 
> Maybe his shepherding of #425 (invisible binders in type declarations)
> is a good fit with that enterprise.
> 
> Thank you Richard!
> 
> Simon
> 
> |  -----Original Message-----
> |  From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On
> |  Behalf Of Joachim Breitner
> |  Sent: 09 August 2021 10:55
> |  To: ghc-steering-committee at haskell.org
> |  Subject: Re: [ghc-steering-committee] Scoping of types
> |  
> |  Hi,
> |  
> |  I wasn't technically asking you to shepherd it, merely to assign a shephard
> |  and write the necessary mails and other red tape that I wasn't keen on doing
> |  on the phone while traveling. But now I have a proper keyboard again, so I
> |  can do this. Or I can try.
> |  
> |  There are three proposals in the air that are somewhat related, and might be
> |  worth being shepherded together. We have done that before, and it makes
> |  great sense. In fact, I would consider it within the powers of a shepherd to
> |  take two related proposal and work them into one.
> |  
> |  We have these proposals that related to "type variables and patterns":
> |  (summaries are mine and might be wrong)
> |  
> |  #291: Simplify scoping for type applications in patterns
> |  
> |        This makes the "a" in a (Just @a _) pattern to always bind a new
> |        type variable, it is never an occurrence (as it would be under
> |        the accepted "#126 Type Varialbes in TPatterns"
> |  
> |  #238: Introduce -XTypeAbstractions, limiting -XScopedTypeVariables
> |  
> |        This refines/fixes "#155 Binding type variables in λ exprs",
> |        splits up ScopedTypeVariables, introduces a @(..) short-hand
> |        (the dots are syntax, not metasyntax).
> |  
> |  #420: no-implicit-binds: Adjust defaulting of -XPatternSignatureBinds
> |  
> |        This modifies "#285 -XNoImplicitForAll, -
> |        XNoPatternSignatureBinds", which itself partly breaks out
> |        existing behavior into two new extensions (ImplicitForAll,
> |        PatternSignatureBinds)
> |  
> |        Fun fact: #285 includes wording like "or, if #238 is accepted:"
> |  
> |  
> |  So, if I see it correctly, we have _three_ accepted proposals related to
> |  type variables (#126, #155, #285), which are all unimplemented. On top of
> |  that, we have three open proposals modifying these. This is all very
> |  confusing and doesn't feel quite effective to me. It's not unusual that
> |  proposals are accepted but don't get implemented for a while, but it can be
> |  a sign that they are not quite right yet.
> |  
> |  So I am almost of a mind to un-accept #126, #155, #285, and, together with,
> |  #291, #238, #420 mark then at "needs unifiying revision", and asking the
> |  authors and all interested parties to come up with one (1) unifying proposal
> |  that covers it all.
> |  
> |  Well, maybe this is a bit too harsh, but in principle it seems more
> |  productive to juggle this set of unimplemented proposals, proposal modifying
> |  proposals and conditional proposals.
> |  
> |  Or maybe all it needs is a single shepherd who is motivated to clear this
> |  jungle for us.
> |  
> |  What do you think, how should we proceed? Does anyone feel a calling to
> |  guide this process to a conclusion?
> |  
> |  
> |  Cheers,
> |  Joachim
> |  
> |  --
> |  Joachim Breitner
> |    mail at joachim-breitner.de
> |  
> |  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim
> |  -
> |  breitner.de%2F&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Cc73b2d6cfc814077
> |  015d08d95b1bc947%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63764099718817
> |  7261%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1
> |  haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=nUxjVT1dUp8eizt7faWgnuF%2BWWPHj6e2Rug3K
> |  d5usGU%3D&amp;reserved=0
> |  
> |  
> |  _______________________________________________
> |  ghc-steering-committee mailing list
> |  ghc-steering-committee at haskell.org
> |  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haske
> |  ll.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
> |  committee&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Cc73b2d6cfc814077015d0
> |  8d95b1bc947%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637640997188177261%
> |  7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi
> |  LCJXVCI6Mn0%3D%7C1000&amp;sdata=BkvvfLPKEqhO24Q%2FLVJXnW2i%2F5YiesjTMcA6FXC2
> |  zNI%3D&amp;reserved=0


From mail at joachim-breitner.de  Sun Aug 15 20:58:57 2021
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sun, 15 Aug 2021 22:58:57 +0200
Subject: [ghc-steering-committee] Scoping of types
In-Reply-To: <010f017b4a402f63-2931300a-d31c-4dde-85ac-d52bbd6d8bbc-000000@us-east-2.amazonses.com>
References: <CAHnFXOuTyET6238R=2bXX=ew2t-3WESfYxgW0H8QdJjPLMe3qg@mail.gmail.com>
 <CAH6fHQnuop6w-tpS158jXVk8yFVDQKxWoNUnk1wsqD2=1-8GxQ@mail.gmail.com>
 <CAHnFXOvj0njO=bPSD9RR4PxT+Sai4mOsW9=5k75MBxsK7jtJvg@mail.gmail.com>
 <3d7a61595cb3f600ff02bcefc1c7c2c00a2766d7.camel@joachim-breitner.de>
 <VI1PR83MB02694271E2D53AB177ACF533ADFB9@VI1PR83MB0269.EURPRD83.prod.outlook.com>
 <010f017b4a402f63-2931300a-d31c-4dde-85ac-d52bbd6d8bbc-000000@us-east-2.amazonses.com>
Message-ID: <b1f5a282b8e4ce1fd29b8d4f10ceb8f3187a645f.camel@joachim-breitner.de>

Hi,

thanks!

At the risk of sounding like a broken record: One thing that I found
missing in the proposals so far (but maybe I just didn’t see it) is a
good idea of very obviously (convenient and easy to spot syntax) and in
a unifying way (types and terms the same way – of course!)
distinguishing between occurrences and binders of variables in a
pattern.

Binders? Of course the main thing on a pattern.
Occurrences in types? Also not unheard of; was a big part of #126.
Occurrences in terms? Sounds odd, but I believe that not having a good
syntax for that is one of the main reasons we currently can’t abstract
pattern synonyms over terms, but that such abstraction is useful and
will eventually come, and it would be great to already now use a syntax
on the type level that we can use on the terms level as well. (After
all, we want to get rid of the syntactic levels.)

Given that ocurrences are the rarer case (both in terms and types),
maybe a simple “marker” would work? But I have no obviously compelling
solution to offer.

With that wish list item voiced, I am looking forward to your proposal
:-)

Cheers,
Joachim


Am Sonntag, dem 15.08.2021 um 14:38 +0000 schrieb Richard Eisenberg:
> Yes, indeed. Time is remarkably squeezed for me right now (which is why I'm working on a Sunday morning). Don't expect any action here before September. But I plan to synthesize this little bundle of proposals into something coherent soon. I don't expect any real changes over what's currently proposed -- just a more coherent & unified presentation, accompanied by typing rules.
> 
> Richard
> 
> > On Aug 14, 2021, at 11:40 AM, Simon Peyton Jones <simonpj at microsoft.com> wrote:
> > 
> > I spoke to Richard about this.  He is planning to respond to your call
> > 
> > >  What do you think, how should we proceed? Does anyone feel a calling to
> > >  guide this process to a conclusion?
> > 
> > Maybe his shepherding of #425 (invisible binders in type declarations)
> > is a good fit with that enterprise.
> > 
> > Thank you Richard!
> > 
> > Simon
> > 
> > >  -----Original Message-----
> > >  From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On
> > >  Behalf Of Joachim Breitner
> > >  Sent: 09 August 2021 10:55
> > >  To: ghc-steering-committee at haskell.org
> > >  Subject: Re: [ghc-steering-committee] Scoping of types
> > >  
> > >  Hi,
> > >  
> > >  I wasn't technically asking you to shepherd it, merely to assign a shephard
> > >  and write the necessary mails and other red tape that I wasn't keen on doing
> > >  on the phone while traveling. But now I have a proper keyboard again, so I
> > >  can do this. Or I can try.
> > >  
> > >  There are three proposals in the air that are somewhat related, and might be
> > >  worth being shepherded together. We have done that before, and it makes
> > >  great sense. In fact, I would consider it within the powers of a shepherd to
> > >  take two related proposal and work them into one.
> > >  
> > >  We have these proposals that related to "type variables and patterns":
> > >  (summaries are mine and might be wrong)
> > >  
> > >  #291: Simplify scoping for type applications in patterns
> > >  
> > >        This makes the "a" in a (Just @a _) pattern to always bind a new
> > >        type variable, it is never an occurrence (as it would be under
> > >        the accepted "#126 Type Varialbes in TPatterns"
> > >  
> > >  #238: Introduce -XTypeAbstractions, limiting -XScopedTypeVariables
> > >  
> > >        This refines/fixes "#155 Binding type variables in λ exprs",
> > >        splits up ScopedTypeVariables, introduces a @(..) short-hand
> > >        (the dots are syntax, not metasyntax).
> > >  
> > >  #420: no-implicit-binds: Adjust defaulting of -XPatternSignatureBinds
> > >  
> > >        This modifies "#285 -XNoImplicitForAll, -
> > >        XNoPatternSignatureBinds", which itself partly breaks out
> > >        existing behavior into two new extensions (ImplicitForAll,
> > >        PatternSignatureBinds)
> > >  
> > >        Fun fact: #285 includes wording like "or, if #238 is accepted:"
> > >  
> > >  
> > >  So, if I see it correctly, we have _three_ accepted proposals related to
> > >  type variables (#126, #155, #285), which are all unimplemented. On top of
> > >  that, we have three open proposals modifying these. This is all very
> > >  confusing and doesn't feel quite effective to me. It's not unusual that
> > >  proposals are accepted but don't get implemented for a while, but it can be
> > >  a sign that they are not quite right yet.
> > >  
> > >  So I am almost of a mind to un-accept #126, #155, #285, and, together with,
> > >  #291, #238, #420 mark then at "needs unifiying revision", and asking the
> > >  authors and all interested parties to come up with one (1) unifying proposal
> > >  that covers it all.
> > >  
> > >  Well, maybe this is a bit too harsh, but in principle it seems more
> > >  productive to juggle this set of unimplemented proposals, proposal modifying
> > >  proposals and conditional proposals.
> > >  
> > >  Or maybe all it needs is a single shepherd who is motivated to clear this
> > >  jungle for us.
> > >  
> > >  What do you think, how should we proceed? Does anyone feel a calling to
> > >  guide this process to a conclusion?
> > >  
> > >  
> > >  Cheers,
> > >  Joachim
> > >  
> > >  --
> > >  Joachim Breitner
> > >    mail at joachim-breitner.de
> > >  
> > >  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim
> > >  -
> > >  breitner.de%2F&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Cc73b2d6cfc814077
> > >  015d08d95b1bc947%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63764099718817
> > >  7261%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1
> > >  haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=nUxjVT1dUp8eizt7faWgnuF%2BWWPHj6e2Rug3K
> > >  d5usGU%3D&amp;reserved=0
> > >  
> > >  
> > >  _______________________________________________
> > >  ghc-steering-committee mailing list
> > >  ghc-steering-committee at haskell.org
> > >  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haske
> > >  ll.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
> > >  committee&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Cc73b2d6cfc814077015d0
> > >  8d95b1bc947%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637640997188177261%
> > >  7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi
> > >  LCJXVCI6Mn0%3D%7C1000&amp;sdata=BkvvfLPKEqhO24Q%2FLVJXnW2i%2F5YiesjTMcA6FXC2
> > >  zNI%3D&amp;reserved=0
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

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



From eric at seidel.io  Wed Aug 18 02:57:07 2021
From: eric at seidel.io (Eric Seidel)
Date: Tue, 17 Aug 2021 21:57:07 -0500
Subject: [ghc-steering-committee] Unlifted data types
In-Reply-To: <VI1PR83MB0269FC67F40ECAE0A2ED02FBADF89@VI1PR83MB0269.EURPRD83.prod.outlook.com>
References: <VI1PR83MB0269FC67F40ECAE0A2ED02FBADF89@VI1PR83MB0269.EURPRD83.prod.outlook.com>
Message-ID: <7f0297ed-3df1-4547-8837-a3e7235ca6a5@www.fastmail.com>

I think the distance between the `type IntU` and `data IntU` is the crux of the issue. If we were forced to keep the signature and declaration together, i.e.

```
type IntU :: Bool -> Wombat
data IntU a b = IntU Int
```

I wouldn't be bothered by the distance from the definition of `Wombat`.

If I'm reading this code, and I already know what Wombat is, there's no problem. If I *don't* know what Wombat is, then I need to look up its definition anyway to make sense of IntU.

I've never been particularly fond of Haskell's tolerance for separating signatures and definitions. It has some practical uses -- notably in combination with -XCPP it makes it easy to ensure signatures are consistent across CPP branches -- but in general I think distance between signature and definition is a smell.

On Wed, Aug 11, 2021, at 03:48, Simon Peyton Jones via ghc-steering-committee wrote:
>  
> I have just posted 
> <https://github.com/ghc-proposals/ghc-proposals/pull/265#issuecomment-896626642> this, about unlifted data types.  Yikes!  
> Simon
>  
> *In accepted proposal #265 on Unlifted Datatypes 
> <https://github.com/ghc-proposals/ghc-proposals/pull/265>*
> I have just realised that in this accepted, and implemented proposal we 
> have done something entirely new. Consider this (from 
> https://gitlab.haskell.org/ghc/ghc/-/issues/20204)
> 
> `type IntU ::  Bool -> Wombat` ` ` `...LOTS OF CODE...` ` ` `data IntU 
> a b = IntU Int` ` ` `...MORE CODE...` ` ` `type Wombat =Type -> TYPE 
> UnliftedRep` 
> The kind signature for `IntU` *completely changes the semantics of the 
> *`*data IntU*`* declaration*, and yet can be separate from it. That is 
> new: generally, signatures can restrict the applicability of something, 
> but *don't change its semantics*. (Yes, with overlapping instances, 
> certainly incoherent instances, you could change semantics, but the 
> general principal holds.)
> 
> Even if it is adjacent, the fact that it's unlifted is quite subtle... 
> you have to look to the right of the arrows, and then through the 
> distant (and perhaps imported) type synonym `Wombat`.
> 
> I'm not very happy with a distant kind signature having such a profound 
> effect on the semantics of the data type. Indeed in my comment above 
> <https://github.com/ghc-proposals/ghc-proposals/pull/265#issuecomment-525705557> I suggested a keyword
> 
> `data unlifted IntU a b = IntU Int` 
> to signal that it's an *unlifted* data type. But then I went AWOL and 
> didn't pursue the matter. I don't know why I was so negligent.
> 
> So this post is to ask: does anyone else think this is bizarre? I'm 
> inclined to make a proposal to add the keyword, but I thought I'd test 
> the waters first.
> 
>  
> _______________________________________________
> 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  Wed Aug 18 08:32:40 2021
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 18 Aug 2021 08:32:40 +0000
Subject: [ghc-steering-committee] Unlifted data types
In-Reply-To: <7f0297ed-3df1-4547-8837-a3e7235ca6a5@www.fastmail.com>
References: <VI1PR83MB0269FC67F40ECAE0A2ED02FBADF89@VI1PR83MB0269.EURPRD83.prod.outlook.com>
 <7f0297ed-3df1-4547-8837-a3e7235ca6a5@www.fastmail.com>
Message-ID: <VI1PR83MB0269D7707A65D963425B7D36ADFF9@VI1PR83MB0269.EURPRD83.prod.outlook.com>

I'm bothered both by distance, and the hidden-ness of Wombat, and (most fundamentally) by the fact that the data type declaration itself is not self-describing.  Usually if I look at a type signature for a function and don't really understand it, I can rely on the type checker to ensure that it's only called in well-typed ways.  I can also just look at the code for the function, and infer a type that is either the same or more general.

Not so here.  I boggled that we can write
	data IntU a b = IntU Int
and not know whether it is lifted or not.  That's about *semantics* and runtime behaviour, not mere static acceptance/rejection!

I suppose my base principle is:
* If GHC can infer a type for a declaration
* Then it's ok to omit or ignore the type/kind signature

That is, signatures (a) are needed when inference is Too Hard (b) restrict polymorphism.  But they should not (c) change semantics.

Now I know that because of dark corners of the language, defaulting etc, the signature of a function *can* affect its semantics, but it is rare and very much a dark corner -- it's a wart.  But this is right at the heart of what every data declaration means.  I don't want to use one small wart to justify a much larger wartier wart.

I wish I had realised this at the time.  Apologies for that.

Simon

|  -----Original Message-----
|  From: Eric Seidel <eric at seidel.io>
|  Sent: 18 August 2021 03:57
|  To: Simon Peyton Jones <simonpj at microsoft.com>; ghc-steering-
|  committee at haskell.org; Sebastian Graf <sgraf1337 at gmail.com>
|  Subject: Re: [ghc-steering-committee] Unlifted data types
|  
|  I think the distance between the `type IntU` and `data IntU` is the crux of
|  the issue. If we were forced to keep the signature and declaration together,
|  i.e.
|  
|  ```
|  type IntU :: Bool -> Wombat
|  data IntU a b = IntU Int
|  ```
|  
|  I wouldn't be bothered by the distance from the definition of `Wombat`.
|  
|  If I'm reading this code, and I already know what Wombat is, there's no
|  problem. If I *don't* know what Wombat is, then I need to look up its
|  definition anyway to make sense of IntU.
|  
|  I've never been particularly fond of Haskell's tolerance for separating
|  signatures and definitions. It has some practical uses -- notably in
|  combination with -XCPP it makes it easy to ensure signatures are consistent
|  across CPP branches -- but in general I think distance between signature and
|  definition is a smell.
|  
|  On Wed, Aug 11, 2021, at 03:48, Simon Peyton Jones via ghc-steering-
|  committee wrote:
|  >
|  > I have just posted
|  >
|  <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co
|  m%2Fghc-proposals%2Fghc-proposals%2Fpull%2F265%23issuecomment-
|  896626642&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C9bd05c205b5d4757d4cd0
|  8d961f3ea95%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637648524474023194%
|  7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi
|  LCJXVCI6Mn0%3D%7C3000&amp;sdata=sr6XzIgF5CSnLyol8jSfjHToJpD86Q7bPHnKkaMjMgI%
|  3D&amp;reserved=0> this, about unlifted data types.  Yikes!
|  > Simon
|  >
|  > *In accepted proposal #265 on Unlifted Datatypes
|  > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit
|  > hub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F265&amp;data=04%7C01%
|  > 7Csimonpj%40microsoft.com%7C9bd05c205b5d4757d4cd08d961f3ea95%7C72f988b
|  > f86f141af91ab2d7cd011db47%7C1%7C0%7C637648524474033189%7CUnknown%7CTWF
|  > pbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6M
|  > n0%3D%7C3000&amp;sdata=OWlj9RxqQfTBZcjp1QE5AUSSvnG%2By3wbuXL2VbqEGpw%3
|  > D&amp;reserved=0>* I have just realised that in this accepted, and
|  > implemented proposal we have done something entirely new. Consider
|  > this (from
|  > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitl
|  > ab.haskell.org%2Fghc%2Fghc%2F-%2Fissues%2F20204&amp;data=04%7C01%7Csim
|  > onpj%40microsoft.com%7C9bd05c205b5d4757d4cd08d961f3ea95%7C72f988bf86f1
|  > 41af91ab2d7cd011db47%7C1%7C0%7C637648524474033189%7CUnknown%7CTWFpbGZs
|  > b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D
|  > %7C3000&amp;sdata=9SNn4GSIs%2Bd40SBQCEpYfYh7hO73XLoXY%2BWE2uuTg0k%3D&a
|  > mp;reserved=0)
|  >
|  > `type IntU ::  Bool -> Wombat` ` ` `...LOTS OF CODE...` ` ` `data IntU
|  > a b = IntU Int` ` ` `...MORE CODE...` ` ` `type Wombat =Type -> TYPE
|  > UnliftedRep` The kind signature for `IntU` *completely changes the
|  > semantics of the *`*data IntU*`* declaration*, and yet can be separate
|  > from it. That is
|  > new: generally, signatures can restrict the applicability of
|  > something, but *don't change its semantics*. (Yes, with overlapping
|  > instances, certainly incoherent instances, you could change semantics,
|  > but the general principal holds.)
|  >
|  > Even if it is adjacent, the fact that it's unlifted is quite subtle...
|  > you have to look to the right of the arrows, and then through the
|  > distant (and perhaps imported) type synonym `Wombat`.
|  >
|  > I'm not very happy with a distant kind signature having such a
|  > profound effect on the semantics of the data type. Indeed in my
|  > comment above
|  > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit
|  > hub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F265%23issuecomment-52
|  > 5705557&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C9bd05c205b5d4757d
|  > 4cd08d961f3ea95%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637648524
|  > 474033189%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIi
|  > LCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=fB257%2Flsx8ucSnW%2Fgc
|  > %2FPP50rVz4e2MJJCZgmc%2FB08jo%3D&amp;reserved=0> I suggested a keyword
|  >
|  > `data unlifted IntU a b = IntU Int`
|  > to signal that it's an *unlifted* data type. But then I went AWOL and
|  > didn't pursue the matter. I don't know why I was so negligent.
|  >
|  > So this post is to ask: does anyone else think this is bizarre? I'm
|  > inclined to make a proposal to add the keyword, but I thought I'd test
|  > the waters first.
|  >
|  >
|  > _______________________________________________
|  > ghc-steering-committee mailing list
|  > ghc-steering-committee at haskell.org
|  > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
|  > .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&a
|  > mp;data=04%7C01%7Csimonpj%40microsoft.com%7C9bd05c205b5d4757d4cd08d961
|  > f3ea95%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637648524474033189
|  > %7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6I
|  > k1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=rwunJpephHqcWKNE%2F0IpMPS21mWSL
|  > uyYr3V%2FVs6hfCo%3D&amp;reserved=0
|  >

From iavor.diatchki at gmail.com  Wed Aug 18 09:00:39 2021
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Wed, 18 Aug 2021 12:00:39 +0300
Subject: [ghc-steering-committee] Unlifted data types
In-Reply-To: <VI1PR83MB0269D7707A65D963425B7D36ADFF9@VI1PR83MB0269.EURPRD83.prod.outlook.com>
References: <VI1PR83MB0269FC67F40ECAE0A2ED02FBADF89@VI1PR83MB0269.EURPRD83.prod.outlook.com>
 <7f0297ed-3df1-4547-8837-a3e7235ca6a5@www.fastmail.com>
 <VI1PR83MB0269D7707A65D963425B7D36ADFF9@VI1PR83MB0269.EURPRD83.prod.outlook.com>
Message-ID: <CAGK9nuqotH7WmsOc4URXJ7xr04PzjD9DE4Py9i6D7XY54qP7PA@mail.gmail.com>

Hello,

I am retired but still on the list so I read it sometimes :). (feel free to
unsubscribe me)

But since I was not sure where else to comment, I thought I'd chime in here
to say that I also find this pretty confusing.

My assumption/intuition is that 'data' should always introduce a lifted
type, and 'newtype' should have the same liftedness as its definition.   I
would much prefer that if we wanted to have some sort of unified 'data' we
should have a separate construct for it (e.g., like the proposed 'data
unlifted')

Iavor

On Wed, Aug 18, 2021, 11:33 Simon Peyton Jones via ghc-steering-committee <
ghc-steering-committee at haskell.org> wrote:

> I'm bothered both by distance, and the hidden-ness of Wombat, and (most
> fundamentally) by the fact that the data type declaration itself is not
> self-describing.  Usually if I look at a type signature for a function and
> don't really understand it, I can rely on the type checker to ensure that
> it's only called in well-typed ways.  I can also just look at the code for
> the function, and infer a type that is either the same or more general.
>
> Not so here.  I boggled that we can write
>         data IntU a b = IntU Int
> and not know whether it is lifted or not.  That's about *semantics* and
> runtime behaviour, not mere static acceptance/rejection!
>
> I suppose my base principle is:
> * If GHC can infer a type for a declaration
> * Then it's ok to omit or ignore the type/kind signature
>
> That is, signatures (a) are needed when inference is Too Hard (b) restrict
> polymorphism.  But they should not (c) change semantics.
>
> Now I know that because of dark corners of the language, defaulting etc,
> the signature of a function *can* affect its semantics, but it is rare and
> very much a dark corner -- it's a wart.  But this is right at the heart of
> what every data declaration means.  I don't want to use one small wart to
> justify a much larger wartier wart.
>
> I wish I had realised this at the time.  Apologies for that.
>
> Simon
>
> |  -----Original Message-----
> |  From: Eric Seidel <eric at seidel.io>
> |  Sent: 18 August 2021 03:57
> |  To: Simon Peyton Jones <simonpj at microsoft.com>; ghc-steering-
> |  committee at haskell.org; Sebastian Graf <sgraf1337 at gmail.com>
> |  Subject: Re: [ghc-steering-committee] Unlifted data types
> |
> |  I think the distance between the `type IntU` and `data IntU` is the
> crux of
> |  the issue. If we were forced to keep the signature and declaration
> together,
> |  i.e.
> |
> |  ```
> |  type IntU :: Bool -> Wombat
> |  data IntU a b = IntU Int
> |  ```
> |
> |  I wouldn't be bothered by the distance from the definition of `Wombat`.
> |
> |  If I'm reading this code, and I already know what Wombat is, there's no
> |  problem. If I *don't* know what Wombat is, then I need to look up its
> |  definition anyway to make sense of IntU.
> |
> |  I've never been particularly fond of Haskell's tolerance for separating
> |  signatures and definitions. It has some practical uses -- notably in
> |  combination with -XCPP it makes it easy to ensure signatures are
> consistent
> |  across CPP branches -- but in general I think distance between
> signature and
> |  definition is a smell.
> |
> |  On Wed, Aug 11, 2021, at 03:48, Simon Peyton Jones via ghc-steering-
> |  committee wrote:
> |  >
> |  > I have just posted
> |  >
> |  <
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co
> |  m%2Fghc-proposals%2Fghc-proposals%2Fpull%2F265%23issuecomment-
> |  896626642&amp;data=04%7C01%7Csimonpj%40microsoft.com
> %7C9bd05c205b5d4757d4cd0
> |
> 8d961f3ea95%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637648524474023194%
> |
> 7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi
> |
> LCJXVCI6Mn0%3D%7C3000&amp;sdata=sr6XzIgF5CSnLyol8jSfjHToJpD86Q7bPHnKkaMjMgI%
> |  3D&amp;reserved=0> this, about unlifted data types.  Yikes!
> |  > Simon
> |  >
> |  > *In accepted proposal #265 on Unlifted Datatypes
> |  > <
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit
> |  > hub.com
> %2Fghc-proposals%2Fghc-proposals%2Fpull%2F265&amp;data=04%7C01%
> |  > 7Csimonpj%40microsoft.com
> %7C9bd05c205b5d4757d4cd08d961f3ea95%7C72f988b
> |  > f86f141af91ab2d7cd011db47%7C1%7C0%7C637648524474033189%7CUnknown%7CTWF
> |  > pbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6M
> |  > n0%3D%7C3000&amp;sdata=OWlj9RxqQfTBZcjp1QE5AUSSvnG%2By3wbuXL2VbqEGpw%3
> |  > D&amp;reserved=0>* I have just realised that in this accepted, and
> |  > implemented proposal we have done something entirely new. Consider
> |  > this (from
> |  >
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitl
> |  > ab.haskell.org
> %2Fghc%2Fghc%2F-%2Fissues%2F20204&amp;data=04%7C01%7Csim
> |  > onpj%40microsoft.com
> %7C9bd05c205b5d4757d4cd08d961f3ea95%7C72f988bf86f1
> |  > 41af91ab2d7cd011db47%7C1%7C0%7C637648524474033189%7CUnknown%7CTWFpbGZs
> |  > b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D
> |  > %7C3000&amp;sdata=9SNn4GSIs%2Bd40SBQCEpYfYh7hO73XLoXY%2BWE2uuTg0k%3D&a
> |  > mp;reserved=0)
> |  >
> |  > `type IntU ::  Bool -> Wombat` ` ` `...LOTS OF CODE...` ` ` `data IntU
> |  > a b = IntU Int` ` ` `...MORE CODE...` ` ` `type Wombat =Type -> TYPE
> |  > UnliftedRep` The kind signature for `IntU` *completely changes the
> |  > semantics of the *`*data IntU*`* declaration*, and yet can be separate
> |  > from it. That is
> |  > new: generally, signatures can restrict the applicability of
> |  > something, but *don't change its semantics*. (Yes, with overlapping
> |  > instances, certainly incoherent instances, you could change semantics,
> |  > but the general principal holds.)
> |  >
> |  > Even if it is adjacent, the fact that it's unlifted is quite subtle...
> |  > you have to look to the right of the arrows, and then through the
> |  > distant (and perhaps imported) type synonym `Wombat`.
> |  >
> |  > I'm not very happy with a distant kind signature having such a
> |  > profound effect on the semantics of the data type. Indeed in my
> |  > comment above
> |  > <
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit
> |  > hub.com
> %2Fghc-proposals%2Fghc-proposals%2Fpull%2F265%23issuecomment-52
> |  > 5705557&amp;data=04%7C01%7Csimonpj%40microsoft.com
> %7C9bd05c205b5d4757d
> |  > 4cd08d961f3ea95%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637648524
> |  > 474033189%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIi
> |  > LCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=fB257%2Flsx8ucSnW%2Fgc
> |  > %2FPP50rVz4e2MJJCZgmc%2FB08jo%3D&amp;reserved=0> I suggested a keyword
> |  >
> |  > `data unlifted IntU a b = IntU Int`
> |  > to signal that it's an *unlifted* data type. But then I went AWOL and
> |  > didn't pursue the matter. I don't know why I was so negligent.
> |  >
> |  > So this post is to ask: does anyone else think this is bizarre? I'm
> |  > inclined to make a proposal to add the keyword, but I thought I'd test
> |  > the waters first.
> |  >
> |  >
> |  > _______________________________________________
> |  > ghc-steering-committee mailing list
> |  > ghc-steering-committee at haskell.org
> |  >
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
> |  > .haskell.org
> %2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&a
> |  > mp;data=04%7C01%7Csimonpj%40microsoft.com
> %7C9bd05c205b5d4757d4cd08d961
> |  > f3ea95%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637648524474033189
> |  > %7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6I
> |  > k1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=rwunJpephHqcWKNE%2F0IpMPS21mWSL
> |  > uyYr3V%2FVs6hfCo%3D&amp;reserved=0
> |  >
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210818/2f56be77/attachment-0001.html>

From eric at seidel.io  Wed Aug 18 13:32:37 2021
From: eric at seidel.io (Eric Seidel)
Date: Wed, 18 Aug 2021 08:32:37 -0500
Subject: [ghc-steering-committee] Unlifted data types
In-Reply-To: <VI1PR83MB0269D7707A65D963425B7D36ADFF9@VI1PR83MB0269.EURPRD83.prod.outlook.com>
References: <VI1PR83MB0269FC67F40ECAE0A2ED02FBADF89@VI1PR83MB0269.EURPRD83.prod.outlook.com>
 <7f0297ed-3df1-4547-8837-a3e7235ca6a5@www.fastmail.com>
 <VI1PR83MB0269D7707A65D963425B7D36ADFF9@VI1PR83MB0269.EURPRD83.prod.outlook.com>
Message-ID: <d3d59ad6-ac27-4a44-907f-571658e1bbdd@www.fastmail.com>

On Wed, Aug 18, 2021, at 03:32, Simon Peyton Jones wrote:
> Usually if I look at a type signature for a function 
> and don't really understand it, I can rely on the type checker to 
> ensure that it's only called in well-typed ways.  I can also just look 
> at the code for the function, and infer a type that is either the same 
> or more general.

Note that we can still rely on the type checker to ensure that IntU is only
used in well-typed ways. This is strictly about communicating semantics
to other programmers (not suggesting that's less important).

> Not so here.  I boggled that we can write
> 	data IntU a b = IntU Int
> and not know whether it is lifted or not.  That's about *semantics* and 
> runtime behaviour, not mere static acceptance/rejection!
> 
> I suppose my base principle is:
> * If GHC can infer a type for a declaration
> * Then it's ok to omit or ignore the type/kind signature
> 
> That is, signatures (a) are needed when inference is Too Hard (b) 
> restrict polymorphism.  But they should not (c) change semantics.
> 
> Now I know that because of dark corners of the language, defaulting 
> etc, the signature of a function *can* affect its semantics, but it is 
> rare and very much a dark corner -- it's a wart.  But this is right at 
> the heart of what every data declaration means.  I don't want to use 
> one small wart to justify a much larger wartier wart.

Type classes (and in particular the monomorphism restriction) are a very
prominent example of signatures affecting runtime semantics in
fundamental ways. The monomorphism restriction itself is a wart, but the
underlying difference between

  foo :: Num a => a

and 

  foo :: Int

in terms of runtime representation and sharing are core to the language.
And in my opinion, the type signature is *exactly* the right place to
capture these semantic differences.

We use types to communicate the externally-visible behavior of our
programs: the number of arguments to a function and their types,
effects incurred in the form of monads, etc. Why should liftedness
and the implications for evaluation strategies be different? (In fact,
as I've suggested before, I think we should go further and expose
the strictness of function arguments in the type system, but that's
a separate discussion.)

---

On a semi-related note, this prompted me to go back and reread the
proposal, and I'm not entirely clear on one point. In

```
data Foo :: TYPE (BoxedRep Unlifted) where
  MkFoo :: Int -> Foo
```

Foo is unlifted and arguments of type Foo will be evaluated strictly,
but is MkFoo itself strict in its Int argument? The proposal doesn't
seem to say, and I could see arguments in either direction.

From simonpj at microsoft.com  Thu Aug 19 11:14:01 2021
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 19 Aug 2021 11:14:01 +0000
Subject: [ghc-steering-committee] Unlifted data types
In-Reply-To: <d3d59ad6-ac27-4a44-907f-571658e1bbdd@www.fastmail.com>
References: <VI1PR83MB0269FC67F40ECAE0A2ED02FBADF89@VI1PR83MB0269.EURPRD83.prod.outlook.com>
 <7f0297ed-3df1-4547-8837-a3e7235ca6a5@www.fastmail.com>
 <VI1PR83MB0269D7707A65D963425B7D36ADFF9@VI1PR83MB0269.EURPRD83.prod.outlook.com>
 <d3d59ad6-ac27-4a44-907f-571658e1bbdd@www.fastmail.com>
Message-ID: <VI1PR83MB0269C0107809DB6C2D8BCC1CADC09@VI1PR83MB0269.EURPRD83.prod.outlook.com>

|  We use types to communicate the externally-visible behavior of our
|  programs: the number of arguments to a function and their types, effects
|  incurred in the form of monads, etc. Why should liftedness and the
|  implications for evaluation strategies be different?

We use them to *communicate* behaviour, but not to *specify* behaviour.  That is done by the definition of the function itself.

I'm keen to hear from other members of the committee.

Maybe I should make a proposal, to seek broader input.

Simon

|  -----Original Message-----
|  From: Eric Seidel <eric at seidel.io>
|  Sent: 18 August 2021 14:33
|  To: Simon Peyton Jones <simonpj at microsoft.com>; ghc-steering-
|  committee at haskell.org; Sebastian Graf <sgraf1337 at gmail.com>
|  Subject: Re: [ghc-steering-committee] Unlifted data types
|  
|  On Wed, Aug 18, 2021, at 03:32, Simon Peyton Jones wrote:
|  > Usually if I look at a type signature for a function and don't really
|  > understand it, I can rely on the type checker to ensure that it's only
|  > called in well-typed ways.  I can also just look at the code for the
|  > function, and infer a type that is either the same or more general.
|  
|  Note that we can still rely on the type checker to ensure that IntU is only
|  used in well-typed ways. This is strictly about communicating semantics to
|  other programmers (not suggesting that's less important).
|  
|  > Not so here.  I boggled that we can write
|  > 	data IntU a b = IntU Int
|  > and not know whether it is lifted or not.  That's about *semantics*
|  > and runtime behaviour, not mere static acceptance/rejection!
|  >
|  > I suppose my base principle is:
|  > * If GHC can infer a type for a declaration
|  > * Then it's ok to omit or ignore the type/kind signature
|  >
|  > That is, signatures (a) are needed when inference is Too Hard (b)
|  > restrict polymorphism.  But they should not (c) change semantics.
|  >
|  > Now I know that because of dark corners of the language, defaulting
|  > etc, the signature of a function *can* affect its semantics, but it is
|  > rare and very much a dark corner -- it's a wart.  But this is right at
|  > the heart of what every data declaration means.  I don't want to use
|  > one small wart to justify a much larger wartier wart.
|  
|  Type classes (and in particular the monomorphism restriction) are a very
|  prominent example of signatures affecting runtime semantics in fundamental
|  ways. The monomorphism restriction itself is a wart, but the underlying
|  difference between
|  
|    foo :: Num a => a
|  
|  and
|  
|    foo :: Int
|  
|  in terms of runtime representation and sharing are core to the language.
|  And in my opinion, the type signature is *exactly* the right place to
|  capture these semantic differences.
|  
|  We use types to communicate the externally-visible behavior of our
|  programs: the number of arguments to a function and their types, effects
|  incurred in the form of monads, etc. Why should liftedness and the
|  implications for evaluation strategies be different? (In fact, as I've
|  suggested before, I think we should go further and expose the strictness of
|  function arguments in the type system, but that's a separate discussion.)
|  
|  ---
|  
|  On a semi-related note, this prompted me to go back and reread the proposal,
|  and I'm not entirely clear on one point. In
|  
|  ```
|  data Foo :: TYPE (BoxedRep Unlifted) where
|    MkFoo :: Int -> Foo
|  ```
|  
|  Foo is unlifted and arguments of type Foo will be evaluated strictly, but is
|  MkFoo itself strict in its Int argument? The proposal doesn't seem to say,
|  and I could see arguments in either direction.

From eric at seidel.io  Thu Aug 19 13:25:52 2021
From: eric at seidel.io (Eric Seidel)
Date: Thu, 19 Aug 2021 08:25:52 -0500
Subject: [ghc-steering-committee] #409: Exportable named defaults,
	Recommendation: Accept
In-Reply-To: <VI1PR83MB0269DB8E468F939EE67FD08AADFB9@VI1PR83MB0269.EURPRD83.prod.outlook.com>
References: <VI1PR83MB0269DB8E468F939EE67FD08AADFB9@VI1PR83MB0269.EURPRD83.prod.outlook.com>
Message-ID: <58CA0B9F-0B7B-40C8-A8E3-BB8A588B8B84@seidel.io>

Dear Committee,

Simon PJ has requested (on GitHub) that we merge all aspects of this proposal into a single extension NamedDefaults. We already had agreement that the import behavior should not be guarded by any extension, so I take this to mean the following. 

The proposal will introduce a single new extension NamedDefaults that enables:

1. The ‘default C (T1, T2, …)’ syntax that specifies the defaulted class. 
2. Exporting defaulting rules as discussed (explicitly, in the export list). 

Defaulting rules are always imported (implicitly), with no need to enable the NamedDefaults extension. 

Any objections?

Sent from my iPhone

> On Aug 14, 2021, at 12:58, Simon Peyton Jones <simonpj at microsoft.com> wrote:
> 
> 
> Eric
>  
> I’m in support too – but I have added three small qns to the GitHub thread.
> 
> Simon
>  
> From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On Behalf Of Spiwack, Arnaud
> Sent: 05 August 2021 07:43
> To: Eric Seidel <eric at seidel.io>
> Cc: ghc-steering-committee at haskell.org
> Subject: Re: [ghc-steering-committee] #409: Exportable named defaults, Recommendation: Accept
>  
> I'm very supportive of this proposal. Thanks to everyone who participated in the discussion. Like Eric, I don't see any value to the ImportedDefault extension, and would rather we removed it.
> 
>  
> 
> On Tue, Aug 3, 2021 at 4:10 AM Eric Seidel <eric at seidel.io> wrote:
> 
> Committee,
> 
> Mario has updated the proposal following some discussion on GitHub around the question of implicit vs explicit export and import of default rules. The result is
> 
> 1. *Implicit import*: any and all forms of `import M` also import any defaulting rules exported by M, like type classes.
> 
> 2. *Explicit export*: defaulting rules must be explicitly exported like named things, mostly. The one exception is that 
> 
>     module M (module N) where { import N }
> 
> does not re-export any defaulting rules imported from N. Simon PJ argued strongly for this change on GitHub[1].
> 
> With that question settled, and with Simon and Richard's assent on GitHub, *I'd like to recommend that we accept the proposal*. However, I still do not see the need for a separate ImportedDefaults extension and would recommend that we enable the import behavior universally.
> 
> [1]: https://github.com/ghc-proposals/ghc-proposals/pull/409#issuecomment-882338794
> 
> On Mon, Jul 12, 2021, at 04:09, Simon Peyton Jones wrote:
> >  
> > I have added this as a comment in the GitHub repo, since others may 
> > want to express an opinion
> >  
> > Simon
> >  
> > *From:* ghc-steering-committee 
> > <ghc-steering-committee-bounces at haskell.org> *On Behalf Of *Richard 
> > Eisenberg
> > *Sent:* 11 July 2021 02:48
> > *To:* Eric Seidel <eric at seidel.io>
> > *Cc:* ghc-steering-committee at haskell.org
> > *Subject:* Re: [ghc-steering-committee] #409: Exportable named 
> > defaults, Recommendation: Partial Accept
> >  
> >  
> > 
> > 
> > > On Jul 9, 2021, at 12:35 AM, Eric Seidel <eric at seidel.io> wrote:
> > >  
> > > On Thu, Jul 1, 2021, at 13:16, Joachim Breitner wrote:
> > > 
> > >> a different way to phrase that question might be: Do we want these
> > >> defaulting declarations to behave just exactly like named things, or
> > >> exactly like typeclass instances, or do we afford a new class with it’s
> > >> own exporting/importing behavior. Is that a fair assessment?
> > > 
> > > Not entirely, I think. 
> > > 
> > > We currently have two types of import/export behavior:
> > > named things, and typeclass instances. The proposal as currently
> > > written places defaulting rules somewhere in between: defaulting
> > > rules are exported like named things, but imported like class instances.
> > > This is new, but not too foreign, as the behavior on both sides exactly
> > > matches existing behavior we're familiar with. It's just the combination
> > > that's new.
> >  
> > This doesn't match my understanding of the proposal. It looks to me 
> > that, as written in the proposal, exports of a `default` would have to 
> > be explicit. That is, a module starting with `module M where ...` would 
> > not export any defaults. This fact is a bit implied in the proposal 
> > ("This proposal does not modify that behaviour: a `default` declaration 
> > by itself does not apply outside its module."), but it's my best 
> > understanding. 
> >  
> > ---
> >  
> > Simon and I have discussed. We both came to an agreement that imports 
> > should have to be explicit.
> >  
> > GHC currently has two import/export strategies.
> >  
> > Strategy 1: Always. In the Always strategy, an entity is always 
> > exported from a module and always brought into scope from an imported 
> > module. The Always strategy is used for type and class instances.
> >  
> > Strategy 2: Public. In the Public strategy, an entity is exported by 
> > default (no export list) or when explicitly included in an export list. 
> > It is brought into scope from an importing module by default (no import 
> > list) or when explicitly included in an import list. A Public entity 
> > may be excluded from scope by a `hiding` clause. All top-level named 
> > entities are exported/imported via the Public strategy.
> >  
> > I propose (with Simon's support)
> >  
> > Strategy 3: Private. In the Private strategy. an entity is exported 
> > only when explicitly included in an export list, and it is brought into 
> > scope from an imported module only when explicitly included in the 
> > import list. I propose we use Private for `default` declarations (only).
> >  
> > Reasons:
> >  
> > * Changing defaulting behavior really can launch the rockets. Suppose T 
> > has a Num instance whose fromInteger uses unsafePerformIO to launch the 
> > rockets. Then including T in an import list could make a very 
> > innocent-looking `x = 5` declaration launch the rockets.
> >  
> > * GHC currently supports an option -ddump-minimal-imports, which 
> > displays import lists describing what symbols must be brought into 
> > scope from an imported module. If a `import M` import statement brought 
> > defaulting behavior into scope, then going from `import M` to `import M 
> > (foo, bar)` might deleteriously change defaulting behavior, thus 
> > invalidating the work of -ddump-minimal-imports.
> >  
> > * The proposal as written does not describe how `module` exports work 
> > with named defaults. For example, what happens in `module B (module A) 
> > where import A`? Normally, that re-exports all names in scope both as 
> > `A.blah` and as `blah`. But, of course, a default isn't named in this 
> > way. So is the default exported? By requiring explicit inclusion in the 
> > export list, the Private strategy sidesteps this question.
> >  
> > * This is a more conservative choice. We can always revisit this in the 
> > light of experience. However, if defaults were always imported, it 
> > would be much more disruptive to make them imported only by request.
> >  
> > We have rightly identified that using the Private strategy would 
> > potentially reduce the usefulness of this idea, especially with 
> > alternative Preludes. As far as I know, GHC does not currently 
> > officially support having an alternative Prelude. That is, an 
> > "alternative Prelude" is really just disabling the import of 
> > base.Prelude and then importing some other module. However, we could 
> > imagine a compiler flag that specifies another package (or module name) 
> > to use as the Prelude... and then we could also specify how it is 
> > imported. For example, we could say that the Prelude is imported with
> >  
> > > import Prelude
> > > import Prelude ( default(..) )
> >  
> > where the second line says to grab all the defaults. I think this would 
> > be reasonable, but not necessary in the first version of this current 
> > proposal.
> >  
> > Richard
> _______________________________________________
> 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/20210819/1d33399a/attachment.html>

From mail at joachim-breitner.de  Thu Aug 19 18:05:41 2021
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 19 Aug 2021 20:05:41 +0200
Subject: [ghc-steering-committee] #409: Exportable named defaults,
 Recommendation: Accept
In-Reply-To: <58CA0B9F-0B7B-40C8-A8E3-BB8A588B8B84@seidel.io>
References: <VI1PR83MB0269DB8E468F939EE67FD08AADFB9@VI1PR83MB0269.EURPRD83.prod.outlook.com>
 <58CA0B9F-0B7B-40C8-A8E3-BB8A588B8B84@seidel.io>
Message-ID: <1438c8dd96300619f40a69f2efef61f170d36bae.camel@joachim-breitner.de>

Hi,

Am Donnerstag, dem 19.08.2021 um 08:25 -0500 schrieb Eric Seidel:
> Any objections?

not from me :-)

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



From eric at seidel.io  Thu Aug 19 19:16:39 2021
From: eric at seidel.io (Eric Seidel)
Date: Thu, 19 Aug 2021 14:16:39 -0500
Subject: [ghc-steering-committee] Unlifted data types
In-Reply-To: <VI1PR83MB0269C0107809DB6C2D8BCC1CADC09@VI1PR83MB0269.EURPRD83.prod.outlook.com>
References: <VI1PR83MB0269FC67F40ECAE0A2ED02FBADF89@VI1PR83MB0269.EURPRD83.prod.outlook.com>
 <7f0297ed-3df1-4547-8837-a3e7235ca6a5@www.fastmail.com>
 <VI1PR83MB0269D7707A65D963425B7D36ADFF9@VI1PR83MB0269.EURPRD83.prod.outlook.com>
 <d3d59ad6-ac27-4a44-907f-571658e1bbdd@www.fastmail.com>
 <VI1PR83MB0269C0107809DB6C2D8BCC1CADC09@VI1PR83MB0269.EURPRD83.prod.outlook.com>
Message-ID: <902afa3f-004b-4366-bd1f-3d86b83b87a7@www.fastmail.com>

On Thu, Aug 19, 2021, at 06:14, Simon Peyton Jones wrote:
> |  We use types to communicate the externally-visible behavior of our
> |  programs: the number of arguments to a function and their types, effects
> |  incurred in the form of monads, etc. Why should liftedness and the
> |  implications for evaluation strategies be different?
> 
> We use them to *communicate* behaviour, but not to *specify* behaviour. 
>  That is done by the definition of the function itself.

I disagree, types are a great specification language. The whole point of advanced
type system features is to enhance the specification language so we can
specify more interesting properties. 

Often, we do this so that the type checker can *verify* our code, but there are plenty
of cases where we use types to *drive code generation*. Consider GHC.Generics.
We can write a highly-polymorphic JSON serialization function

  gToJSON :: Generic a => a -> JSON

which we can then instantiate at different types, e.g.

  data Foo
  fooToJSON :: Foo -> JSON
  fooToJSON = gToJSON

  data Bar
  barToJSON :: Bar -> JSON
  barToJSON = gToJSON

fooToJSON and barToJSON have the exact same definition, but very different
semantics. Their complete semantics depends on *both* their definition *and*
their type signatures.

I think the deeper point here is that Haskell's dynamic semantics depends on
its static semantics. We can't evaluate a Haskell program without knowing the
types involved.

From sgraf1337 at gmail.com  Thu Aug 19 19:23:15 2021
From: sgraf1337 at gmail.com (Sebastian Graf)
Date: Thu, 19 Aug 2021 19:23:15 +0000
Subject: [ghc-steering-committee] Unlifted data types
In-Reply-To: <902afa3f-004b-4366-bd1f-3d86b83b87a7@www.fastmail.com>
References: <VI1PR83MB0269FC67F40ECAE0A2ED02FBADF89@vi1pr83mb0269.eurprd83.prod.outlook.com>
 <7f0297ed-3df1-4547-8837-a3e7235ca6a5@www.fastmail.com>
 <VI1PR83MB0269D7707A65D963425B7D36ADFF9@vi1pr83mb0269.eurprd83.prod.outlook.com>
 <d3d59ad6-ac27-4a44-907f-571658e1bbdd@www.fastmail.com>
 <VI1PR83MB0269C0107809DB6C2D8BCC1CADC09@vi1pr83mb0269.eurprd83.prod.outlook.com>
 <902afa3f-004b-4366-bd1f-3d86b83b87a7@www.fastmail.com>
Message-ID: <emb019ef72-16cc-4a6a-96d6-e7a85de6d982@sebastian-pc>

Hi,

FWIW, I'm neither a proponent of adding an unlifted keyword or modifier, 
nor a strong opponent.
I just want to make aware of the point I raise in 
https://github.com/ghc-proposals/ghc-proposals/pull/265#issuecomment-901904173, 
namely that
No keyword is sufficient to describe the full spectrum of 
levity-polymorphic data typesOur language server is already smart enough 
to give the necessary info on hover, without even needing to navigate to 
the definition (where we would hope to see `unlifted` or a lack 
thereof). It also works with levity-polymorphism.
Cheers,
Sebastian

------ Originalnachricht ------
Von: "Eric Seidel" <eric at seidel.io>
An: "Simon Peyton Jones" <simonpj at microsoft.com>; 
"ghc-steering-committee at haskell.org" 
<ghc-steering-committee at haskell.org>; "Sebastian Graf" 
<sgraf1337 at gmail.com>
Gesendet: 19.08.2021 21:16:39
Betreff: Re: [ghc-steering-committee] Unlifted data types

>On Thu, Aug 19, 2021, at 06:14, Simon Peyton Jones wrote:
>>  |  We use types to communicate the externally-visible behavior of our
>>  |  programs: the number of arguments to a function and their types, effects
>>  |  incurred in the form of monads, etc. Why should liftedness and the
>>  |  implications for evaluation strategies be different?
>>
>>  We use them to *communicate* behaviour, but not to *specify* behaviour.
>>   That is done by the definition of the function itself.
>
>I disagree, types are a great specification language. The whole point of advanced
>type system features is to enhance the specification language so we can
>specify more interesting properties.
>
>Often, we do this so that the type checker can *verify* our code, but there are plenty
>of cases where we use types to *drive code generation*. Consider GHC.Generics.
>We can write a highly-polymorphic JSON serialization function
>
>   gToJSON :: Generic a => a -> JSON
>
>which we can then instantiate at different types, e.g.
>
>   data Foo
>   fooToJSON :: Foo -> JSON
>   fooToJSON = gToJSON
>
>   data Bar
>   barToJSON :: Bar -> JSON
>   barToJSON = gToJSON
>
>fooToJSON and barToJSON have the exact same definition, but very different
>semantics. Their complete semantics depends on *both* their definition *and*
>their type signatures.
>
>I think the deeper point here is that Haskell's dynamic semantics depends on
>its static semantics. We can't evaluate a Haskell program without knowing the
>types involved.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210819/48c74fe7/attachment.html>

From lists at richarde.dev  Fri Aug 20 02:13:16 2021
From: lists at richarde.dev (Richard Eisenberg)
Date: Fri, 20 Aug 2021 02:13:16 +0000
Subject: [ghc-steering-committee] #409: Exportable named defaults,
 Recommendation: Accept
In-Reply-To: <58CA0B9F-0B7B-40C8-A8E3-BB8A588B8B84@seidel.io>
References: <VI1PR83MB0269DB8E468F939EE67FD08AADFB9@VI1PR83MB0269.EURPRD83.prod.outlook.com>
 <58CA0B9F-0B7B-40C8-A8E3-BB8A588B8B84@seidel.io>
Message-ID: <010f017b61557982-284fcbc1-ff82-4cf5-8cb1-8bb6be5b01df-000000@us-east-2.amazonses.com>

I'm happy with this. Thanks!

Richard

> On Aug 19, 2021, at 9:25 AM, Eric Seidel <eric at seidel.io> wrote:
> 
> Dear Committee,
> 
> Simon PJ has requested (on GitHub) that we merge all aspects of this proposal into a single extension NamedDefaults. We already had agreement that the import behavior should not be guarded by any extension, so I take this to mean the following. 
> 
> The proposal will introduce a single new extension NamedDefaults that enables:
> 
> 1. The ‘default C (T1, T2, …)’ syntax that specifies the defaulted class. 
> 2. Exporting defaulting rules as discussed (explicitly, in the export list). 
> 
> Defaulting rules are always imported (implicitly), with no need to enable the NamedDefaults extension. 
> 
> Any objections?
> 
> Sent from my iPhone
> 
>> On Aug 14, 2021, at 12:58, Simon Peyton Jones <simonpj at microsoft.com> wrote:
>> 
>> 
>> Eric
>>  
>> I’m in support too – but I have added three small qns to the GitHub thread.
>> 
>> Simon
>>  
>> From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On Behalf Of Spiwack, Arnaud
>> Sent: 05 August 2021 07:43
>> To: Eric Seidel <eric at seidel.io>
>> Cc: ghc-steering-committee at haskell.org
>> Subject: Re: [ghc-steering-committee] #409: Exportable named defaults, Recommendation: Accept
>>  
>> I'm very supportive of this proposal. Thanks to everyone who participated in the discussion. Like Eric, I don't see any value to the ImportedDefault extension, and would rather we removed it.
>> 
>>  
>> 
>> On Tue, Aug 3, 2021 at 4:10 AM Eric Seidel <eric at seidel.io <mailto:eric at seidel.io>> wrote:
>> 
>> Committee,
>> 
>> Mario has updated the proposal following some discussion on GitHub around the question of implicit vs explicit export and import of default rules. The result is
>> 
>> 1. *Implicit import*: any and all forms of `import M` also import any defaulting rules exported by M, like type classes.
>> 
>> 2. *Explicit export*: defaulting rules must be explicitly exported like named things, mostly. The one exception is that 
>> 
>>     module M (module N) where { import N }
>> 
>> does not re-export any defaulting rules imported from N. Simon PJ argued strongly for this change on GitHub[1].
>> 
>> With that question settled, and with Simon and Richard's assent on GitHub, *I'd like to recommend that we accept the proposal*. However, I still do not see the need for a separate ImportedDefaults extension and would recommend that we enable the import behavior universally.
>> 
>> [1]: https://github.com/ghc-proposals/ghc-proposals/pull/409#issuecomment-882338794 <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F409%23issuecomment-882338794&data=04%7C01%7Csimonpj%40microsoft.com%7C4209473397bb4a1e123d08d957dc5f41%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637637426303882159%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=QimksAfoQFVo25E0UgtDwLiOUFKzUgl24h5P%2BvO26Oc%3D&reserved=0>
>> 
>> On Mon, Jul 12, 2021, at 04:09, Simon Peyton Jones wrote:
>> >  
>> > I have added this as a comment in the GitHub repo, since others may 
>> > want to express an opinion
>> >  
>> > Simon
>> >  
>> > *From:* ghc-steering-committee 
>> > <ghc-steering-committee-bounces at haskell.org <mailto:ghc-steering-committee-bounces at haskell.org>> *On Behalf Of *Richard 
>> > Eisenberg
>> > *Sent:* 11 July 2021 02:48
>> > *To:* Eric Seidel <eric at seidel.io <mailto:eric at seidel.io>>
>> > *Cc:* ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
>> > *Subject:* Re: [ghc-steering-committee] #409: Exportable named 
>> > defaults, Recommendation: Partial Accept
>> >  
>> >  
>> > 
>> > 
>> > > On Jul 9, 2021, at 12:35 AM, Eric Seidel <eric at seidel.io <mailto:eric at seidel.io>> wrote:
>> > >  
>> > > On Thu, Jul 1, 2021, at 13:16, Joachim Breitner wrote:
>> > > 
>> > >> a different way to phrase that question might be: Do we want these
>> > >> defaulting declarations to behave just exactly like named things, or
>> > >> exactly like typeclass instances, or do we afford a new class with it’s
>> > >> own exporting/importing behavior. Is that a fair assessment?
>> > > 
>> > > Not entirely, I think. 
>> > > 
>> > > We currently have two types of import/export behavior:
>> > > named things, and typeclass instances. The proposal as currently
>> > > written places defaulting rules somewhere in between: defaulting
>> > > rules are exported like named things, but imported like class instances.
>> > > This is new, but not too foreign, as the behavior on both sides exactly
>> > > matches existing behavior we're familiar with. It's just the combination
>> > > that's new.
>> >  
>> > This doesn't match my understanding of the proposal. It looks to me 
>> > that, as written in the proposal, exports of a `default` would have to 
>> > be explicit. That is, a module starting with `module M where ...` would 
>> > not export any defaults. This fact is a bit implied in the proposal 
>> > ("This proposal does not modify that behaviour: a `default` declaration 
>> > by itself does not apply outside its module."), but it's my best 
>> > understanding. 
>> >  
>> > ---
>> >  
>> > Simon and I have discussed. We both came to an agreement that imports 
>> > should have to be explicit.
>> >  
>> > GHC currently has two import/export strategies.
>> >  
>> > Strategy 1: Always. In the Always strategy, an entity is always 
>> > exported from a module and always brought into scope from an imported 
>> > module. The Always strategy is used for type and class instances.
>> >  
>> > Strategy 2: Public. In the Public strategy, an entity is exported by 
>> > default (no export list) or when explicitly included in an export list. 
>> > It is brought into scope from an importing module by default (no import 
>> > list) or when explicitly included in an import list. A Public entity 
>> > may be excluded from scope by a `hiding` clause. All top-level named 
>> > entities are exported/imported via the Public strategy.
>> >  
>> > I propose (with Simon's support)
>> >  
>> > Strategy 3: Private. In the Private strategy. an entity is exported 
>> > only when explicitly included in an export list, and it is brought into 
>> > scope from an imported module only when explicitly included in the 
>> > import list. I propose we use Private for `default` declarations (only).
>> >  
>> > Reasons:
>> >  
>> > * Changing defaulting behavior really can launch the rockets. Suppose T 
>> > has a Num instance whose fromInteger uses unsafePerformIO to launch the 
>> > rockets. Then including T in an import list could make a very 
>> > innocent-looking `x = 5` declaration launch the rockets.
>> >  
>> > * GHC currently supports an option -ddump-minimal-imports, which 
>> > displays import lists describing what symbols must be brought into 
>> > scope from an imported module. If a `import M` import statement brought 
>> > defaulting behavior into scope, then going from `import M` to `import M 
>> > (foo, bar)` might deleteriously change defaulting behavior, thus 
>> > invalidating the work of -ddump-minimal-imports.
>> >  
>> > * The proposal as written does not describe how `module` exports work 
>> > with named defaults. For example, what happens in `module B (module A) 
>> > where import A`? Normally, that re-exports all names in scope both as 
>> > `A.blah` and as `blah`. But, of course, a default isn't named in this 
>> > way. So is the default exported? By requiring explicit inclusion in the 
>> > export list, the Private strategy sidesteps this question.
>> >  
>> > * This is a more conservative choice. We can always revisit this in the 
>> > light of experience. However, if defaults were always imported, it 
>> > would be much more disruptive to make them imported only by request.
>> >  
>> > We have rightly identified that using the Private strategy would 
>> > potentially reduce the usefulness of this idea, especially with 
>> > alternative Preludes. As far as I know, GHC does not currently 
>> > officially support having an alternative Prelude. That is, an 
>> > "alternative Prelude" is really just disabling the import of 
>> > base.Prelude and then importing some other module. However, we could 
>> > imagine a compiler flag that specifies another package (or module name) 
>> > to use as the Prelude... and then we could also specify how it is 
>> > imported. For example, we could say that the Prelude is imported with
>> >  
>> > > import Prelude
>> > > import Prelude ( default(..) )
>> >  
>> > where the second line says to grab all the defaults. I think this would 
>> > be reasonable, but not necessary in the first version of this current 
>> > proposal.
>> >  
>> > Richard
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7C4209473397bb4a1e123d08d957dc5f41%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637637426303892149%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=UhgwhcfU2P5%2BBwQX0lokFK8wIlFnW5RC%2BdSCg24oSzE%3D&reserved=0>_______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

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

From trupill at gmail.com  Fri Aug 20 14:26:17 2021
From: trupill at gmail.com (Alejandro Serrano Mena)
Date: Fri, 20 Aug 2021 16:26:17 +0200
Subject: [ghc-steering-committee] #409: Exportable named defaults,
 Recommendation: Accept
In-Reply-To: <010f017b61557982-284fcbc1-ff82-4cf5-8cb1-8bb6be5b01df-000000@us-east-2.amazonses.com>
References: <VI1PR83MB0269DB8E468F939EE67FD08AADFB9@VI1PR83MB0269.EURPRD83.prod.outlook.com>
 <58CA0B9F-0B7B-40C8-A8E3-BB8A588B8B84@seidel.io>
 <010f017b61557982-284fcbc1-ff82-4cf5-8cb1-8bb6be5b01df-000000@us-east-2.amazonses.com>
Message-ID: <CAHnFXOtNHZKiMcG3Km7beCn-bx01XbxPyU_zjXCu057sv5Ogyw@mail.gmail.com>

I am also happy with that solution.

Regards,
Alejandro

El El vie, 20 ago 2021 a las 4:13, Richard Eisenberg <lists at richarde.dev>
escribió:

> I'm happy with this. Thanks!
>
> Richard
>
> On Aug 19, 2021, at 9:25 AM, Eric Seidel <eric at seidel.io> wrote:
>
> Dear Committee,
>
> Simon PJ has requested (on GitHub) that we merge all aspects of this
> proposal into a single extension NamedDefaults. We already had agreement
> that the import behavior should not be guarded by any extension, so I take
> this to mean the following.
>
> The proposal will introduce a single new extension NamedDefaults that
> enables:
>
> 1. The ‘default C (T1, T2, …)’ syntax that specifies the defaulted class.
> 2. Exporting defaulting rules as discussed (explicitly, in the export
> list).
>
> Defaulting rules are always imported (implicitly), with no need to enable
> the NamedDefaults extension.
>
> Any objections?
>
> Sent from my iPhone
>
> On Aug 14, 2021, at 12:58, Simon Peyton Jones <simonpj at microsoft.com>
> wrote:
>
> 
> Eric
>
> I’m in support too – but I have added three small qns to the GitHub thread.
>
> Simon
>
> *From:* ghc-steering-committee <ghc-steering-committee-bounces at haskell.org
> > *On Behalf Of *Spiwack, Arnaud
> *Sent:* 05 August 2021 07:43
> *To:* Eric Seidel <eric at seidel.io>
> *Cc:* ghc-steering-committee at haskell.org
> *Subject:* Re: [ghc-steering-committee] #409: Exportable named defaults,
> Recommendation: Accept
>
>
> I'm very supportive of this proposal. Thanks to everyone who participated
> in the discussion. Like Eric, I don't see any value to the ImportedDefault
> extension, and would rather we removed it.
>
>
>
> On Tue, Aug 3, 2021 at 4:10 AM Eric Seidel <eric at seidel.io> wrote:
>
> Committee,
>
> Mario has updated the proposal following some discussion on GitHub around
> the question of implicit vs explicit export and import of default rules.
> The result is
>
> 1. *Implicit import*: any and all forms of `import M` also import any
> defaulting rules exported by M, like type classes.
>
> 2. *Explicit export*: defaulting rules must be explicitly exported like
> named things, mostly. The one exception is that
>
>     module M (module N) where { import N }
>
> does not re-export any defaulting rules imported from N. Simon PJ argued
> strongly for this change on GitHub[1].
>
> With that question settled, and with Simon and Richard's assent on GitHub,
> *I'd like to recommend that we accept the proposal*. However, I still do
> not see the need for a separate ImportedDefaults extension and would
> recommend that we enable the import behavior universally.
>
> [1]:
> https://github.com/ghc-proposals/ghc-proposals/pull/409#issuecomment-882338794
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F409%23issuecomment-882338794&data=04%7C01%7Csimonpj%40microsoft.com%7C4209473397bb4a1e123d08d957dc5f41%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637637426303882159%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=QimksAfoQFVo25E0UgtDwLiOUFKzUgl24h5P%2BvO26Oc%3D&reserved=0>
>
> On Mon, Jul 12, 2021, at 04:09, Simon Peyton Jones wrote:
> >
> > I have added this as a comment in the GitHub repo, since others may
> > want to express an opinion
> >
> > Simon
> >
> > *From:* ghc-steering-committee
> > <ghc-steering-committee-bounces at haskell.org> *On Behalf Of *Richard
> > Eisenberg
> > *Sent:* 11 July 2021 02:48
> > *To:* Eric Seidel <eric at seidel.io>
> > *Cc:* ghc-steering-committee at haskell.org
> > *Subject:* Re: [ghc-steering-committee] #409: Exportable named
> > defaults, Recommendation: Partial Accept
> >
> >
> >
> >
> > > On Jul 9, 2021, at 12:35 AM, Eric Seidel <eric at seidel.io> wrote:
> > >
> > > On Thu, Jul 1, 2021, at 13:16, Joachim Breitner wrote:
> > >
> > >> a different way to phrase that question might be: Do we want these
> > >> defaulting declarations to behave just exactly like named things, or
> > >> exactly like typeclass instances, or do we afford a new class with
> it’s
> > >> own exporting/importing behavior. Is that a fair assessment?
> > >
> > > Not entirely, I think.
> > >
> > > We currently have two types of import/export behavior:
> > > named things, and typeclass instances. The proposal as currently
> > > written places defaulting rules somewhere in between: defaulting
> > > rules are exported like named things, but imported like class
> instances.
> > > This is new, but not too foreign, as the behavior on both sides exactly
> > > matches existing behavior we're familiar with. It's just the
> combination
> > > that's new.
> >
> > This doesn't match my understanding of the proposal. It looks to me
> > that, as written in the proposal, exports of a `default` would have to
> > be explicit. That is, a module starting with `module M where ...` would
> > not export any defaults. This fact is a bit implied in the proposal
> > ("This proposal does not modify that behaviour: a `default` declaration
> > by itself does not apply outside its module."), but it's my best
> > understanding.
> >
> > ---
> >
> > Simon and I have discussed. We both came to an agreement that imports
> > should have to be explicit.
> >
> > GHC currently has two import/export strategies.
> >
> > Strategy 1: Always. In the Always strategy, an entity is always
> > exported from a module and always brought into scope from an imported
> > module. The Always strategy is used for type and class instances.
> >
> > Strategy 2: Public. In the Public strategy, an entity is exported by
> > default (no export list) or when explicitly included in an export list.
> > It is brought into scope from an importing module by default (no import
> > list) or when explicitly included in an import list. A Public entity
> > may be excluded from scope by a `hiding` clause. All top-level named
> > entities are exported/imported via the Public strategy.
> >
> > I propose (with Simon's support)
> >
> > Strategy 3: Private. In the Private strategy. an entity is exported
> > only when explicitly included in an export list, and it is brought into
> > scope from an imported module only when explicitly included in the
> > import list. I propose we use Private for `default` declarations (only).
> >
> > Reasons:
> >
> > * Changing defaulting behavior really can launch the rockets. Suppose T
> > has a Num instance whose fromInteger uses unsafePerformIO to launch the
> > rockets. Then including T in an import list could make a very
> > innocent-looking `x = 5` declaration launch the rockets.
> >
> > * GHC currently supports an option -ddump-minimal-imports, which
> > displays import lists describing what symbols must be brought into
> > scope from an imported module. If a `import M` import statement brought
> > defaulting behavior into scope, then going from `import M` to `import M
> > (foo, bar)` might deleteriously change defaulting behavior, thus
> > invalidating the work of -ddump-minimal-imports.
> >
> > * The proposal as written does not describe how `module` exports work
> > with named defaults. For example, what happens in `module B (module A)
> > where import A`? Normally, that re-exports all names in scope both as
> > `A.blah` and as `blah`. But, of course, a default isn't named in this
> > way. So is the default exported? By requiring explicit inclusion in the
> > export list, the Private strategy sidesteps this question.
> >
> > * This is a more conservative choice. We can always revisit this in the
> > light of experience. However, if defaults were always imported, it
> > would be much more disruptive to make them imported only by request.
> >
> > We have rightly identified that using the Private strategy would
> > potentially reduce the usefulness of this idea, especially with
> > alternative Preludes. As far as I know, GHC does not currently
> > officially support having an alternative Prelude. That is, an
> > "alternative Prelude" is really just disabling the import of
> > base.Prelude and then importing some other module. However, we could
> > imagine a compiler flag that specifies another package (or module name)
> > to use as the Prelude... and then we could also specify how it is
> > imported. For example, we could say that the Prelude is imported with
> >
> > > import Prelude
> > > import Prelude ( default(..) )
> >
> > where the second line says to grab all the defaults. I think this would
> > be reasonable, but not necessary in the first version of this current
> > proposal.
> >
> > Richard
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7C4209473397bb4a1e123d08d957dc5f41%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637637426303892149%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=UhgwhcfU2P5%2BBwQX0lokFK8wIlFnW5RC%2BdSCg24oSzE%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/20210820/f033012a/attachment-0001.html>