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

[Richard Eisenberg]

> 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 <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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210526/6773b42a/attachment.html>