[ghc-steering-committee] #283: Local modules (again), recommendation: accept

Sat Jul 24 11:47:22 UTC 2021

OK I finished reading it again. Overall I like it because it's just name
resolution; this is entirely in keeping with Haskell as it stands, and
limits the interaction with current and future language features. As a
smooth extension of the language I think it works nicely.

I rather like the idea of "data qualified" and "class qualified", perhaps
because similar ideas work out quite well in other languages (e.g. C++).

Just one thing concerns me. I don't think this is necessarily a blocker,
but it makes me vaguely uneasy.

Currently, if I see an identifier "M.x", I can search for "M" and be sure
to find it in the import list somewhere, either as "import M" or "import X
as M". I suspect a lot of people rely on this, and some coding styles
strongly encourage the use of qualified names for this reason. Exporting
qualified names and unfortunately breaks this property - any import can
bring into scope qualified names.

The property could be recovered by requiring the explicit import of
qualified names (import Data.Set (module Set, ..) or something like that)
but that doesn't seem very appealing either. Curious whether other people
are worried about this and/or have any suggestions.

Cheers
Simon

On Fri, 23 Jul 2021 at 11:00, Simon Marlow <marlowsd at gmail.com> wrote:

> 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!
>
> I think a deadline is a good idea.
>
> Cheers
> Simon
>
> On Fri, 23 Jul 2021 at 07:23, Spiwack, Arnaud <arnaud.spiwack at tweag.io>
> wrote:
>
>> Dear all,
>>
>> I know that this proposal is a bit long, but it also deserves your
>> attention.
>>
>> 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?
>>
>> ---
>>
>> Recapitulating the opinions so far
>>
>>    - I'm personally pretty enthusiastic about the entire proposal
>>    - Tom voiced quite enthusiastic support for what Simon PJ calls (1),
>>    and (3)
>>    - Simon PJ wants (1), is not against (2), is mildly against (3)
>>    - Joachim suspends his judgement (which is fine, but hopefully not
>>    too many of us do this :-) ).
>>
>>
>> On Wed, Jul 21, 2021 at 2:30 PM Simon Peyton Jones <simonpj at microsoft.com>
>> wrote:
>>
>>> To be clear, I’m ok with (1), luke-warm on (2), and mildly against (3)
>>>
>>>    1. Import and export of qualified names. This seems like the Main
>>>    Point.
>>>    2. Local import (in a let/where). This seems low pain but low gain.
>>>    3. Local modules. This is the one I'm struggling with.
>>>
>>> There is  more on the (tail end of the) PR
>>> https://github.com/ghc-proposals/ghc-proposals/pull/283
>>>
>>>
>>>
>>> I am open to being educated.
>>>
>>>
>>> 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).
>>>
>>>
>>>
>>> One mechanism (if my categorisation is correct) could be to ask everyone
>>> to vote (yes/no/maybe) on all of 1,2,3.
>>>
>>>
>>>
>>> Arnaud, you are our shepherd.  Your sheep await your command.
>>>
>>>
>>>
>>> Simon
>>>
>>>
>>>
>>> *From:* ghc-steering-committee <
>>> ghc-steering-committee-bounces at haskell.org> *On Behalf Of *Richard
>>> Eisenberg
>>> *Sent:* 19 July 2021 21:18
>>> *To:* Spiwack, Arnaud <arnaud.spiwack at tweag.io>
>>> *Cc:* GHC Steering Committee <ghc-steering-committee at haskell.org>
>>> *Subject:* Re: [ghc-steering-committee] #283: Local modules (again),
>>> recommendation: accept
>>>
>>>
>>>
>>> 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.
>>>
>>>
>>>
>>> Thanks!
>>>
>>> Richard
>>>
>>>
>>>
>>> On Jun 11, 2021, at 3:05 AM, Spiwack, Arnaud <arnaud.spiwack at tweag.io>
>>> wrote:
>>>
>>>
>>>
>>> Dear all,
>>>
>>>
>>>
>>> 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.
>>>
>>>
>>>
>>> This is an important proposal, I'm keen on seeing its design finalised.
>>>
>>>
>>>
>>> /Arnaud
>>>
>>>
>>>
>>> On Wed, May 26, 2021 at 2:35 PM Richard Eisenberg <rae at richarde.dev>
>>> wrote:
>>>
>>>
>>>
>>>
>>>
>>> On May 26, 2021, at 3:28 AM, Spiwack, Arnaud <arnaud.spiwack at tweag.io>
>>> wrote:
>>>
>>>
>>>
>>> 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.
>>>
>>>
>>>
>>> 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.
>>>
>>>
>>>
>>> Richard
>>>
>>>
>>>
>>>
>>>
>>> On Tue, May 25, 2021 at 11:54 PM Richard Eisenberg <rae at richarde.dev>
>>> wrote:
>>>
>>>
>>>
>>>
>>>
>>> On May 25, 2021, at 3:09 PM, Alejandro Serrano Mena <trupill at gmail.com>
>>> wrote:
>>>
>>>
>>>
>>> - I am not sure of the benefit of allowing (1), compared with the
>>> possible surprise of users.
>>>
>>> - I do not fully understand (2).
>>>
>>> - I think (3) would be great, if we ensure that nothing changes if I
>>> don’t use “qualified”, even if -XLocalModules is on.
>>>
>>>
>>>
>>> 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.
>>>
>>>
>>>
>>> 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:
>>>
>>>
>>>
>>> import Data.Set as Set ( abcde )
>>>
>>>
>>>
>>> data Set = Mk { abcdf :: Int }
>>>
>>>
>>>
>>> blah = Set.abcdf
>>>
>>>
>>>
>>> Previously, GHC would have suggested that you perhaps misspelled abcde.
>>> Now, you'll get (presumably) a type error.
>>>
>>>
>>>
>>> Here's another case:
>>>
>>>
>>>
>>> import Data.Set as Set ( Set )
>>>
>>>
>>>
>>> data Set = Mk
>>>
>>>
>>>
>>> x :: Set.Set
>>>
>>>
>>>
>>> Everything is happy today, but with -XLocalModules (and (3)), the type
>>> of x is an ambiguous name.
>>>
>>>
>>>
>>> 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.
>>>
>>>
>>>
>>> I, too, could live without (2).
>>>
>>>
>>>
>>> Richard
>>>
>>>
>>>
>>>
>>>
>> _______________________________________________
>> 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/20210724/96a08a35/attachment.html>