[ghc-steering-committee] #283: Local modules (again), recommendation: accept
Simon Peyton Jones
simonpj at microsoft.com
Mon Jul 26 21:38:41 UTC 2021
I hope this helps!
Alas it leaves me even more confused.
Now there are three concepts in play
* local module
* top-level module
* compilation unit
I think that perhaps top-level module = compilation unit.
But no, you say "there is really no distinction between top-level modules and local modules, but there is a distinction between a compilation unit and a module".
So you seem to be saying "top-level module = local module". But then you say "An import statement can name only a top-level module, not a local module." suggesting that local modules and top level modules are not the same after all.
I'm sorry, but I'm pretty baffled
Simon
From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On Behalf Of Richard Eisenberg
Sent: 26 July 2021 17:55
To: Alejandro Serrano Mena <trupill at gmail.com>
Cc: GHC Steering Committee <ghc-steering-committee at haskell.org>
Subject: Re: [ghc-steering-committee] #283: Local modules (again), recommendation: accept
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:
1. 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.
2. A top-level module can have import statements; a local module can have only import module statements.
3. 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:
1. 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.
2. 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).
1. I hope this helps!
Richard
On Jul 23, 2021, at 7:16 AM, Alejandro Serrano Mena <trupill at gmail.com<mailto: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)
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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F283&data=04%7C01%7Csimonpj%40microsoft.com%7C46ab11d6561e40b7dfb608d9505636f2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637629154431063086%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=IL2LIK2SWo9Idqrip5I1IQy9pvt02v0tfP9pDmIPV5w%3D&reserved=0>
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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7C46ab11d6561e40b7dfb608d9505636f2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637629154431073081%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=7j7afOKKTr63mDs95flG53ii7eo6QSjSFyRdOvp1MUU%3D&reserved=0>
_______________________________________________
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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7C46ab11d6561e40b7dfb608d9505636f2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637629154431083081%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=bOtq6xjhCSuB8aPjr4K2lftRJIRtpGOQ9wyLY%2Fhn1q8%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210726/b8430b32/attachment-0001.html>
More information about the ghc-steering-committee
mailing list