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

Fri Jul 23 11:16:12 UTC 2021

 Re-reading the thread has made me aware of the distinction introduced by
this proposal between “top-level” and “local modules”, which I do not fully
grasp. I was under the impression that this was working more on the
syntactic level (so if I write `module X where module Y where` this is
similar to `module X.Y where`), and the specification was about sorting out
how this works, but now I’m surprised about this new concept.

Regards,
Alejandro

El 23 jul 2021 12:00:40, Simon Marlow <marlowsd at gmail.com> escribió:

> 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
>>
> _______________________________________________
> 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/20210723/f105d1dc/attachment-0001.html>