<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 14 Apr 2020 at 16:00, Eric Seidel <<a href="mailto:eric@seidel.io">eric@seidel.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">If we allow "M.do" without explicitly importing M, building the module dependency graph suddenly requires parsing the entire module rather than just the preamble. How much of a concern is this for compilation times?<br></blockquote><div><br></div><div>That would be a big deal for GHC, which currently relies on being able to parse just the header to determine the module dependency graph.</div><div><br></div><div>Cheers</div><div>Simon<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Apart from that possible concern, I support both of Joachim's recommendations. <br>
<br>
On Tue, Apr 14, 2020, at 03:47, Richard Eisenberg wrote:<br>
> About whether names must be in scope (only):<br>
> <br>
> What do module prefixes in code mean? I claim: they refer to a set of <br>
> in-scope identifiers. That's it. Because of the way Haskell allows <br>
> module aliasing, they do not refer to, say, a compilation unit, or some <br>
> `module` structure. A module prefix identifies just a flat set of <br>
> identifiers. This "set" view works nicely both with module aliasing and <br>
> the way that Haskell specifies what "module M" means in an export list.<br>
> <br>
> Since a module prefix refers to a set of in-scope identifiers, it seems <br>
> to make sense only to have the same meaning with M.do syntax. With the <br>
> "identifiers do not need to be in scope" approach, then the M in M.do <br>
> is now referring, I think, to a set of `module` structures that have <br>
> been aliased to M in the import list. We then have to look in the <br>
> export lists of each of those modules to see what is available. And <br>
> what if multiple modules in the same set have bind operators in their <br>
> export lists? That would be ambiguous, I suppose. Now, what if multiple <br>
> modules in the module set export disjoint subsets of the operators? <br>
> (For example, we have `import M1 as M` and `import M2 as M`, where `M1` <br>
> exports `(>>)` and `M2` exports `(>>=)`.) I suppose we'd combine them. <br>
> My problem is that we would have to specify all of these rules with the <br>
> "out of scope" interpretation. With the in-scope interpretation, all of <br>
> these answers follow directly from the specification. Much simpler!<br>
> <br>
> All that said, it seems the majority favor the out-of-scope <br>
> interpretation. I truly don't feel strongly and am happy to go with <br>
> that. I just wanted to expand my argument slightly to see if it won any <br>
> of you over.<br>
> <br>
> Richard<br>
> <br>
> > On Apr 14, 2020, at 7:58 AM, Spiwack, Arnaud <<a href="mailto:arnaud.spiwack@tweag.io" target="_blank">arnaud.spiwack@tweag.io</a>> wrote:<br>
> > <br>
> > <br>
> > <br>
> > On Fri, Apr 10, 2020 at 10:43 AM Joachim Breitner <<a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a>> wrote:<br>
> >> I am surprised this is so controversial. There are many things in<br>
> >>  Haskell that are used that are not imported: <br>
> >> <br>
> >>  * The desugaring of plain do notation (!)<br>
> >>  * The desugaring of if-then-else (no need to have True/False in scope)<br>
> >>  * The desugaring of boolean guards<br>
> >>  (again, no need to have True/False in scope)<br>
> >>  * Instances<br>
> >>  * And because of that, `foo.bar` according to RecordDotSyntax will<br>
> >>  not require `bar` to be in scope, as this is just an <br>
> >>  instance accessed via HasField "bar" (if I am not mistaken)<br>
> >> <br>
> >>  In contrast, there is nothing where you have to import some `foo` when<br>
> >>  you don't actually mention `foo` in your source code.<br>
> >> <br>
> >>  Which seems a pretty reasonable rule:<br>
> >>  Import the things you write; no more, no less!<br>
> > <br>
> > I wanted to add, for the record, that Joachim's argument convinced me that, indeed, were we to go for the module-qualified do approach, we probably shouldn't require the names to be in scope.<br>
> > <br>
> > However, it makes the module-qualified approach more counter-intuitive to me: it doesn't make sense to me to use the namespace `M` to refer to a term which is not in this namespace. Obviously, Joachim, you have a different intuition about this.<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://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>
> <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://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>
><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://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>