Please review #409: Exportable named defaults, Shepherd: Eric

newer
GHC20xx review; GHC2022 yes or no?

Joachim Breitner

4 Apr 2021 4 Apr '21

6:34 a.m.

Dear Committe, Exportable named defaults has been proposed by Mario https://github.com/ghc-proposals/ghc-proposals/pull/409 https://github.com/blamario/ghc-proposals/blob/exportable-named-default/prop... I propose Eric as the Shepherd. This did not gather a lot of attention on Github, or rather none, so Eric, maybe also consider whether this needs to be advertised more, or maybe who should be pointed to it. Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process Thanks, Joachim -- -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

Show replies by date

Eric Seidel

18 May 18 May

10:11 p.m.

New subject: #409: Exportable named defaults, Recommendation: Partial Accept

Hi all, Mario has proposed a handful of language extensions around type defaulting. 1. NamedDefaults: this extension simply allows specifying the class to default, instead of it always being Num (or a handful of other hardcoded classes if one enables ExtendedDefaultRules). The rule only applies to the current module, as usual. 2. ExportedDefaults: this extension allows exporting defaulting rules. 3. ImportedDefaults: this extension makes import declarations pull in defaulting rules implicitly, like class instances. Extensions (2) and (3) work together to provide a mechanism for sharing sets of defaulting rules across modules. It is possible to import conflicting sets of defaulting rules from different modules, in that case the conflict must be resolved manually by the importing module, with a new defaulting rule. My recommendation is that we * Accept extension (1), as it is a clear improvement over the status quo and can stand on its own. * Reject (without prejudice) extensions (2) and (3). These extensions bring considerable extra complexity and another orphan-like mechanism. There's an open question here of whether defaulting rules should be globally coherent like type classes, or if they're something different; the discussion has arguments for both sides. I'm not sure, and so I recommend we don't commit ourselves one way or the other for now. Please take a look at the proposal. Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/409 Proposal: https://github.com/blamario/ghc-proposals/blob/exportable-named-default/prop... Eric On Sun, Apr 4, 2021, at 06:34, Joachim Breitner wrote:

...

Dear Committe,

Exportable named defaults has been proposed by Mario https://github.com/ghc-proposals/ghc-proposals/pull/409 https://github.com/blamario/ghc-proposals/blob/exportable-named-default/prop...

I propose Eric as the Shepherd.

This did not gather a lot of attention on Github, or rather none, so Eric, maybe also consider whether this needs to be advertised more, or maybe who should be pointed to it.

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

Thanks, Joachim -- -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

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

Joachim Breitner

19 May 19 May

3:41 a.m.

New subject: #409: Exportable named defaults, Recommendation: Partial Accept

Hi Eric, I agree that this proposal is really two proposals that are relatively orthogonal (defaults for other type classes, and defaults across modules). Worth splitting maybe? Following your recommendation, focusing on NamedDefaults first. Indeed, if he had the ability to write default IsString (T.Text) I might have voted OverloadedStrings into Haskell2021 :-) So definitely a valuable proposal, but I think we some questions are unanswered yet. For default A (Int,String,()) default B (String,(),Int) (A t, B t) => t it says “just don't do that;”. But doesn’t that imply that, if one wants to rule out all use-site conflicts, there must be a global priority ordering of types across all defaultable type classes where each individual default clause is a subsequence of? Would it then make sense to just statically forbid such “illegal” orderings, i.e. reject if two default declarations are in scope that could lead to that? Would that rule out declarations that we’d want to allow? And then there are the multi-parameter type classes… they are discussed in the end, but not part of the proposal. I kinda feel that instead of taking one small step here, we should aim a bit higher and find something that works not just for some type classes, but most of them out there. Or at least understand why that would not be possible/desirable. That said, I don’t consider myself an expert on type class defaulting, so happy to hear other’s opinions here. Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

Richard Eisenberg

12:17 p.m.

New subject: #409: Exportable named defaults, Recommendation: Partial Accept

How does this proposal compare to https://github.com/abarbu/ghc-proposals/blob/master/proposals/0000-defaultin... https://github.com/abarbu/ghc-proposals/blob/master/proposals/0000-defaultin... ? That alternative proposal was ruled "out of scope", because it describes a plugin interface, which is out of scope of this committee. But I think it's a viable alternative to Mario's proposal here, and appears to be more powerful (although more difficult to use). I'm worried that the "out of scope" label derailed the plugins proposal, as I do not believe that further work on that idea (even though it's already implemented!) has been pursued. Richard

...

On May 18, 2021, at 10:11 PM, Eric Seidel wrote:

Hi all,

Mario has proposed a handful of language extensions around type defaulting.

1. NamedDefaults: this extension simply allows specifying the class to default, instead of it always being Num (or a handful of other hardcoded classes if one enables ExtendedDefaultRules). The rule only applies to the current module, as usual.

2. ExportedDefaults: this extension allows exporting defaulting rules.

3. ImportedDefaults: this extension makes import declarations pull in defaulting rules implicitly, like class instances.

Extensions (2) and (3) work together to provide a mechanism for sharing sets of defaulting rules across modules. It is possible to import conflicting sets of defaulting rules from different modules, in that case the conflict must be resolved manually by the importing module, with a new defaulting rule.

My recommendation is that we

* Accept extension (1), as it is a clear improvement over the status quo and can stand on its own.

* Reject (without prejudice) extensions (2) and (3). These extensions bring considerable extra complexity and another orphan-like mechanism. There's an open question here of whether defaulting rules should be globally coherent like type classes, or if they're something different; the discussion has arguments for both sides. I'm not sure, and so I recommend we don't commit ourselves one way or the other for now.

Please take a look at the proposal.

Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/409 Proposal: https://github.com/blamario/ghc-proposals/blob/exportable-named-default/prop...

Eric

On Sun, Apr 4, 2021, at 06:34, Joachim Breitner wrote:

...
Dear Committe,

Exportable named defaults has been proposed by Mario https://github.com/ghc-proposals/ghc-proposals/pull/409 https://github.com/blamario/ghc-proposals/blob/exportable-named-default/prop...

I propose Eric as the Shepherd.

This did not gather a lot of attention on Github, or rather none, so Eric, maybe also consider whether this needs to be advertised more, or maybe who should be pointed to it.

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

Thanks, Joachim -- -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

_______________________________________________ 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

Joachim Breitner

2:46 p.m.

New subject: #409: Exportable named defaults, Recommendation: Partial Accept

Hi, Am Mittwoch, den 19.05.2021, 16:17 +0000 schrieb Richard Eisenberg:

...

I'm worried that the "out of scope" label derailed the plugins proposal, as I do not believe that further work on that idea (even though it's already implemented!) has been pursued.

we could rename it to “no-decision-needed” or something like that? Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

Richard Eisenberg

4:52 p.m.

New subject: #409: Exportable named defaults, Recommendation: Partial Accept

...

On May 19, 2021, at 2:46 PM, Joachim Breitner wrote:

we could rename it to “no-decision-needed” or something like that?

Well, it depends on the subject. If someone posts a proposal describing a new field in a cabal file, that's out of scope. But somehow this plugin suggestion is different: it solves the kind of problem that other proposals solve, but the solution just happens not to fit the usual format (and is beyond our purview). So maybe we have both "no approval needed" and "out of scope", and apply them in the two different situations. All that said, I'd rather not derail this thread further: I'm still keen on figuring out whether Mario's proposal is a better way forward than using a plugin. My instinct -- especially in light of Joachim's questions earlier, which will need answers -- is that a plugin is a lower-stakes way forward. If we support the plugin architecture and we gain experience in light of it, we can consider adding a proper language feature. Richard

Eric Seidel

8:28 p.m.

New subject: #409: Exportable named defaults, Recommendation: Partial Accept

Thanks for reminding me again of this proposal, plugins actually came to my mind as well when I was writing my recommendation for Mario's proposal. - The barrier to entry is significantly raised with a plugin, both for authors and users. This is likely fine for the purpose of experimentation, but I think we should be clear that plugins are not a long-term solution here. - The flip side of the above is that we're not at all tied to any particular design in the interim. - The plugin API neatly provides a way to "export" defaulting rules, but it doesn't really seem to address the conflict-resolution aspect of Mario's proposal. If I enable multiple defaulting plugins with conflicting rules, how does defaulting work? Presumably it boils down to the order in which the plugins are installed, and I either have to manage that or write my own plugin, both of which seem painful. Mario's solution of writing another defaulting rule in the current module is much cleaner, and *more likely to actually see use*. - So I'm worried that a defaulting plugin API will be unwieldy enough that we won't see much experimentation in exactly the area I want to see experimentation, how do we share defaulting rules and resolve conflicts. - Could we write a *generic* defaulting plugin that would allow sharing user-defined rules? Maybe, I can kind of imagine how you could write dummy values that the plugin interprets as defaulting rules, and which can then be exported and imported as usual. I think that's an intriguing idea that might be lightweight enough to see use and let us experiment with different rules around sharing, coherence, and conflict resolution. Eric On Wed, May 19, 2021, at 12:17, Richard Eisenberg wrote:

...

How does this proposal compare to https://github.com/abarbu/ghc-proposals/blob/master/proposals/0000-defaultin... ? That alternative proposal was ruled "out of scope", because it describes a plugin interface, which is out of scope of this committee. But I think it's a viable alternative to Mario's proposal here, and appears to be more powerful (although more difficult to use). I'm worried that the "out of scope" label derailed the plugins proposal, as I do not believe that further work on that idea (even though it's already implemented!) has been pursued.

Richard

...
On May 18, 2021, at 10:11 PM, Eric Seidel wrote:

Hi all,

Mario has proposed a handful of language extensions around type defaulting.

1. NamedDefaults: this extension simply allows specifying the class to default, instead of it always being Num (or a handful of other hardcoded classes if one enables ExtendedDefaultRules). The rule only applies to the current module, as usual.

2. ExportedDefaults: this extension allows exporting defaulting rules.

3. ImportedDefaults: this extension makes import declarations pull in defaulting rules implicitly, like class instances.

Extensions (2) and (3) work together to provide a mechanism for sharing sets of defaulting rules across modules. It is possible to import conflicting sets of defaulting rules from different modules, in that case the conflict must be resolved manually by the importing module, with a new defaulting rule.

My recommendation is that we

* Accept extension (1), as it is a clear improvement over the status quo and can stand on its own.

* Reject (without prejudice) extensions (2) and (3). These extensions bring considerable extra complexity and another orphan-like mechanism. There's an open question here of whether defaulting rules should be globally coherent like type classes, or if they're something different; the discussion has arguments for both sides. I'm not sure, and so I recommend we don't commit ourselves one way or the other for now.

Please take a look at the proposal.

Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/409 Proposal: https://github.com/blamario/ghc-proposals/blob/exportable-named-default/prop...

Eric

On Sun, Apr 4, 2021, at 06:34, Joachim Breitner wrote:

...
Dear Committe,

Exportable named defaults has been proposed by Mario https://github.com/ghc-proposals/ghc-proposals/pull/409 https://github.com/blamario/ghc-proposals/blob/exportable-named-default/prop...

I propose Eric as the Shepherd.

This did not gather a lot of attention on Github, or rather none, so Eric, maybe also consider whether this needs to be advertised more, or maybe who should be pointed to it.

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

Thanks, Joachim -- -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

_______________________________________________ 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

Alejandro Serrano Mena

20 May 20 May

11:24 a.m.

New subject: #409: Exportable named defaults, Recommendation: Partial Accept

Hi all, I agree with the recommendations of accepting (1) and rejecting (2) and (3). The Report here ( https://www.haskell.org/onlinereport/haskell2010/haskellch4.html#x10-790004....) mentions that defaults are local to a module, and I think this is the right move, even more so since we can think of other ways of importing/exporting defaults, like plug-ins. Alejandro El 19 may 2021 4:11:48, Eric Seidel escribió:

...

Hi all,

Mario has proposed a handful of language extensions around type defaulting.

1. NamedDefaults: this extension simply allows specifying the class to default, instead of it always being Num (or a handful of other hardcoded classes if one enables ExtendedDefaultRules). The rule only applies to the current module, as usual.

2. ExportedDefaults: this extension allows exporting defaulting rules.

3. ImportedDefaults: this extension makes import declarations pull in defaulting rules implicitly, like class instances.

Extensions (2) and (3) work together to provide a mechanism for sharing sets of defaulting rules across modules. It is possible to import conflicting sets of defaulting rules from different modules, in that case the conflict must be resolved manually by the importing module, with a new defaulting rule.

My recommendation is that we

* Accept extension (1), as it is a clear improvement over the status quo and can stand on its own.

* Reject (without prejudice) extensions (2) and (3). These extensions bring considerable extra complexity and another orphan-like mechanism. There's an open question here of whether defaulting rules should be globally coherent like type classes, or if they're something different; the discussion has arguments for both sides. I'm not sure, and so I recommend we don't commit ourselves one way or the other for now.

Please take a look at the proposal.

Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/409 Proposal: https://github.com/blamario/ghc-proposals/blob/exportable-named-default/prop...

Eric

On Sun, Apr 4, 2021, at 06:34, Joachim Breitner wrote:

Dear Committe,

Exportable named defaults

has been proposed by Mario

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

https://github.com/blamario/ghc-proposals/blob/exportable-named-default/prop...

I propose Eric as the Shepherd.

This did not gather a lot of attention on Github, or rather none, so

Eric, maybe also consider whether this needs to be advertised more, or

maybe who should be pointed to it.

Please guide us to a conclusion as outlined in

https://github.com/ghc-proposals/ghc-proposals#committee-process

Thanks,

Joachim

--

--

Joachim Breitner

mail@joachim-breitner.de

http://www.joachim-breitner.de/

_______________________________________________

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

Richard Eisenberg

25 May 25 May

4:01 p.m.

New subject: #409: Exportable named defaults, Recommendation: Partial Accept

I have commented on GitHub with my thoughts here: https://github.com/ghc-proposals/ghc-proposals/pull/409#issuecomment-8482210... https://github.com/ghc-proposals/ghc-proposals/pull/409#issuecomment-8482210... Thanks, Richard

...

On May 20, 2021, at 11:24 AM, Alejandro Serrano Mena wrote:

Hi all,

I agree with the recommendations of accepting (1) and rejecting (2) and (3). The Report here (https://www.haskell.org/onlinereport/haskell2010/haskellch4.html#x10-790004.... https://www.haskell.org/onlinereport/haskell2010/haskellch4.html#x10-790004....) mentions that defaults are local to a module, and I think this is the right move, even more so since we can think of other ways of importing/exporting defaults, like plug-ins.

Alejandro

El 19 may 2021 4:11:48, Eric Seidel mailto:eric@seidel.io> escribió: Hi all,

Mario has proposed a handful of language extensions around type defaulting.

1. NamedDefaults: this extension simply allows specifying the class to default, instead of it always being Num (or a handful of other hardcoded classes if one enables ExtendedDefaultRules). The rule only applies to the current module, as usual.

2. ExportedDefaults: this extension allows exporting defaulting rules.

3. ImportedDefaults: this extension makes import declarations pull in defaulting rules implicitly, like class instances.

Extensions (2) and (3) work together to provide a mechanism for sharing sets of defaulting rules across modules. It is possible to import conflicting sets of defaulting rules from different modules, in that case the conflict must be resolved manually by the importing module, with a new defaulting rule.

My recommendation is that we

* Accept extension (1), as it is a clear improvement over the status quo and can stand on its own.

* Reject (without prejudice) extensions (2) and (3). These extensions bring considerable extra complexity and another orphan-like mechanism. There's an open question here of whether defaulting rules should be globally coherent like type classes, or if they're something different; the discussion has arguments for both sides. I'm not sure, and so I recommend we don't commit ourselves one way or the other for now.

Please take a look at the proposal.

Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/409 https://github.com/ghc-proposals/ghc-proposals/pull/409 Proposal: https://github.com/blamario/ghc-proposals/blob/exportable-named-default/prop... https://github.com/blamario/ghc-proposals/blob/exportable-named-default/prop...

Eric

On Sun, Apr 4, 2021, at 06:34, Joachim Breitner wrote:

...
Dear Committe,

Exportable named defaults has been proposed by Mario https://github.com/ghc-proposals/ghc-proposals/pull/409 https://github.com/ghc-proposals/ghc-proposals/pull/409 https://github.com/blamario/ghc-proposals/blob/exportable-named-default/prop... https://github.com/blamario/ghc-proposals/blob/exportable-named-default/prop...

I propose Eric as the Shepherd.

This did not gather a lot of attention on Github, or rather none, so Eric, maybe also consider whether this needs to be advertised more, or maybe who should be pointed to it.

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

Thanks, Joachim -- -- Joachim Breitner mail@joachim-breitner.de mailto:mail@joachim-breitner.de http://www.joachim-breitner.de/ http://www.joachim-breitner.de/

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

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

Eric Seidel

6 Jun 6 Jun

11:14 p.m.

New subject: #409: Exportable named defaults, Recommendation: Partial Accept

The response to the NamedDefaults extension has been uniformly positive, so I think we can consider that part accepted. However, we still need to make a decision about the ExportedDefaults extension. Since my original recommendation to reject this part of the proposal, I've come around to the argument that defaulting rules don't need global coherence like class instances, so explicit exports are fine. Simon PJ and Richard have also voiced support for explicit exports as suggested in the proposal. So I would like to revise my recommendation for ExportedDefaults to *accept*. That leaves the question of how defaulting rules should be imported. The two options are 1. *implicit*: all defaulting rules exported by a module M are automatically imported by *any* import of M, just like class instances. The proposal suggests doing this, and hiding it behind an `ImportedDefaults` extension, which feels unnecessary to me. 2. *explicit*: defaulting rules must be explicitly imported, using a syntax like `import M (default C)`. If we go this route, we will also need to decide whether a plain `import M` should import defaulting rules. Richard argues on GitHub that it should not, but I think that veers too far from the existing behavior of imports. Between the two, I lean towards (2) for the symmetry between explicit exports and imports, with the `import M` syntax pulling in defaulting rules. Eric On Tue, May 25, 2021, at 16:01, Richard Eisenberg wrote:

...

I have commented on GitHub with my thoughts here: https://github.com/ghc-proposals/ghc-proposals/pull/409#issuecomment-8482210...

Thanks, Richard

...
On May 20, 2021, at 11:24 AM, Alejandro Serrano Mena wrote:

Hi all,

I agree with the recommendations of accepting (1) and rejecting (2) and (3). The Report here (https://www.haskell.org/onlinereport/haskell2010/haskellch4.html#x10-790004....) mentions that defaults are local to a module, and I think this is the right move, even more so since we can think of other ways of importing/exporting defaults, like plug-ins.

Alejandro

El 19 may 2021 4:11:48, Eric Seidel escribió:

...
Hi all,

Mario has proposed a handful of language extensions around type defaulting.

1. NamedDefaults: this extension simply allows specifying the class to default, instead of it always being Num (or a handful of other hardcoded classes if one enables ExtendedDefaultRules). The rule only applies to the current module, as usual.

2. ExportedDefaults: this extension allows exporting defaulting rules.

3. ImportedDefaults: this extension makes import declarations pull in defaulting rules implicitly, like class instances.

Extensions (2) and (3) work together to provide a mechanism for sharing sets of defaulting rules across modules. It is possible to import conflicting sets of defaulting rules from different modules, in that case the conflict must be resolved manually by the importing module, with a new defaulting rule.

My recommendation is that we

* Accept extension (1), as it is a clear improvement over the status quo and can stand on its own.

* Reject (without prejudice) extensions (2) and (3). These extensions bring considerable extra complexity and another orphan-like mechanism. There's an open question here of whether defaulting rules should be globally coherent like type classes, or if they're something different; the discussion has arguments for both sides. I'm not sure, and so I recommend we don't commit ourselves one way or the other for now.

Please take a look at the proposal.

Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/409 Proposal: https://github.com/blamario/ghc-proposals/blob/exportable-named-default/prop...

Eric

On Sun, Apr 4, 2021, at 06:34, Joachim Breitner wrote:

...
Dear Committe,

Exportable named defaults has been proposed by Mario https://github.com/ghc-proposals/ghc-proposals/pull/409 https://github.com/blamario/ghc-proposals/blob/exportable-named-default/prop...

I propose Eric as the Shepherd.

This did not gather a lot of attention on Github, or rather none, so Eric, maybe also consider whether this needs to be advertised more, or maybe who should be pointed to it.

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

Thanks, Joachim -- -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

_______________________________________________ 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

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

Alejandro Serrano Mena

7 Jun 7 Jun

3:22 a.m.

New subject: #409: Exportable named defaults, Recommendation: Partial Accept

Hi everybody, The discussion in the PR has also convinced me about the advantages of being able to import/export defaults. I would like to add that there’s a in-the-middle option discussed somewhere in the PR, which is (1) + a way to hide the defaulting. Something like:

...

import Module hiding (default Num)

which I find quite natural: everything related to type classes is imported automatically, and “defaulting” goes in that “mental bucket” for me. Another concern for me is the requirement of having 3 different extensions. I know being fine-grained is great, but I think we’ve erred sometimes in the “too much” side in the past. I’ve written in the PR on that matter. Regards, Alejandro El 7 jun 2021 5:14:55, Eric Seidel escribió:

...

The response to the NamedDefaults extension has been uniformly positive, so I think we can consider that part accepted.

However, we still need to make a decision about the ExportedDefaults extension. Since my original recommendation to reject this part of the proposal, I've come around to the argument that defaulting rules don't need global coherence like class instances, so explicit exports are fine. Simon PJ and Richard have also voiced support for explicit exports as suggested in the proposal.

So I would like to revise my recommendation for ExportedDefaults to *accept*.

That leaves the question of how defaulting rules should be imported. The two options are

1. *implicit*: all defaulting rules exported by a module M are automatically imported by *any* import of M, just like class instances. The proposal suggests doing this, and hiding it behind an `ImportedDefaults` extension, which feels unnecessary to me.

2. *explicit*: defaulting rules must be explicitly imported, using a syntax like `import M (default C)`. If we go this route, we will also need to decide whether a plain `import M` should import defaulting rules. Richard argues on GitHub that it should not, but I think that veers too far from the existing behavior of imports.

Between the two, I lean towards (2) for the symmetry between explicit exports and imports, with the `import M` syntax pulling in defaulting rules.

Eric

On Tue, May 25, 2021, at 16:01, Richard Eisenberg wrote:

I have commented on GitHub with my thoughts here:

https://github.com/ghc-proposals/ghc-proposals/pull/409#issuecomment-8482210...

Thanks,

Richard

...
On May 20, 2021, at 11:24 AM, Alejandro Serrano Mena wrote:

...
...
Hi all,

...
...
I agree with the recommendations of accepting (1) and rejecting (2) and (3). The Report here ( https://www.haskell.org/onlinereport/haskell2010/haskellch4.html#x10-790004....) mentions that defaults are local to a module, and I think this is the right move, even more so since we can think of other ways of importing/exporting defaults, like plug-ins.

...
...
Alejandro

...
...
El 19 may 2021 4:11:48, Eric Seidel escribió:

...
...
Hi all,

...
...
...
...
Mario has proposed a handful of language extensions around type defaulting.

...
...
...
...
1. NamedDefaults: this extension simply allows specifying the class to default, instead of it always being Num (or a handful of other hardcoded classes if one enables ExtendedDefaultRules). The rule only applies to the current module, as usual.

...
...
...
...
2. ExportedDefaults: this extension allows exporting defaulting rules.

...
...
...
...
3. ImportedDefaults: this extension makes import declarations pull in defaulting rules implicitly, like class instances.

...
...
...
...
Extensions (2) and (3) work together to provide a mechanism for sharing sets of defaulting rules across modules. It is possible to import conflicting sets of defaulting rules from different modules, in that case the conflict must be resolved manually by the importing module, with a new defaulting rule.

...
...
...
...
My recommendation is that we

...
...
...
...
* Accept extension (1), as it is a clear improvement over the status quo and can stand on its own.

...
...
...
...
* Reject (without prejudice) extensions (2) and (3). These extensions bring considerable extra complexity and another orphan-like mechanism. There's an open question here of whether defaulting rules should be globally coherent like type classes, or if they're something different; the discussion has arguments for both sides. I'm not sure, and so I recommend we don't commit ourselves one way or the other for now.

...
...
...
...
Please take a look at the proposal.

...
...
...
...
Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/409

...
...
Proposal: https://github.com/blamario/ghc-proposals/blob/exportable-named-default/prop...

...
...
...
...
Eric

...
...
...
...
On Sun, Apr 4, 2021, at 06:34, Joachim Breitner wrote:

...
...
...
Dear Committe,

...
...
...
...
...
...
Exportable named defaults

...
...
...
has been proposed by Mario

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

...
...
...
https://github.com/blamario/ghc-proposals/blob/exportable-named-default/prop...

...
...
...
...
...
...
I propose Eric as the Shepherd.

...
...
...
...
...
...
This did not gather a lot of attention on Github, or rather none, so

...
...
...
Eric, maybe also consider whether this needs to be advertised more, or

...
...
...
maybe who should be pointed to it.

...
...
...
...
...
...
Please guide us to a conclusion as outlined in

...
...
...
https://github.com/ghc-proposals/ghc-proposals#committee-process

...
...
...
...
...
...
Thanks,

...
...
...
Joachim

...
...
...
--

...
...
...
--

...
...
...
Joachim Breitner

...
...
...
mail@joachim-breitner.de

...
...
...
http://www.joachim-breitner.de/

...
...
...
...
...
...
...
...
...
_______________________________________________

...
...
...
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

...
_______________________________________________

...
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

Richard Eisenberg

8 Jun 8 Jun

1:16 p.m.

New subject: #409: Exportable named defaults, Recommendation: Partial Accept

Thanks for this summary! As I've argued on GitHub, I feel quite strongly against silent importing of defaulting, where "silent" means that code that compiles today might continue to compile tomorrow, but with defaults imported. Route (1) in Eric's email describes the need for a new extension to allow default imports. This avoids my problem with "silent", but I don't really like it. Route (2) is most natural in its "silent" mode (as Eric argues), but I really really don't want silent mode! So my ideas on GitHub are a bit funny-shaped. I would love if someone could come up with a better solution to this all, that avoids silence while still not being as awkward as my ideas on GitHub. All that said, I won't die on this hill, if the rest of the committee opts for a choice that allows silent default imports. Maybe I'd be happy enough with a warning (on by default) that a default was silently imported; users could suppress the warning by making the default import explicit. Perhaps even better (more precise) would be a warning when a default was silently imported and a constraint of the class of the default-import were defaulted. (It might be hard to say whether the import actually changed the defaulting behavior, so I won't ask for that. It would be enough just to know that an import was about the same class as the defaulting was.) Actually, this might be the middle road we can all like. Richard

...

On Jun 6, 2021, at 11:14 PM, Eric Seidel wrote:

The response to the NamedDefaults extension has been uniformly positive, so I think we can consider that part accepted.

However, we still need to make a decision about the ExportedDefaults extension. Since my original recommendation to reject this part of the proposal, I've come around to the argument that defaulting rules don't need global coherence like class instances, so explicit exports are fine. Simon PJ and Richard have also voiced support for explicit exports as suggested in the proposal.

So I would like to revise my recommendation for ExportedDefaults to *accept*.

That leaves the question of how defaulting rules should be imported. The two options are

1. *implicit*: all defaulting rules exported by a module M are automatically imported by *any* import of M, just like class instances. The proposal suggests doing this, and hiding it behind an `ImportedDefaults` extension, which feels unnecessary to me.

2. *explicit*: defaulting rules must be explicitly imported, using a syntax like `import M (default C)`. If we go this route, we will also need to decide whether a plain `import M` should import defaulting rules. Richard argues on GitHub that it should not, but I think that veers too far from the existing behavior of imports.

Between the two, I lean towards (2) for the symmetry between explicit exports and imports, with the `import M` syntax pulling in defaulting rules.

Eric

On Tue, May 25, 2021, at 16:01, Richard Eisenberg wrote:

...
I have commented on GitHub with my thoughts here: https://github.com/ghc-proposals/ghc-proposals/pull/409#issuecomment-8482210...

Thanks, Richard

...
On May 20, 2021, at 11:24 AM, Alejandro Serrano Mena wrote:

Hi all,

I agree with the recommendations of accepting (1) and rejecting (2) and (3). The Report here (https://www.haskell.org/onlinereport/haskell2010/haskellch4.html#x10-790004....) mentions that defaults are local to a module, and I think this is the right move, even more so since we can think of other ways of importing/exporting defaults, like plug-ins.

Alejandro

El 19 may 2021 4:11:48, Eric Seidel escribió:

...
Hi all,

Mario has proposed a handful of language extensions around type defaulting.

1. NamedDefaults: this extension simply allows specifying the class to default, instead of it always being Num (or a handful of other hardcoded classes if one enables ExtendedDefaultRules). The rule only applies to the current module, as usual.

2. ExportedDefaults: this extension allows exporting defaulting rules.

3. ImportedDefaults: this extension makes import declarations pull in defaulting rules implicitly, like class instances.

Extensions (2) and (3) work together to provide a mechanism for sharing sets of defaulting rules across modules. It is possible to import conflicting sets of defaulting rules from different modules, in that case the conflict must be resolved manually by the importing module, with a new defaulting rule.

My recommendation is that we

* Accept extension (1), as it is a clear improvement over the status quo and can stand on its own.

* Reject (without prejudice) extensions (2) and (3). These extensions bring considerable extra complexity and another orphan-like mechanism. There's an open question here of whether defaulting rules should be globally coherent like type classes, or if they're something different; the discussion has arguments for both sides. I'm not sure, and so I recommend we don't commit ourselves one way or the other for now.

Please take a look at the proposal.

Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/409 Proposal: https://github.com/blamario/ghc-proposals/blob/exportable-named-default/prop...

Eric

On Sun, Apr 4, 2021, at 06:34, Joachim Breitner wrote:

...
Dear Committe,

Exportable named defaults has been proposed by Mario https://github.com/ghc-proposals/ghc-proposals/pull/409 https://github.com/blamario/ghc-proposals/blob/exportable-named-default/prop...

I propose Eric as the Shepherd.

This did not gather a lot of attention on Github, or rather none, so Eric, maybe also consider whether this needs to be advertised more, or maybe who should be pointed to it.

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

Thanks, Joachim -- -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

_______________________________________________ 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

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

Eric Seidel

8:43 p.m.

New subject: #409: Exportable named defaults, Recommendation: Partial Accept

On Tue, Jun 8, 2021, at 13:16, Richard Eisenberg wrote:

...

Perhaps even better (more precise) would be a warning when a default was silently imported and a constraint of the class of the default-import were defaulted.

I think a warning is very reasonable, but I'm not sure about turning it on by default. IMO, far and away the biggest use case for ExportedDefaults will be the myriad Prelude replacements (and maybe someday even the Prelude itself). For those use cases I think it's quite important that the import be a clean one-liner like import MyPrelude rather than import MyPrelude import MyPrelude (default IsString, default Num, ...) For other random modules that want to export defaults I feel much less strongly about the single import. Maybe that's an argument for a more baked-in way of installing a custom Prelude. Eric

Spiwack, Arnaud

11 Jun 11 Jun

6:14 a.m.

New subject: #409: Exportable named defaults, Recommendation: Partial Accept

I’m catching up here. Let me share a few thoughts: - I really want something like this (both for better OverloadedList support, and because it’s super useful in tests) - I’m rather unsure what to think about regarding the non-total priority (the fact that you can have default C (A, B); default D (B, A) and need to default a variable x with (C x, D x)). This sounds like something that must at least be specified. Am I correct that it isn’t? - There is no point in separating NamedDefaults and ExportedDefaults in two extensions - Regarding imports: in a first approximation explicit imports are useless. Having implicit imports lets me, for instance, define default IsList ([]) in the prelude, and then turn OverloadedList on in GHC2023 and not break existing programs. Yay. Explicit default imports just save me one copy-paste. Note by the way that if GHC2023 is the target, then the extension to import defaults would also have to be included in GHC2023, so, basically, ImportedDefaults is practically useless, and we should just import defaults (I don’t think a warning would make much sense for a normal default behaviour; I agree with Simon that this is not worse than importing overloaded instances). Still, there are some dark corners (I have pointed out one above, but I also find the exports and imports kind of difficult to wrap my head around). So I guess the conversation is not over quite yet. On Wed, Jun 9, 2021 at 2:44 AM Eric Seidel wrote:

...

On Tue, Jun 8, 2021, at 13:16, Richard Eisenberg wrote:

...
Perhaps even better (more precise) would be a warning when a default was silently imported and a constraint of the class of the default-import were defaulted.

I think a warning is very reasonable, but I'm not sure about turning it on by default.

IMO, far and away the biggest use case for ExportedDefaults will be the myriad Prelude replacements (and maybe someday even the Prelude itself). For those use cases I think it's quite important that the import be a clean one-liner like

import MyPrelude

rather than

import MyPrelude import MyPrelude (default IsString, default Num, ...)

For other random modules that want to export defaults I feel much less strongly about the single import. Maybe that's an argument for a more baked-in way of installing a custom Prelude.

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

Eric Seidel

16 Jun 16 Jun

10:12 p.m.

New subject: #409: Exportable named defaults, Recommendation: Partial Accept

On Fri, Jun 11, 2021, at 06:14, Spiwack, Arnaud wrote:

...

* I’m rather unsure what to think about regarding the non-total priority (the fact that you can have `default C (A, B); default D (B, A)` and need to default a variable `x` with `(C x, D x)`). This sounds like something that must at least be specified. Am I correct that it isn’t?

It is specified to be a static error, and the solution is either - define your own, consistent default rules for C and D in the current module, OR - ascribe types to the ambiguous use-sites and bypass default resolution entirely. See sections [2.5] and [5.1] in the proposal. It's a bit of a sharp edge, to be sure. But defaulting rules are anti-modular much like type classes, and I think this is the most sensible thing to do here. [2.5]: https://github.com/blamario/ghc-proposals/blob/exportable-named-default/prop... [5.1]: https://github.com/blamario/ghc-proposals/blob/exportable-named-default/prop...

...

* Regarding imports: in a first approximation explicit imports are useless. Having implicit imports lets me, for instance, define `default IsList ([])` in the prelude, and then turn `OverloadedList` on in `GHC2023` and not break existing programs.

There's a bit of a subtlety here in the use of "explicit" vs "implicit", and I'm not sure how you're using them here. We have at least three proposals for the behavior of imports. Given ``` module Defaults where default IsString (Text) ``` (A) Fully implicit (like class instances) ``` import Defaults -- imports `default IsString (Text)` import Defaults () -- imports `default IsString (Text)` ``` (B) Fully explicit (Richard's preference, I believe) ``` import Defaults -- does not import `default IsString (Text)` import Defaults () -- does not import `default IsString (Text)` import Defaults (default IsString) -- imports `default IsString (Text)` ``` (C) Like normal values ``` import Defaults -- imports `default IsString (Text)` import Defaults () -- does not import `default IsString (Text)` import Defaults (default IsString) -- imports `default IsString (Text)` ``` Since the Prelude is implicitly imported without an import list, both A and C would let you avoid an extra import. Same goes for Prelude replacements. Eric

Spiwack, Arnaud

17 Jun 17 Jun

10:08 a.m.

New subject: #409: Exportable named defaults, Recommendation: Partial Accept

On Thu, Jun 17, 2021 at 4:13 AM Eric Seidel wrote:

...

It is specified to be a static error, and the solution is either

- define your own, consistent default rules for C and D in the current module, OR - ascribe types to the ambiguous use-sites and bypass default resolution entirely.

Indeed. I'm convinced. Since the Prelude is implicitly imported without an import list, both A and

...

C would let you avoid an extra import. Same goes for Prelude replacements.

I fully agree with this statement. (I don't think that I have a preference between A and C)

Eric Seidel

20 Jun 20 Jun

10:24 p.m.

New subject: #409: Exportable named defaults, Recommendation: Partial Accept

On Thu, Jun 17, 2021, at 10:08, Spiwack, Arnaud wrote:

...

...
Since the Prelude is implicitly imported without an import list, both A and C would let you avoid an extra import. Same goes for Prelude replacements.

I fully agree with this statement. (I don't think that I have a preference between A and C)

Great, then I think we have broad support among the committee members who've participated in this discussion for some form of implicit import of defaulting rules. I recommend we treat defaulting rules like any other importable entity to match how the proposal treats them in export lists, ie given ``` module Defaults where default IsString (Text) ``` we have the following import behavior ``` import Defaults -- imports `default IsString (Text)` import Defaults () -- does not import `default IsString (Text)` import Defaults (default IsString) -- imports `default IsString (Text)` import Defaults hiding (default IsString) -- does not import `default IsString (Text)` import Defaults qualified -- imports `default IsString (Text)` ``` By my reading, Simon PJ, Joachim, Alejandro, Arnaud, and Richard (provided we have a warning) should all be happy with this path. I believe we also have broad agreement that imports need not be guarded by any extension. If you disagree please speak up! I have not heard anything from Vitaly, Cale, Tom, Simon M, or Vlad. If you have any thoughts on this proposal, please speak up now. I'll discuss the proposed changes (treating imported defaults like other importable entities, and the warning) with the author. As usual, I'll treat silence from the committee as assent, and will declare the proposal accepted next Sunday 6/27 if there are no objections. Thanks! Eric

Spiwack, Arnaud

21 Jun 21 Jun

2:59 a.m.

New subject: #409: Exportable named defaults, Recommendation: Partial Accept

Note: Richard, who is the main proponent of the explicit import idea is on holiday this week, so we will not hear from him, and should not consider his silence as approval.

...

I recommend we treat defaulting rules like any other importable entity to match how the proposal treats them in export lists

Sounds reasonable to me. On Mon, Jun 21, 2021 at 4:27 AM Eric Seidel wrote:

...

On Thu, Jun 17, 2021, at 10:08, Spiwack, Arnaud wrote:

...
...
Since the Prelude is implicitly imported without an import list, both A and C would let you avoid an extra import. Same goes for Prelude replacements.

I fully agree with this statement. (I don't think that I have a preference between A and C)

Great, then I think we have broad support among the committee members who've participated in this discussion for some form of implicit import of defaulting rules. I recommend we treat defaulting rules like any other importable entity to match how the proposal treats them in export lists, ie given

``` module Defaults where default IsString (Text) ```

we have the following import behavior

``` import Defaults -- imports `default IsString (Text)` import Defaults () -- does not import `default IsString (Text)` import Defaults (default IsString) -- imports `default IsString (Text)` import Defaults hiding (default IsString) -- does not import `default IsString (Text)` import Defaults qualified -- imports `default IsString (Text)` ```

By my reading, Simon PJ, Joachim, Alejandro, Arnaud, and Richard (provided we have a warning) should all be happy with this path. I believe we also have broad agreement that imports need not be guarded by any extension. If you disagree please speak up!

I have not heard anything from Vitaly, Cale, Tom, Simon M, or Vlad. If you have any thoughts on this proposal, please speak up now.

I'll discuss the proposed changes (treating imported defaults like other importable entities, and the warning) with the author. As usual, I'll treat silence from the committee as assent, and will declare the proposal accepted next Sunday 6/27 if there are no objections.

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

Joachim Breitner

27 Jun 27 Jun

11:39 a.m.

New subject: #409: Exportable named defaults, Recommendation: Partial Accept

Hi, Am Sonntag, dem 20.06.2021 um 22:24 -0400 schrieb Eric Seidel:

...

I recommend we treat defaulting rules like any other importable entity to match how the proposal treats them in export lists

I am not confident that I can fully predict the practical implications of this design, e.g. how well it works for people who advocate for an “explicit import lists always” style. But yes, it is a reasonable starting point. A gut feeling tells me that defaulting rules are a bit more like typeclass instances and a bit less like named entities (which you import to refer to them in your text). Alejandro voiced that feeling too. If we now add a way to mention these typeclass-instancy-thing in import and export lists, this _might_ set precendent which could eventually lead to syntax for explicitly exporting or importing type class instances. This is not a value judgment, just a thought. Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

Richard Eisenberg

29 Jun 29 Jun

10:38 p.m.

New subject: #409: Exportable named defaults, Recommendation: Partial Accept

Just to chime in now that I'm back in action: I'm reasonably happy with the final result here, but still curious about whether the new warning will be on by default or not. If it's not: then an unsuspecting user's program could drastically, silently change its meaning just by adding an import -- even if no symbol is used from that import! (I guess this is already true with overlapping instances and orphans. But that doesn't mean we should make the threat worse!) If it is: the usefulness of the extension is lessened, because any use of it will be noisy. Richard

...

On Jun 27, 2021, at 11:39 AM, Joachim Breitner wrote:

Hi,

Am Sonntag, dem 20.06.2021 um 22:24 -0400 schrieb Eric Seidel:

...
I recommend we treat defaulting rules like any other importable entity to match how the proposal treats them in export lists

I am not confident that I can fully predict the practical implications of this design, e.g. how well it works for people who advocate for an “explicit import lists always” style. But yes, it is a reasonable starting point.

A gut feeling tells me that defaulting rules are a bit more like typeclass instances and a bit less like named entities (which you import to refer to them in your text). Alejandro voiced that feeling too. If we now add a way to mention these typeclass-instancy-thing in import and export lists, this _might_ set precendent which could eventually lead to syntax for explicitly exporting or importing type class instances. This is not a value judgment, just a thought.

Cheers, Joachim

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

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

Eric Seidel

11:19 p.m.

New subject: #409: Exportable named defaults, Recommendation: Partial Accept

On Tue, Jun 29, 2021, at 22:38, Richard Eisenberg wrote:

...

Just to chime in now that I'm back in action: I'm reasonably happy with the final result here

With Richard in support, that leaves Simon PJ opposed to explicit imports [1]. So we have Richard opposed to implicit imports, Simon opposed to explicit imports, and the rest of us (I believe) amenable to either. I think we have two options at this point: we can keep trying to achieve consensus, or we can take a vote. Richard, Simon, since the two of you seem to have the strongest opinions on the import question, do you think we can reach a consensus here? I'm happy to set up a call if it would help to discuss things live.

...

but still curious about whether the new warning will be on by default or not.

I believe it should be off by default. The warning would interfere with Prelude replacements (and the Prelude itself, should it adopt ExportedDefaults), which I view as the biggest usecase for these extensions. Thanks! Eric [1]: https://github.com/ghc-proposals/ghc-proposals/pull/409#issuecomment-8648094...

Simon Peyton Jones

30 Jun 30 Jun

3:36 a.m.

New subject: #409: Exportable named defaults, Recommendation: Partial Accept

OK i've added a comment to explain the delay. Richard, you and I can discuss. Simon | -----Original Message----- | From: ghc-steering-committee On | Behalf Of Eric Seidel | Sent: 30 June 2021 04:19 | To: ghc-steering-committee@haskell.org | Subject: Re: [ghc-steering-committee] #409: Exportable named defaults, | Recommendation: Partial Accept | | On Tue, Jun 29, 2021, at 22:38, Richard Eisenberg wrote: | > Just to chime in now that I'm back in action: I'm reasonably happy | > with the final result here | | With Richard in support, that leaves Simon PJ opposed to explicit imports | [1]. So we have Richard opposed to implicit imports, Simon opposed to | explicit imports, and the rest of us (I believe) amenable to either. | | I think we have two options at this point: we can keep trying to achieve | consensus, or we can take a vote. Richard, Simon, since the two of you seem | to have the strongest opinions on the import question, do you think we can | reach a consensus here? I'm happy to set up a call if it would help to | discuss things live. | | > but still curious about whether the new warning will be on by default or | not. | | I believe it should be off by default. The warning would interfere with | Prelude replacements (and the Prelude itself, should it adopt | ExportedDefaults), which I view as the biggest usecase for these extensions. | | Thanks! | Eric | | [1]: | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com | %2Fghc-proposals%2Fghc-proposals%2Fpull%2F409%23issuecomment- | 864809405&data=04%7C01%7Csimonpj%40microsoft.com%7C5126784da503456fb1bb0 | 8d93b760db0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637606200986942832% | 7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi | LCJXVCI6Mn0%3D%7C3000&sdata=RqPy7fhDfWRyIdz7NEMWWwuWKLRRom8c%2BC3p%2BFYz | H4Q%3D&reserved=0 | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee@haskell.org | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haske | ll.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=04%7C01%7Csimonpj%40microsoft.com%7C5126784da503456fb1bb0 | 8d93b760db0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637606200986942832% | 7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi | LCJXVCI6Mn0%3D%7C3000&sdata=ePQduxulLz%2FTmpGhfRjKxRJ1bRyRdorYEYnjyR96xb | w%3D&reserved=0

Eric Seidel

9 Jul 9 Jul

12:38 a.m.

New subject: #409: Exportable named defaults, Recommendation: Partial Accept

Simon, Richard, have you had a chance to discuss? If not, I'd be happy to set up a call between the three of us. On Wed, Jun 30, 2021, at 01:36, Simon Peyton Jones wrote:

...

OK i've added a comment to explain the delay. Richard, you and I can discuss.

Simon

| -----Original Message----- | From: ghc-steering-committee On | Behalf Of Eric Seidel | Sent: 30 June 2021 04:19 | To: ghc-steering-committee@haskell.org | Subject: Re: [ghc-steering-committee] #409: Exportable named defaults, | Recommendation: Partial Accept | | On Tue, Jun 29, 2021, at 22:38, Richard Eisenberg wrote: | > Just to chime in now that I'm back in action: I'm reasonably happy | > with the final result here | | With Richard in support, that leaves Simon PJ opposed to explicit imports | [1]. So we have Richard opposed to implicit imports, Simon opposed to | explicit imports, and the rest of us (I believe) amenable to either. | | I think we have two options at this point: we can keep trying to achieve | consensus, or we can take a vote. Richard, Simon, since the two of you seem | to have the strongest opinions on the import question, do you think we can | reach a consensus here? I'm happy to set up a call if it would help to | discuss things live. | | > but still curious about whether the new warning will be on by default or | not. | | I believe it should be off by default. The warning would interfere with | Prelude replacements (and the Prelude itself, should it adopt | ExportedDefaults), which I view as the biggest usecase for these extensions. | | Thanks! | Eric | | [1]: | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com | %2Fghc-proposals%2Fghc-proposals%2Fpull%2F409%23issuecomment- | 864809405&data=04%7C01%7Csimonpj%40microsoft.com%7C5126784da503456fb1bb0 | 8d93b760db0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637606200986942832% | 7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi | LCJXVCI6Mn0%3D%7C3000&sdata=RqPy7fhDfWRyIdz7NEMWWwuWKLRRom8c%2BC3p%2BFYz | H4Q%3D&reserved=0 | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee@haskell.org | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haske | ll.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=04%7C01%7Csimonpj%40microsoft.com%7C5126784da503456fb1bb0 | 8d93b760db0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637606200986942832% | 7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi | LCJXVCI6Mn0%3D%7C3000&sdata=ePQduxulLz%2FTmpGhfRjKxRJ1bRyRdorYEYnjyR96xb | w%3D&reserved=0

Simon Peyton Jones

9:02 a.m.

New subject: #409: Exportable named defaults, Recommendation: Partial Accept

We have discussed! Richard will post our conclusions. Simon | -----Original Message----- | From: Eric Seidel | Sent: 09 July 2021 05:38 | To: Simon Peyton Jones ; Richard Eisenberg | | Cc: ghc-steering-committee@haskell.org | Subject: Re: [ghc-steering-committee] #409: Exportable named defaults, | Recommendation: Partial Accept | | Simon, Richard, have you had a chance to discuss? If not, I'd be happy to | set up a call between the three of us. | | On Wed, Jun 30, 2021, at 01:36, Simon Peyton Jones wrote: | > OK i've added a comment to explain the delay. Richard, you and I can | discuss. | > | > Simon | > | > | -----Original Message----- | > | From: ghc-steering-committee | > | On Behalf Of Eric | > | Seidel | > | Sent: 30 June 2021 04:19 | > | To: ghc-steering-committee@haskell.org | > | Subject: Re: [ghc-steering-committee] #409: Exportable named | > | defaults, | > | Recommendation: Partial Accept | > | | > | On Tue, Jun 29, 2021, at 22:38, Richard Eisenberg wrote: | > | > Just to chime in now that I'm back in action: I'm reasonably | > | happy > with the final result here | > | | > | With Richard in support, that leaves Simon PJ opposed to explicit | > | imports [1]. So we have Richard opposed to implicit imports, Simon | > | opposed to explicit imports, and the rest of us (I believe) amenable to | either. | > | | > | I think we have two options at this point: we can keep trying to | > | achieve consensus, or we can take a vote. Richard, Simon, since the | > | two of you seem to have the strongest opinions on the import | > | question, do you think we can reach a consensus here? I'm happy to | > | set up a call if it would help to discuss things live. | > | | > | > but still curious about whether the new warning will be on by | > | default or not. | > | | > | I believe it should be off by default. The warning would interfere | > | with Prelude replacements (and the Prelude itself, should it adopt | > | ExportedDefaults), which I view as the biggest usecase for these | extensions. | > | | > | Thanks! | > | Eric | > | | > | [1]: | > | | > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi | > | thub.com | > | %2Fghc-proposals%2Fghc-proposals%2Fpull%2F409%23issuecomment- | > | | > | 864809405&data=04%7C01%7Csimonpj%40microsoft.com%7C5126784da5034 | > | 56fb1bb0 | > | 8d93b760db0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63760620098 | > | 6942832% | > | 7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6 | > | Ik1haWwi | > | LCJXVCI6Mn0%3D%7C3000&sdata=RqPy7fhDfWRyIdz7NEMWWwuWKLRRom8c%2BC | > | 3p%2BFYz | > | H4Q%3D&reserved=0 | > | _______________________________________________ | > | ghc-steering-committee mailing list | > | ghc-steering-committee@haskell.org | > | | > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fma | > | il.haske | > | ll.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | > | | > | committee&data=04%7C01%7Csimonpj%40microsoft.com%7C5126784da5034 | > | 56fb1bb0 | > | 8d93b760db0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63760620098 | > | 6942832% | > | 7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6 | > | Ik1haWwi | > | LCJXVCI6Mn0%3D%7C3000&sdata=ePQduxulLz%2FTmpGhfRjKxRJ1bRyRdorYEY | > | njyR96xb | > | w%3D&reserved=0 | >

Joachim Breitner

1 Jul 1 Jul

3:16 p.m.

New subject: #409: Exportable named defaults, Recommendation: Partial Accept

Hi, Am Dienstag, dem 29.06.2021 um 23:19 -0400 schrieb Eric Seidel:

...

On Tue, Jun 29, 2021, at 22:38, Richard Eisenberg wrote:

...
Just to chime in now that I'm back in action: I'm reasonably happy with the final result here

With Richard in support, that leaves Simon PJ opposed to explicit imports [1]. So we have Richard opposed to implicit imports, Simon opposed to explicit imports, and the rest of us (I believe) amenable to either.

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? So, it doesn't really work like named things, as you don’t refer to them in code. But also the same design constraints as for type class instances applies, because there is no coherence requirement (which, unless I am mistaken, is the reason why we need no way to _not_ import an instance). That implies to me that this feature should be designed without too much allusion to existing export/import behavior, and rather basing it on what makes the feature most useful. (sorry, this mail doesn’t get more concrete that this.) Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

Eric Seidel

9 Jul 9 Jul

12:35 a.m.

New subject: #409: Exportable named defaults, Recommendation: Partial Accept

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. Some people have expressed concerns about implicitly importing defaulting rules like instances, which led to my current recommendation that we treat them *exactly* like named things on both sides. I think importing defaulting rules like named things is unlikely to cause problems in practice, so this seems like a good compromise. Richard further suggested that defaulting rules should have to be explicitly mentioned in an import list to be imported, which is a new import behavior for which we have no existing intuition to guide us. In fact, our existing intuition around import lists would actively mislead us here. So the question is not just do we adopt existing behavior or do something new. There are three options that have been proposed. 1. Adopt existing behavior exactly. 2. Combine existing behaviors in a novel way. 3. Introduce an entirely new behavior. In general, I would say that as you move from (1) to (3), you need an increasingly strong justification. I don't think I can justify (3) in this case based on Richard's concerns about module changes impacting type inference in downstream modules. Does that make sense?

Richard Eisenberg

10 Jul 10 Jul

9:47 p.m.

New subject: #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

Simon Peyton Jones

12 Jul 12 Jul

4:09 a.m.

New subject: #409: Exportable named defaults, Recommendation: Partial Accept

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 mailto:eric@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

Eric Seidel

2 Aug 2 Aug

10:09 p.m.

New subject: #409: Exportable named defaults, Recommendation: Accept

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... 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

Spiwack, Arnaud

5 Aug 5 Aug

2:42 a.m.

New subject: #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...

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

Joachim Breitner

6 Aug 6 Aug

11:11 a.m.

New subject: #409: Exportable named defaults, Recommendation: Accept

Same here

Simon Peyton Jones

14 Aug 14 Aug

1:57 p.m.

New subject: #409: Exportable named defaults, Recommendation: Accept

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 mailto:eric@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-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 mailto:ghc-steering-committee-bounces@haskell.org> *On Behalf Of *Richard Eisenberg *Sent:* 11 July 2021 02:48 *To:* Eric Seidel mailto:eric@seidel.io> *Cc:* ghc-steering-committee@haskell.orgmailto: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 mailto:eric@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@haskell.orgmailto: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

Eric Seidel

19 Aug 19 Aug

9:25 a.m.

New subject: #409: Exportable named defaults, Recommendation: Accept

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...

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

Joachim Breitner

2:05 p.m.

New subject: #409: Exportable named defaults, Recommendation: Accept

Hi, Am Donnerstag, dem 19.08.2021 um 08:25 -0500 schrieb Eric Seidel:

...

Any objections?

not from me :-) -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

Richard Eisenberg

10:13 p.m.

New subject: #409: Exportable named defaults, Recommendation: Accept

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 mailto:eric@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-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 mailto:ghc-steering-committee-bounces@haskell.org> *On Behalf Of *Richard Eisenberg *Sent:* 11 July 2021 02:48 *To:* Eric Seidel mailto:eric@seidel.io> *Cc:* ghc-steering-committee@haskell.org mailto: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 mailto:eric@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@haskell.org mailto: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

Alejandro Serrano Mena

20 Aug 20 Aug

10:26 a.m.

New subject: #409: Exportable named defaults, Recommendation: Accept

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

Eric Seidel

30 Sep 30 Sep

10:17 p.m.

New subject: #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

1327

Age (days ago)

1507

Last active (days ago)

List overview

Download

36 comments

7 participants

participants (7)

Alejandro Serrano Mena
Eric Seidel
Joachim Breitner
Richard Eisenberg
Richard Eisenberg
Simon Peyton Jones
Spiwack, Arnaud

Please review #409: Exportable named defaults, Shepherd: Eric

tags

participants (7)