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

[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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201016/94a9a6e3/attachment-0001.html>