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

[Joachim Breitner]

Hi,

it seems that there are refinements possible. So even if most comments
were supportive so far, shall we send it back to “needs revision” and
discuss on the Github thread?

Cheers,
Joachim


Am Freitag, den 16.10.2020, 10:03 +0100 schrieb Simon Marlow:
> I like the proposal. Particularly I like that "it's just namespacing", you can explain everything in terms of what entities are in scope with what names.
> 
> But one thing jars with me:
> 
> * In existing import statements, names are made available both qualified and unqualified unless you say "qualified", in which case only the qualified names are brought into scope.
> * In this proposal, the "qualified" convention is extended to data/class/.. declarations, and to module exports. That's all fine.
> * However, local modules use a different convention: you get only the qualified names by default unless you add the "import" keyword to bring into scope the unqualified names. This applies both to a local module declaration at the top level, and to the import of a local module in an import list.
> 
> Why the inconsistency here? Can't we use the "qualified" convention everywhere? I think I would rather prefer to write
> 
>    qualified module M (x,y) where ...
> 
> to make it clear that you have to refer to M.x qualified. That's a lot more consistent with import statements.
> 
> Perhaps the concern is that if you just "import M" and M contains local modules, we want those modules to be imported qualified by default. But we could just state that to be the case, so that you have to explicitly "import M (module N)" to bring N's entities into scope unqualified.
> 
> Cheers
> Simon
> 
> 
> On Wed, 14 Oct 2020 at 15:08, Spiwack, Arnaud <arnaud.spiwack at tweag.io> wrote:
> > Dear all,
> > 
> > I would like to bring our own Richard Eisenberg’s proposal, #283: Local modules, to your attention.
> > https://github.com/ghc-proposals/ghc-proposals/pull/283
> > 
> > The proposal is an attempt at solving the long debated issue that we can’t export qualified names out of a module (e.g. we may have to repeat import qualified Data.Map as Map and import qualified Data.Set as Set in every module in a project, rather than simply calling import MyPrelude which would take care of both and more), to improve scope management, and sharing names between types in the same files, while making namespaces more convenient to use in the process.
> > 
> > It’s a pretty ambitious proposal, with quite a few interlocking pieces. Yet, in my opinion, they fit pretty well together. And I’m, as a potential consumer, very enthusiastic about it.
> > 
> > Some highlight (though do read the whole thing):
> > 
> > We can define modules inside of other modules, with the syntax module Foo (some, optional, exports) where …
> > Like in the rest of Haskell, modules are no more than namespaces. Therefore you can open two module Foo, it will just merge the names in them
> > Values in local modules can be referred to, qualified, in the encompassing module
> > Local modules can be exported, importing them will import the name as qualified
> > A new import module Foo statement can be used in let and where clauses, it brings everything of the form Foo.x into scope unqualified for the scope of the let or where
> > Additionally, there is a small point that is not integral to the rest of the proposal, where defining, say, a type
> > 
> > data T
> >   = A
> >   | B
> > Would create a local module named T, such that the constructors could be referred to as T.A and T.B. I mention it separately, because it causes the only (small) backward incompatibility (that is Haskell 2010 programs which stop compiling when you turn on -XLocalModules).
> > 
> > I’m rather in favour of keeping it in, but it’s worth mentioning.
> > 
> > I pretty much want all of these features in my daily programming, so, as I said above, I’m very enthusiastic for all of this. And I’m pretty happy with the realisation. Hence my recommending acceptance.
> > 
> > /Arnaud
> > 
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/