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

[Richard Eisenberg]

> 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/20210525/5e433eff/attachment.html>