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

Fri Jul 23 10:00:40 UTC 2021

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/20210723/98f26ce5/attachment-0001.html>