[ghc-steering-committee] #283: Local modules (again), recommendation: accept
Richard Eisenberg
rae at richarde.dev
Mon Jul 26 16:55:21 UTC 2021
Hi Alejandro,
This distinction between top-level module and local module is pretty superficial. I've added a new bit to the proposal to explain this:
> This proposal describes top-level modules as distinct from local modules, but this distinction has little import. Here is the full set of differences between these concepts:
>
> The module keyword for a top-level module is the first lexeme in a file; the module keyword for a local module must not be the first lexeme in a file.
> A top-level module can have import statements; a local module can have only import module statements.
> An import statement can name only a top-level module, not a local module.
> That's it! If you like, you can think of a import X statement as a combination of import qualified X and import module X statement: the first loads the external compilation unit named X (in a file X.hs) and brings lots of X.blah entities into scope, and the second removes the X. qualification.
>
> Another way to think about this is that there is really no distinction between top-level modules and local modules, but there is a distinction between a compilation unit and a module. An import statement names a compilation unit, granting access to any modules it contains. Haskell separately has two restrictions:
>
> Every compilation unit must contain exactly one module (which may contain other modules); the compilation unit must have the same name as its one module.
> import statements must go before all other statements (except, optionally, for a module header) in a compilation unit (in order to support finding dependencies while parsing only a prefix of a file).
I hope this helps!
Richard
> On Jul 23, 2021, at 7:16 AM, Alejandro Serrano Mena <trupill at gmail.com> wrote:
>
> 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 <mailto: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 <mailto: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 <mailto:simonpj at microsoft.com>> wrote:
> To be clear, I’m ok with (1), luke-warm on (2), and mildly against (3)
>
> Import and export of qualified names. This seems like the Main Point.
> Local import (in a let/where). This seems low pain but low gain.
> 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 <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 <mailto: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 <mailto:arnaud.spiwack at tweag.io>>
> Cc: GHC Steering Committee <ghc-steering-committee at haskell.org <mailto: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 <mailto: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 <mailto:rae at richarde.dev>> wrote:
>
>
>
>
>
>
> On May 26, 2021, at 3:28 AM, Spiwack, Arnaud <arnaud.spiwack at tweag.io <mailto: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 <mailto:rae at richarde.dev>> wrote:
>
>
>
>
>
>
> On May 25, 2021, at 3:09 PM, Alejandro Serrano Mena <trupill at gmail.com <mailto: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 <mailto:ghc-steering-committee at haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <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/20210726/69708f2f/attachment-0001.html>
More information about the ghc-steering-committee
mailing list