<div dir="auto">I am also happy with that solution.</div><div dir="auto"><br></div><div dir="auto">Regards,</div><div dir="auto">Alejandro</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">El El vie, 20 ago 2021 a las 4:13, Richard Eisenberg <<a href="mailto:lists@richarde.dev">lists@richarde.dev</a>> escribió:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space">I'm happy with this. Thanks!</div><div style="word-wrap:break-word;line-break:after-white-space"><div><br></div><div>Richard<br><div><br><blockquote type="cite"><div>On Aug 19, 2021, at 9:25 AM, Eric Seidel <<a href="mailto:eric@seidel.io" target="_blank">eric@seidel.io</a>> wrote:</div><br><div><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;float:none;display:inline!important">Dear Committee,</span><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><br></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none">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. </div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><br></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none">The proposal will introduce a single new extension NamedDefaults that enables:</div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><br></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none">1. The ‘default C (T1, T2, …)’ syntax that specifies the defaulted class. </div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none">2. Exporting defaulting rules as discussed (explicitly, in the export list). </div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><br></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none">Defaulting rules are always imported (implicitly), with no need to enable the NamedDefaults extension. </div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><br></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none">Any objections?<br><br><div dir="ltr">Sent from my iPhone</div><div dir="ltr"><br><blockquote type="cite">On Aug 14, 2021, at 12:58, Simon Peyton Jones <<a href="mailto:simonpj@microsoft.com" target="_blank">simonpj@microsoft.com</a>> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div><div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif"><span>Eric<u></u><u></u></span></div><div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif"><span><u></u> <u></u></span></div><div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif"><span>I’m in support too – but I have added three small qns to the GitHub thread.<u></u><u></u></span></div><div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif"><span><br>Simon<u></u><u></u></span></div><div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif"><span><u></u> <u></u></span></div><div style="border-style:none none none solid;border-left-width:1.5pt;border-left-color:blue;padding:0cm 0cm 0cm 4pt"><div><div style="border-style:solid none none;border-top-width:1pt;border-top-color:rgb(225,225,225);padding:3pt 0cm 0cm"><div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif"><b><span lang="EN-US">From:</span></b><span lang="EN-US"><span> </span>ghc-steering-committee <<a href="mailto:ghc-steering-committee-bounces@haskell.org" target="_blank">ghc-steering-committee-bounces@haskell.org</a>><span> </span><b>On Behalf Of<span> </span></b>Spiwack, Arnaud<br><b>Sent:</b><span> </span>05 August 2021 07:43<br><b>To:</b><span> </span>Eric Seidel <<a href="mailto:eric@seidel.io" target="_blank">eric@seidel.io</a>><br><b>Cc:</b><span> </span><a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br><b>Subject:</b><span> </span>Re: [ghc-steering-committee] #409: Exportable named defaults, Recommendation: Accept<u></u><u></u></span></div></div></div><div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div><p class="MsoNormal" style="margin:0cm 0cm 6pt;font-size:11pt;font-family:Calibri,sans-serif">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.<u></u><u></u></p></div><p class="MsoNormal" style="margin:0cm 0cm 6pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></p><div><div><p class="MsoNormal" style="margin:0cm 0cm 6pt;font-size:11pt;font-family:Calibri,sans-serif">On Tue, Aug 3, 2021 at 4:10 AM Eric Seidel <<a href="mailto:eric@seidel.io" style="color:blue;text-decoration:underline" target="_blank">eric@seidel.io</a>> wrote:<u></u><u></u></p></div><blockquote style="border-style:none none none solid;border-left-width:1pt;border-left-color:rgb(204,204,204);padding:0cm 0cm 0cm 6pt;margin-left:4.8pt;margin-right:0cm"><p class="MsoNormal" style="margin:0cm 0cm 6pt;font-size:11pt;font-family:Calibri,sans-serif">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<span> </span><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]:<span> </span><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" style="color:blue;text-decoration:underline" 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>> <span> </span><br>> I have added this as a comment in the GitHub repo, since others may<span> </span><br>> want to express an opinion<br>> <span> </span><br>> Simon<br>> <span> </span><br>> *From:* ghc-steering-committee<span> </span><br>> <<a href="mailto:ghc-steering-committee-bounces@haskell.org" style="color:blue;text-decoration:underline" target="_blank">ghc-steering-committee-bounces@haskell.org</a>> *On Behalf Of *Richard<span> </span><br>> Eisenberg<br>> *Sent:* 11 July 2021 02:48<br>> *To:* Eric Seidel <<a href="mailto:eric@seidel.io" style="color:blue;text-decoration:underline" target="_blank">eric@seidel.io</a>><br>> *Cc:*<span> </span><a href="mailto:ghc-steering-committee@haskell.org" style="color:blue;text-decoration:underline" target="_blank">ghc-steering-committee@haskell.org</a><br>> *Subject:* Re: [ghc-steering-committee] #409: Exportable named<span> </span><br>> defaults, Recommendation: Partial Accept<br>> <span> </span><br>> <span> </span><br>><span> </span><br>><span> </span><br>> > On Jul 9, 2021, at 12:35 AM, Eric Seidel <<a href="mailto:eric@seidel.io" style="color:blue;text-decoration:underline" target="_blank">eric@seidel.io</a>> wrote:<br>> > <span> </span><br>> > On Thu, Jul 1, 2021, at 13:16, Joachim Breitner wrote:<br>> ><span> </span><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>> ><span> </span><br>> > Not entirely, I think.<span> </span><br>> ><span> </span><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>> <span> </span><br>> This doesn't match my understanding of the proposal. It looks to me<span> </span><br>> that, as written in the proposal, exports of a `default` would have to<span> </span><br>> be explicit. That is, a module starting with `module M where ...` would<span> </span><br>> not export any defaults. This fact is a bit implied in the proposal<span> </span><br>> ("This proposal does not modify that behaviour: a `default` declaration<span> </span><br>> by itself does not apply outside its module."), but it's my best<span> </span><br>> understanding.<span> </span><br>> <span> </span><br>> ---<br>> <span> </span><br>> Simon and I have discussed. We both came to an agreement that imports<span> </span><br>> should have to be explicit.<br>> <span> </span><br>> GHC currently has two import/export strategies.<br>> <span> </span><br>> Strategy 1: Always. In the Always strategy, an entity is always<span> </span><br>> exported from a module and always brought into scope from an imported<span> </span><br>> module. The Always strategy is used for type and class instances.<br>> <span> </span><br>> Strategy 2: Public. In the Public strategy, an entity is exported by<span> </span><br>> default (no export list) or when explicitly included in an export list.<span> </span><br>> It is brought into scope from an importing module by default (no import<span> </span><br>> list) or when explicitly included in an import list. A Public entity<span> </span><br>> may be excluded from scope by a `hiding` clause. All top-level named<span> </span><br>> entities are exported/imported via the Public strategy.<br>> <span> </span><br>> I propose (with Simon's support)<br>> <span> </span><br>> Strategy 3: Private. In the Private strategy. an entity is exported<span> </span><br>> only when explicitly included in an export list, and it is brought into<span> </span><br>> scope from an imported module only when explicitly included in the<span> </span><br>> import list. I propose we use Private for `default` declarations (only).<br>> <span> </span><br>> Reasons:<br>> <span> </span><br>> * Changing defaulting behavior really can launch the rockets. Suppose T<span> </span><br>> has a Num instance whose fromInteger uses unsafePerformIO to launch the<span> </span><br>> rockets. Then including T in an import list could make a very<span> </span><br>> innocent-looking `x = 5` declaration launch the rockets.<br>> <span> </span><br>> * GHC currently supports an option -ddump-minimal-imports, which<span> </span><br>> displays import lists describing what symbols must be brought into<span> </span><br>> scope from an imported module. If a `import M` import statement brought<span> </span><br>> defaulting behavior into scope, then going from `import M` to `import M<span> </span><br>> (foo, bar)` might deleteriously change defaulting behavior, thus<span> </span><br>> invalidating the work of -ddump-minimal-imports.<br>> <span> </span><br>> * The proposal as written does not describe how `module` exports work<span> </span><br>> with named defaults. For example, what happens in `module B (module A)<span> </span><br>> where import A`? Normally, that re-exports all names in scope both as<span> </span><br>> `A.blah` and as `blah`. But, of course, a default isn't named in this<span> </span><br>> way. So is the default exported? By requiring explicit inclusion in the<span> </span><br>> export list, the Private strategy sidesteps this question.<br>> <span> </span><br>> * This is a more conservative choice. We can always revisit this in the<span> </span><br>> light of experience. However, if defaults were always imported, it<span> </span><br>> would be much more disruptive to make them imported only by request.<br>> <span> </span><br>> We have rightly identified that using the Private strategy would<span> </span><br>> potentially reduce the usefulness of this idea, especially with<span> </span><br>> alternative Preludes. As far as I know, GHC does not currently<span> </span><br>> officially support having an alternative Prelude. That is, an<span> </span><br>> "alternative Prelude" is really just disabling the import of<span> </span><br>> base.Prelude and then importing some other module. However, we could<span> </span><br>> imagine a compiler flag that specifies another package (or module name)<span> </span><br>> to use as the Prelude... and then we could also specify how it is<span> </span><br>> imported. For example, we could say that the Prelude is imported with<br>> <span> </span><br>> > import Prelude<br>> > import Prelude ( default(..) )<br>> <span> </span><br>> where the second line says to grab all the defaults. I think this would<span> </span><br>> be reasonable, but not necessary in the first version of this current<span> </span><br>> proposal.<br>> <span> </span><br>> Richard<br>_______________________________________________<br>ghc-steering-committee mailing list<br><a href="mailto:ghc-steering-committee@haskell.org" style="color:blue;text-decoration:underline" 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" style="color:blue;text-decoration:underline" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><u></u><u></u></p></blockquote></div></div></div></div></blockquote></div><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;float:none;display:inline!important">_______________________________________________</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;float:none;display:inline!important">ghc-steering-committee mailing list</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;float:none;display:inline!important"><a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a></span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;float:none;display:inline!important"><a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a></span></div></blockquote></div><br></div></div>_______________________________________________<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://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div></div>