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

[Spiwack, Arnaud]

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

>
>
> 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>
> 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/20210611/dd85dbe9/attachment.html>