[ghc-steering-committee] #216: Qualified Do again, recommendation: accept the alternative

[Eric Seidel]

That’s what I thought, but thankfully Joachim has clarified that the module has to be explicitly imported, the only question is whether the identifiers have to be brought in scope as part of the import.

Sent from my iPhone

> On Apr 16, 2020, at 07:12, Simon Marlow <marlowsd at gmail.com> wrote:
> 
> 
>> On Tue, 14 Apr 2020 at 16:00, Eric Seidel <eric at seidel.io> wrote:
>> 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?
> 
> 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.
> 
> Cheers
> Simon
> 
>> 
>> Apart from that possible concern, I support both of Joachim's recommendations. 
>> 
>> On Tue, Apr 14, 2020, at 03:47, Richard Eisenberg wrote:
>> > About whether names must be in scope (only):
>> > 
>> > What do module prefixes in code mean? I claim: they refer to a set of 
>> > in-scope identifiers. That's it. Because of the way Haskell allows 
>> > module aliasing, they do not refer to, say, a compilation unit, or some 
>> > `module` structure. A module prefix identifies just a flat set of 
>> > identifiers. This "set" view works nicely both with module aliasing and 
>> > the way that Haskell specifies what "module M" means in an export list.
>> > 
>> > Since a module prefix refers to a set of in-scope identifiers, it seems 
>> > to make sense only to have the same meaning with M.do syntax. With the 
>> > "identifiers do not need to be in scope" approach, then the M in M.do 
>> > is now referring, I think, to a set of `module` structures that have 
>> > been aliased to M in the import list. We then have to look in the 
>> > export lists of each of those modules to see what is available. And 
>> > what if multiple modules in the same set have bind operators in their 
>> > export lists? That would be ambiguous, I suppose. Now, what if multiple 
>> > modules in the module set export disjoint subsets of the operators? 
>> > (For example, we have `import M1 as M` and `import M2 as M`, where `M1` 
>> > exports `(>>)` and `M2` exports `(>>=)`.) I suppose we'd combine them. 
>> > My problem is that we would have to specify all of these rules with the 
>> > "out of scope" interpretation. With the in-scope interpretation, all of 
>> > these answers follow directly from the specification. Much simpler!
>> > 
>> > All that said, it seems the majority favor the out-of-scope 
>> > interpretation. I truly don't feel strongly and am happy to go with 
>> > that. I just wanted to expand my argument slightly to see if it won any 
>> > of you over.
>> > 
>> > Richard
>> > 
>> > > On Apr 14, 2020, at 7:58 AM, Spiwack, Arnaud <arnaud.spiwack at tweag.io> wrote:
>> > > 
>> > > 
>> > > 
>> > > On Fri, Apr 10, 2020 at 10:43 AM Joachim Breitner <mail at joachim-breitner.de> wrote:
>> > >> I am surprised this is so controversial. There are many things in
>> > >>  Haskell that are used that are not imported: 
>> > >> 
>> > >>  * The desugaring of plain do notation (!)
>> > >>  * The desugaring of if-then-else (no need to have True/False in scope)
>> > >>  * The desugaring of boolean guards
>> > >>  (again, no need to have True/False in scope)
>> > >>  * Instances
>> > >>  * And because of that, `foo.bar` according to RecordDotSyntax will
>> > >>  not require `bar` to be in scope, as this is just an 
>> > >>  instance accessed via HasField "bar" (if I am not mistaken)
>> > >> 
>> > >>  In contrast, there is nothing where you have to import some `foo` when
>> > >>  you don't actually mention `foo` in your source code.
>> > >> 
>> > >>  Which seems a pretty reasonable rule:
>> > >>  Import the things you write; no more, no less!
>> > > 
>> > > 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.
>> > > 
>> > > 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.
>> > >  _______________________________________________
>> > > ghc-steering-committee mailing list
>> > > ghc-steering-committee at haskell.org
>> > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>> > 
>> > _______________________________________________
>> > ghc-steering-committee mailing list
>> > ghc-steering-committee at haskell.org
>> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>> >
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20200416/32fabff1/attachment-0001.html>