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

Spiwack, Arnaud arnaud.spiwack at tweag.io
Wed May 26 07:28:02 UTC 2021


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.

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/20210526/d64ccb28/attachment.html>


More information about the ghc-steering-committee mailing list