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
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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee