[ghc-steering-committee] #409: Exportable named defaults, Recommendation: Accept
Eric Seidel
eric at seidel.io
Fri Oct 1 02:17:13 UTC 2021
Hi all,
Following a bit more back and forth on the details, I have accepted the proposal.
Thanks!
On Fri, Aug 20, 2021, at 10:26, Alejandro Serrano Mena wrote:
> 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
More information about the ghc-steering-committee
mailing list