<div dir="ltr"><div dir="ltr"><div>Dear all,</div><div><br></div><div>First sorry I'm a bit late on this, life got in the way.<br></div><div><br></div><div>I've got opinions from both Simons, Tom, and Alejandro. Eric, Joachim, Vitaly, Vlad what do you think about all this?</div><div><br></div><div>---</div><div><br></div><div>If I were to summarise the discussion as I understand it, the major point of discussion is the difference between local modules (which are pure name-spacing entities) and global/top-level modules (which are compilation units, hence can appear in import statements for dependency management). Simon PJ has argued (in an off-band conversation with Richard and I) to embrace the difference more, though in many places in the proposal, these two kind of modules are used the same way, hence deserving the common name of “module”. Simon Marlow is worried that the lack of distinction between global module addressing and local module addressing in `A.B.C.x` can be confusing (is `A.B` a global module, or is `A` the global module and `B.C` the local module?).</div><div><br></div><div>(I'd personally argue, regarding this latter point, that it doesn't matter. By the time we are able to name `A.B.C.x` in a file, global modules may have been renamed, so we have changed a name representing a compilation unit into a namespace, which may or may not be identical. The proposal don't treat the two situations differently at all)</div><div><br></div><div>Another point of discussion which hasn't appeared on this list but has been raised in the Github thread, is that the current proposal goes to great length to make exporting `module M` more or less compatible with the current behaviour giving it a very different semantic to exporting `module qualified M` (these are currently items 4.iv, 4.v, and <a href="http://4.vi">4.vi</a> in the specification section of the proposal). Note that is not fully backwards compatible and even with existing module can export more stuff. The question is whether it is worth trying to match the existing behaviour of `module M`, or whether a simpler notion which is in line with the behaviour of `module qualified M` would be preferable.</div><div><br></div><div>Over to you :-) <br></div><div><br></div><div>/Arnaud<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jul 27, 2021 at 6:01 PM Simon Marlow <<a href="mailto:marlowsd@gmail.com" target="_blank">marlowsd@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">On Mon, 26 Jul 2021 at 18:08, Richard Eisenberg <<a href="mailto:rae@richarde.dev" target="_blank">rae@richarde.dev</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><br><div><div>One idea could be a new import item `import module M impspec` which behaves just like `module M impspec`, but without the use of `qualify` in its interpretation. In code:</div><div><br></div><div></div><blockquote type="cite"><div>interpretImpItem('import' 'module' modids impspec, export_env)</div><div>  = interpretImpSpec(impspec, strip(modids, export_env))</div><div>interpretImpItem('import' 'module' modids, export_env)</div><div>  = strip(modids, export_env)</div></blockquote><div><br></div><div>Now, we could say</div><div><br></div><div>> import qualified Data.Set ( import module Set ) as S</div><div><br></div><div>which would bring e.g. `S.Set` and `S.fromList` into scope.</div><div><br></div><div>This new `import module` import item would enable this idiom. (This is all possible with the proposal as stated, but not nearly as easily.) Would that help? Then, someone who cared about the property you want would be able to suggest a coding style that would maintain it.</div></div></div></blockquote><div><br></div><div>As you say, you can do this using the proposal as is:<br></div><div><br></div><div>module qualified S (module Set) where import Data.Set</div><div><br></div><div>so I don't think it's worth adding anything new, given that this is already quite brief. (if perhaps a little obscure, but you could imagine getting used to it)</div><div><br></div><div>But while thinking about this I realised I'm more concerned that we would have two kinds of qualification that behave in quite different ways, yet look identical. One is top-level modules, which you can bring into scoe and rename with import declarations, and the other is qualified exports which are controlled with export and import specifiers. When I refer to an identifier like A.B.C.x, zero or more of the modids come from the import declaration.</div><div><br></div><div>This is powerful, yes, but also potentially a source of great confusion. I find it hard to predict exactly how this will work out in practice.</div><br><div><br></div><div>Cheers</div><div>Simon</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><div><br></div><div>Richard</div><div><br></div><br><blockquote type="cite"><div><div dir="ltr"><div><br><div>Cheers</div><div>Simon<br></div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 23 Jul 2021 at 11:00, Simon Marlow <<a href="mailto:marlowsd@gmail.com" target="_blank">marlowsd@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Just so I'm not completely silent: in the past I was generally in favour but had some suggestions. It looks like the proposal has undergone a lot of rewrites since I last reviewed it (or perhaps I just don't remember it all that well), I've started to go through it again but this is a biggie! <br></div><div><br></div><div>I think a deadline is a good idea.<br></div><br><div>Cheers</div><div>Simon<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 23 Jul 2021 at 07:23, Spiwack, Arnaud <<a href="mailto:arnaud.spiwack@tweag.io" target="_blank">arnaud.spiwack@tweag.io</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div>Dear all,</div><div><br></div><div>I know that this proposal is a bit long, but it also deserves your attention.</div><div><br></div><div>I feel it's going to be easier to set a bit of time to review the proposal if I give a deadline. So let's say the following: I'll be on holiday starting two weeks from now (6th August), can I have everybody's opinion by then?</div><div><br></div><div>---</div><div><br></div><div>Recapitulating the opinions so far</div><div><ul><li>I'm personally pretty enthusiastic about the entire proposal</li><li>Tom voiced quite enthusiastic support for what Simon PJ calls (1), and (3)</li><li>Simon PJ wants (1), is not against (2), is mildly against (3)</li><li>Joachim suspends his judgement (which is fine, but hopefully not too many of us do this :-) ).<br></li></ul></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jul 21, 2021 at 2:30 PM Simon Peyton Jones <<a href="mailto:simonpj@microsoft.com" target="_blank">simonpj@microsoft.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">





<div lang="EN-GB">
<div><p class="MsoNormal"><span>To be clear, I’m ok with (1), luke-warm on (2), and mildly against (3)<u></u><u></u></span></p>
<ol type="1" start="1">
<li class="MsoNormal">
Import and export of qualified names. This seems like the Main Point.<u></u><u></u></li><li class="MsoNormal">
Local import (in a let/where). This seems low pain but low gain.<u></u><u></u></li><li class="MsoNormal">
Local modules. This is the one I'm struggling with.<u></u><u></u></li></ol><p class="MsoNormal"><span>There is  more on the (tail end of the) PR
<a href="https://github.com/ghc-proposals/ghc-proposals/pull/283" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/283</a><u></u><u></u></span></p><p class="MsoNormal"><span><u></u> <u></u></span></p><p class="MsoNormal"><span>I am open to being educated.<u></u><u></u></span></p><p class="MsoNormal"><span><br>
I would love to hear from other members of the committee.  Tom’s thumbs-up seemed to about (1), without saying anything about (2) and (3).<u></u><u></u></span></p><p class="MsoNormal"><span><u></u> <u></u></span></p><p class="MsoNormal"><span>One mechanism (if my categorisation is correct) could be to ask everyone to vote (yes/no/maybe) on all of 1,2,3.<u></u><u></u></span></p><p class="MsoNormal"><span><u></u> <u></u></span></p><p class="MsoNormal"><span>Arnaud, you are our shepherd.  Your sheep await your command.<u></u><u></u></span></p><p class="MsoNormal"><span><u></u> <u></u></span></p><p class="MsoNormal"><span>Simon<u></u><u></u></span></p><p class="MsoNormal"><span><u></u> <u></u></span></p>
<div style="border-color:currentcolor currentcolor currentcolor blue;border-style:none none none solid;border-width:medium medium medium 1.5pt;padding:0cm 0cm 0cm 4pt">
<div>
<div style="border-color:rgb(225,225,225) currentcolor currentcolor;border-style:solid none none;border-width:1pt medium medium;padding:3pt 0cm 0cm"><p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> ghc-steering-committee <<a href="mailto:ghc-steering-committee-bounces@haskell.org" target="_blank">ghc-steering-committee-bounces@haskell.org</a>>
<b>On Behalf Of </b>Richard Eisenberg<br>
<b>Sent:</b> 19 July 2021 21:18<br>
<b>To:</b> Spiwack, Arnaud <<a href="mailto:arnaud.spiwack@tweag.io" target="_blank">arnaud.spiwack@tweag.io</a>><br>
<b>Cc:</b> GHC Steering Committee <<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a>><br>
<b>Subject:</b> Re: [ghc-steering-committee] #283: Local modules (again), recommendation: accept<u></u><u></u></span></p>
</div>
</div><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Any thoughts on this? Simon PJ seems lukewarm (or maybe even cooler than that), Arnaud is in support, but the rest of you have been quiet.<u></u><u></u></p>
<div><p class="MsoNormal"><u></u> <u></u></p>
</div>
<div><p class="MsoNormal">Thanks!<u></u><u></u></p>
</div>
<div><p class="MsoNormal">Richard<u></u><u></u></p>
<div>
<div><p class="MsoNormal"><br>
<br>
<u></u><u></u></p>
<blockquote style="margin-top:5pt;margin-bottom:5pt">
<div><p class="MsoNormal">On Jun 11, 2021, at 3:05 AM, Spiwack, Arnaud <<a href="mailto:arnaud.spiwack@tweag.io" target="_blank">arnaud.spiwack@tweag.io</a>> wrote:<u></u><u></u></p>
</div><p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<div><p class="MsoNormal">Dear all,<u></u><u></u></p>
</div>
<div><p class="MsoNormal"><u></u> <u></u></p>
</div>
<div><p class="MsoNormal">Let me raise this proposal again. Very few of us have opined, and while I'd usually be happy to consider silence as assent, this is a rather large proposal which may require a few more pairs of eyes. Please consider giving this one a read
 and share your thoughts. If you can't do so right now, please let me know when you will be able to, so that we can plan accordingly.<u></u><u></u></p>
</div>
<div><p class="MsoNormal"><u></u> <u></u></p>
</div>
<div><p class="MsoNormal">This is an important proposal, I'm keen on seeing its design finalised.<u></u><u></u></p>
</div>
<div><p class="MsoNormal"><u></u> <u></u></p>
</div>
<div><p class="MsoNormal">/Arnaud<u></u><u></u></p>
</div>
</div><p class="MsoNormal"><u></u> <u></u></p>
<div>
<div><p class="MsoNormal">On Wed, May 26, 2021 at 2:35 PM Richard Eisenberg <<a href="mailto:rae@richarde.dev" target="_blank">rae@richarde.dev</a>> wrote:<u></u><u></u></p>
</div>
<blockquote style="border-color:currentcolor currentcolor currentcolor rgb(204,204,204);border-style:none none none solid;border-width:medium medium medium 1pt;padding:0cm 0cm 0cm 6pt;margin-left:4.8pt;margin-right:0cm">
<div><p class="MsoNormal"><u></u> <u></u></p>
<div><p class="MsoNormal"><br>
<br>
<u></u><u></u></p>
<blockquote style="margin-top:5pt;margin-bottom:5pt">
<div><p class="MsoNormal">On May 26, 2021, at 3:28 AM, Spiwack, Arnaud <<a href="mailto:arnaud.spiwack@tweag.io" target="_blank">arnaud.spiwack@tweag.io</a>> wrote:<u></u><u></u></p>
</div><p class="MsoNormal"><u></u> <u></u></p>
<div>
<div><p class="MsoNormal">I'm realising that I inverted additional options 1 and 3 in my reply. To spell things out: I'm in favour of the namespace introduced for every datatype and such; and weakly in favour of anonymous modules, for which I prefer the `_` syntax
 than simply omitting the name.<u></u><u></u></p>
</div>
</div>
</blockquote>
<div><p class="MsoNormal"><u></u> <u></u></p>
</div>
<div><p class="MsoNormal">Oh, good. I was very confused here, but I decided not to push on it. I'm similarly weakly in favor of (1), but I can't get myself to decide firmly on whether to go with alternative (7). Going with (7) is a little more consistent with other
 features, but it adds more symbols to the source text that could otherwise be omitted. So I'm pretty ambivalent.<u></u><u></u></p>
</div>
<div><p class="MsoNormal"><u></u> <u></u></p>
</div>
<div><p class="MsoNormal">Richard<u></u><u></u></p>
</div><p class="MsoNormal"><br>
<br>
<u></u><u></u></p>
<blockquote style="margin-top:5pt;margin-bottom:5pt">
<div><p class="MsoNormal"><u></u> <u></u></p>
<div>
<div><p class="MsoNormal">On Tue, May 25, 2021 at 11:54 PM Richard Eisenberg <<a href="mailto:rae@richarde.dev" target="_blank">rae@richarde.dev</a>> wrote:<u></u><u></u></p>
</div>
<blockquote style="border-color:currentcolor currentcolor currentcolor rgb(204,204,204);border-style:none none none solid;border-width:medium medium medium 1pt;padding:0cm 0cm 0cm 6pt;margin-left:4.8pt;margin-right:0cm">
<div><p class="MsoNormal"><u></u> <u></u></p>
<div><p class="MsoNormal"><br>
<br>
<u></u><u></u></p>
<blockquote style="margin-top:5pt;margin-bottom:5pt">
<div><p class="MsoNormal">On May 25, 2021, at 3:09 PM, Alejandro Serrano Mena <<a href="mailto:trupill@gmail.com" target="_blank">trupill@gmail.com</a>> wrote:<u></u><u></u></p>
</div><p class="MsoNormal"><u></u> <u></u></p>
<div>
<div><p class="MsoNormal"><span style="font-size:9pt;font-family:"Helvetica",sans-serif">- I am not sure of the benefit of allowing (1), compared with the possible surprise of users.<u></u><u></u></span></p>
</div>
<div><p class="MsoNormal"><span style="font-size:9pt;font-family:"Helvetica",sans-serif">- I do not fully understand (2).<u></u><u></u></span></p>
</div>
<div><p class="MsoNormal"><span style="font-size:9pt;font-family:"Helvetica",sans-serif">- I think (3) would be great, if we ensure that nothing changes if I don’t use “qualified”, even if -XLocalModules is on.<u></u><u></u></span></p>
</div>
</div>
</blockquote>
</div><p class="MsoNormal"><u></u> <u></u></p>
<div><p class="MsoNormal">If in the language, I would use (1) -- anonymous local modules -- regularly, when defining a function or class instance with a bunch of "local" helper functions. Of course, if we can't omit the module name, I will suffer no great harm.<u></u><u></u></p>
</div>
<div><p class="MsoNormal"><u></u> <u></u></p>
</div>
<div><p class="MsoNormal">I cannot offer the guarantee you seek in (3), but I don't think you want it. (If nothing changes, then the feature has no effect!) Here is a scenario where (3) could cause trouble:<u></u><u></u></p>
</div>
<div><p class="MsoNormal"><u></u> <u></u></p>
</div>
<blockquote style="margin-top:5pt;margin-bottom:5pt">
<div><p class="MsoNormal">import Data.Set as Set ( abcde )<u></u><u></u></p>
</div>
<div><p class="MsoNormal"><u></u> <u></u></p>
</div>
<div><p class="MsoNormal">data Set = Mk { abcdf :: Int }<u></u><u></u></p>
</div>
<div><p class="MsoNormal"><u></u> <u></u></p>
</div>
<div><p class="MsoNormal">blah = Set.abcdf<u></u><u></u></p>
</div>
</blockquote>
<div><p class="MsoNormal"><u></u> <u></u></p>
</div>
<div><p class="MsoNormal">Previously, GHC would have suggested that you perhaps misspelled abcde. Now, you'll get (presumably) a type error.<u></u><u></u></p>
</div>
<div><p class="MsoNormal"><u></u> <u></u></p>
</div>
<div><p class="MsoNormal">Here's another case:<u></u><u></u></p>
</div>
<div><p class="MsoNormal"><u></u> <u></u></p>
</div>
<blockquote style="margin-top:5pt;margin-bottom:5pt">
<div><p class="MsoNormal">import Data.Set as Set ( Set )<u></u><u></u></p>
</div>
<div><p class="MsoNormal"><u></u> <u></u></p>
</div>
<div><p class="MsoNormal">data Set = Mk<u></u><u></u></p>
</div>
<div><p class="MsoNormal"><u></u> <u></u></p>
</div>
<div><p class="MsoNormal">x :: Set.Set<u></u><u></u></p>
</div>
</blockquote>
<div><p class="MsoNormal"><u></u> <u></u></p>
</div>
<div><p class="MsoNormal">Everything is happy today, but with -XLocalModules (and (3)), the type of x is an ambiguous name.<u></u><u></u></p>
</div>
<div><p class="MsoNormal"><u></u> <u></u></p>
</div>
<div><p class="MsoNormal">Any example that causes trouble, though, will have something in common: an imported module name (possibly via an alias) that matches a locally defined type name. I would imagine this pattern is rare in practice, and that the benefit of
 (3) would outweigh the number of times that a problem like this bites.<u></u><u></u></p>
</div>
<div><p class="MsoNormal"><u></u> <u></u></p>
</div>
<div><p class="MsoNormal">I, too, could live without (2).<u></u><u></u></p>
</div>
<div><p class="MsoNormal"><u></u> <u></u></p>
</div>
<div><p class="MsoNormal">Richard<u></u><u></u></p>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div><p class="MsoNormal"><u></u> <u></u></p>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div><p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
</div>
</div>
</div>

</blockquote></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>
</blockquote></div>
</div></blockquote></div><br></div></blockquote></div></div>
</blockquote></div>
</div>