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

[Simon Marlow]

On Thu, 16 Apr 2020 at 13:27, Eric Seidel <eric at seidel.io> wrote:

> 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.
>

Sorry I should have read the rest of the thread before responding. Thanks!

Simon


> 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/bd8d2a32/attachment.html>