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

Tue Jul 27 16:01:43 UTC 2021

On Mon, 26 Jul 2021 at 18:08, Richard Eisenberg <rae at richarde.dev> wrote:

>
> 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:
>
> interpretImpItem('import' 'module' modids impspec, export_env)
>   = interpretImpSpec(impspec, strip(modids, export_env))
> interpretImpItem('import' 'module' modids, export_env)
>   = strip(modids, export_env)
>
>
> Now, we could say
>
> > import qualified Data.Set ( import module Set ) as S
>
> which would bring e.g. `S.Set` and `S.fromList` into scope.
>
> 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.
>

As you say, you can do this using the proposal as is:

module qualified S (module Set) where import Data.Set

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)

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.

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.

Cheers
Simon

>
> Richard
>
>
>
> 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/20210727/e8b47386/attachment.html>