<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;
mso-fareast-language:EN-US;}
.MsoPapDefault
{mso-style-type:export-only;
margin-top:6.0pt;
margin-right:0cm;
margin-bottom:6.0pt;
margin-left:0cm;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-GB" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Eric<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">I’m in support too – but I have added three small qns to the GitHub thread.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><br>
Simon<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> ghc-steering-committee <ghc-steering-committee-bounces@haskell.org>
<b>On Behalf Of </b>Spiwack, Arnaud<br>
<b>Sent:</b> 05 August 2021 07:43<br>
<b>To:</b> Eric Seidel <eric@seidel.io><br>
<b>Cc:</b> ghc-steering-committee@haskell.org<br>
<b>Subject:</b> Re: [ghc-steering-committee] #409: Exportable named defaults, Recommendation: Accept<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
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.<o:p></o:p></p>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
On Tue, Aug 3, 2021 at 4:10 AM Eric Seidel <<a href="mailto:eric@seidel.io">eric@seidel.io</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
Committee,<br>
<br>
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<br>
<br>
1. *Implicit import*: any and all forms of `import M` also import any defaulting rules exported by M, like type classes.<br>
<br>
2. *Explicit export*: defaulting rules must be explicitly exported like named things, mostly. The one exception is that
<br>
<br>
module M (module N) where { import N }<br>
<br>
does not re-export any defaulting rules imported from N. Simon PJ argued strongly for this change on GitHub[1].<br>
<br>
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.<br>
<br>
[1]: <a href="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" target="_blank">
https://github.com/ghc-proposals/ghc-proposals/pull/409#issuecomment-882338794</a><br>
<br>
On Mon, Jul 12, 2021, at 04:09, Simon Peyton Jones wrote:<br>
> <br>
> I have added this as a comment in the GitHub repo, since others may <br>
> want to express an opinion<br>
> <br>
> Simon<br>
> <br>
> *From:* ghc-steering-committee <br>
> <<a href="mailto:ghc-steering-committee-bounces@haskell.org" target="_blank">ghc-steering-committee-bounces@haskell.org</a>> *On Behalf Of *Richard
<br>
> Eisenberg<br>
> *Sent:* 11 July 2021 02:48<br>
> *To:* Eric Seidel <<a href="mailto:eric@seidel.io" target="_blank">eric@seidel.io</a>><br>
> *Cc:* <a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
> *Subject:* Re: [ghc-steering-committee] #409: Exportable named <br>
> defaults, Recommendation: Partial Accept<br>
> <br>
> <br>
> <br>
> <br>
> > On Jul 9, 2021, at 12:35 AM, Eric Seidel <<a href="mailto:eric@seidel.io" target="_blank">eric@seidel.io</a>> wrote:<br>
> > <br>
> > On Thu, Jul 1, 2021, at 13:16, Joachim Breitner wrote:<br>
> > <br>
> >> a different way to phrase that question might be: Do we want these<br>
> >> defaulting declarations to behave just exactly like named things, or<br>
> >> exactly like typeclass instances, or do we afford a new class with it’s<br>
> >> own exporting/importing behavior. Is that a fair assessment?<br>
> > <br>
> > Not entirely, I think. <br>
> > <br>
> > We currently have two types of import/export behavior:<br>
> > named things, and typeclass instances. The proposal as currently<br>
> > written places defaulting rules somewhere in between: defaulting<br>
> > rules are exported like named things, but imported like class instances.<br>
> > This is new, but not too foreign, as the behavior on both sides exactly<br>
> > matches existing behavior we're familiar with. It's just the combination<br>
> > that's new.<br>
> <br>
> This doesn't match my understanding of the proposal. It looks to me <br>
> that, as written in the proposal, exports of a `default` would have to <br>
> be explicit. That is, a module starting with `module M where ...` would <br>
> not export any defaults. This fact is a bit implied in the proposal <br>
> ("This proposal does not modify that behaviour: a `default` declaration <br>
> by itself does not apply outside its module."), but it's my best <br>
> understanding. <br>
> <br>
> ---<br>
> <br>
> Simon and I have discussed. We both came to an agreement that imports <br>
> should have to be explicit.<br>
> <br>
> GHC currently has two import/export strategies.<br>
> <br>
> Strategy 1: Always. In the Always strategy, an entity is always <br>
> exported from a module and always brought into scope from an imported <br>
> module. The Always strategy is used for type and class instances.<br>
> <br>
> Strategy 2: Public. In the Public strategy, an entity is exported by <br>
> default (no export list) or when explicitly included in an export list. <br>
> It is brought into scope from an importing module by default (no import <br>
> list) or when explicitly included in an import list. A Public entity <br>
> may be excluded from scope by a `hiding` clause. All top-level named <br>
> entities are exported/imported via the Public strategy.<br>
> <br>
> I propose (with Simon's support)<br>
> <br>
> Strategy 3: Private. In the Private strategy. an entity is exported <br>
> only when explicitly included in an export list, and it is brought into <br>
> scope from an imported module only when explicitly included in the <br>
> import list. I propose we use Private for `default` declarations (only).<br>
> <br>
> Reasons:<br>
> <br>
> * Changing defaulting behavior really can launch the rockets. Suppose T <br>
> has a Num instance whose fromInteger uses unsafePerformIO to launch the <br>
> rockets. Then including T in an import list could make a very <br>
> innocent-looking `x = 5` declaration launch the rockets.<br>
> <br>
> * GHC currently supports an option -ddump-minimal-imports, which <br>
> displays import lists describing what symbols must be brought into <br>
> scope from an imported module. If a `import M` import statement brought <br>
> defaulting behavior into scope, then going from `import M` to `import M <br>
> (foo, bar)` might deleteriously change defaulting behavior, thus <br>
> invalidating the work of -ddump-minimal-imports.<br>
> <br>
> * The proposal as written does not describe how `module` exports work <br>
> with named defaults. For example, what happens in `module B (module A) <br>
> where import A`? Normally, that re-exports all names in scope both as <br>
> `A.blah` and as `blah`. But, of course, a default isn't named in this <br>
> way. So is the default exported? By requiring explicit inclusion in the <br>
> export list, the Private strategy sidesteps this question.<br>
> <br>
> * This is a more conservative choice. We can always revisit this in the <br>
> light of experience. However, if defaults were always imported, it <br>
> would be much more disruptive to make them imported only by request.<br>
> <br>
> We have rightly identified that using the Private strategy would <br>
> potentially reduce the usefulness of this idea, especially with <br>
> alternative Preludes. As far as I know, GHC does not currently <br>
> officially support having an alternative Prelude. That is, an <br>
> "alternative Prelude" is really just disabling the import of <br>
> base.Prelude and then importing some other module. However, we could <br>
> imagine a compiler flag that specifies another package (or module name) <br>
> to use as the Prelude... and then we could also specify how it is <br>
> imported. For example, we could say that the Prelude is imported with<br>
> <br>
> > import Prelude<br>
> > import Prelude ( default(..) )<br>
> <br>
> where the second line says to grab all the defaults. I think this would <br>
> be reasonable, but not necessary in the first version of this current <br>
> proposal.<br>
> <br>
> Richard<br>
_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="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" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><o:p></o:p></p>
</blockquote>
</div>
</div>
</div>
</body>
</html>