Re: [ghc-steering-committee] #409: Exportable named defaults, Recommendation: Accept

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 escribió:

...

I'm happy with this. Thanks!

Richard

...

On Aug 19, 2021, at 9:25 AM, Eric Seidel 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 wrote:

 Eric____ __ __ I’m in support too – but I have added three small qns to the GitHub thread.____

Simon____ __ __ *From:* ghc-steering-committee *On Behalf Of *Spiwack, Arnaud *Sent:* 05 August 2021 07:43 *To:* Eric Seidel *Cc:* ghc-steering-committee@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 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-8823387... 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 *On Behalf Of *Richard Eisenberg *Sent:* 11 July 2021 02:48 *To:* Eric Seidel *Cc:* ghc-steering-committee@haskell.org *Subject:* Re: [ghc-steering-committee] #409: Exportable named defaults, Recommendation: Partial Accept

> On Jul 9, 2021, at 12:35 AM, Eric Seidel 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@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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee