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

[Alejandro Serrano Mena]

 Dear all,

I am in favor of this proposal. I think it solves one important issue in
Haskell’s design (I’ve always hated the 1-1 relationship between modules
and files), and does so in a way which feels natural with the rest of the
language.

Regarding the optional pieces of the spec:
- 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.

Regards,
Alejandro

El 20 may 2021 17:42:30, Spiwack, Arnaud <arnaud.spiwack at tweag.io> escribió:

> Dear all,
>
> It is time to review the local modules proposal, from our own Richard
> Eisenberg, again. In fact it’s been time for a while, and I must apologise
> to Richard for not having understood that. Sorry, Richard.
>
> Link: https://github.com/ghc-proposals/ghc-proposals/pull/283
>
> Since the last time, the proposal has been both simplified and made more
> precise. The main issues solved by this proposal are
>
>    - The ability to export qualified names from modules
>    - The ability to define functions with qualified names within a module
>    (*e.g.* you could have both T.f and U.f).
>    - The ability to locally refer to qualified data as unqualified
>    (suppose Set.map is in scope, then the proposal lets you write let
>    import module Set in map f (map g some_set).
>
> I think these are three important issues, and the proposal makes a good
> case that they ought to be solved together. I also think that the
> specification is clear and doesn’t leave any dark corner. Caveat: I have
> contributed to writing the current specification, so I may be missing some
> flaws.
>
> The proposal does introduce a somewhat byzantine semantic difference
> between module X and module qualified X in export lists. This is to keep
> the current meaning of module X which is already not very intuitive (cf
> https://ro-che.info/articles/2012-12-25-haskell-module-system-p1 ). I
> think this is unavoidable.
>
> There are also 3 optional pieces of specification that we are asked to
> rule on (§4). I’m personally in favour of option 1. I’m weakly in favour of
> option 3 (with a preference for the variant described in Alternative 7). On
> the other hand option 2 seems to add a bit too much syntactic subtlety to
> be worth it (though if we choose option 2, I see no reason not to accept
> Alternative 3 as well).
>
> /Arnaud
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210525/97aa133c/attachment.html>