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

[Spiwack, Arnaud]

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
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210723/2f2c02e1/attachment.html>