[RFC] Qualified module renamings

Thu Feb 25 22:01:19 UTC 2021

How this will work with packages adding modules.

For concrete example:

- parsec-backpack-0.1 provides two modules Parsec.Prim and
Parsec.Combinators
- in my library, I instantiate Parsec.* to Parsec.Text.*, and
Parsec.String.*, I get four modules. That is nice.
- parsec-backpack-0.1.1 is released adding Parsec.Error. I get six
modules. That is still fine as they are not exported.

However, if the same example is done for re-exported modules, my library
public interface would change depending on (minor) version of a
dependency. This is no go in Hackage context.

As far as I can see it, reexported-modules and wildcards are no go.

Something like

    reexported-modules: [ [ Parsec.Text.m, Parsec.String.m] | m <- [
Prim, Combinators ] ]

or

    reexported-modules: for m in [Prim, Combinators]: Parsec.Text.m,
Parsec.String.m

or some variation of that idea which fits cabal/module syntax would be
both explicit and still more convenient.

I also think it will be even easier to implement, as you all information
is there, you don't need to know any context to expand it.

- Oleg

On 25.2.2021 23.01, Edward Z Yang wrote:
>
> > It took me about five minutes to arrive at the guess that this is
> about the syntax in Cabal files for using backpack - is that right?
>
>
> Oops yes, sorry for omitting this context.
>
>
> > What is the intent of what got implemented, anyway? Are there
> example use cases?
>
>
> I'm not exactly sure what you mean by intent. But a common pattern in
> Backpack is to instantiate a library multiple time with different
> requirements, and if you want them all in scope you have to rename
> them. Right now, this has to be done one-by-one for each provided
> module, which can be a bit annoying. For example, let say you
> parametrized parsec by string type, and you wanted a bytestring
> version and a text version, it would be convenient to be able to
> unconditionally rename every Text.Parsec.* module to
> Text.Parsec.*.ByteString (for example)
>
>
> Edward Kmett described a concrete motivating use case
> at https://github.com/haskell/cabal/issues/7290#issuecomment-783540208
> although his use case is a little difficult to understand.
>
>
> Edward
>
>
> ------------------------------------------------------------------------
> *From:* Bryan Richter <b at chreekat.net>
> *Sent:* Thursday, February 25, 2021 10:06 AM
> *To:* Edward Z Yang
> *Cc:* cabal-devel at haskell.org; ekmett at gmail.com
> *Subject:* Re: [RFC] Qualified module renamings
>  
> It took me about five minutes to arrive at the guess that this is
> about the syntax in Cabal files for using backpack - is that right?
>
> What is the intent of what got implemented, anyway? Are there example
> use cases?
>
> Den tors 25 feb. 2021 18:14Edward Z Yang <ezyang at mit.edu
> <mailto:ezyang at mit.edu>> skrev:
>
>     Today, using the 'mixins' field you can rename modules that come
>     from other packages by manually expressing a renaming one-by-one.
>     In some Backpack use cases, you may have a lot of modules that you
>     would like to mechanically rename into some subnamespace; today,
>     you have manually list each renaming one by one.
>
>
>     https://github.com/haskell/cabal/pull/7303 contains an
>     implementation of one possible way to extend mixin syntax to
>     support qualified renaming; the implementation is very simple. The
>     syntax here is based off of Richard Eisenberg's local modules
>     proposal (https://github.com/ghc-proposals/ghc-proposals/pull/283)
>     which supports the qualified keyword before module exports/imports
>     which has the same effect (bring the module into scope under a
>     sub-module namespace). However, the PR isn't really meant to be an
>     end all to the discussion: it's just to show that it's pretty
>     simple to implement this functionality.
>
>
>     There are two primary axes which I am looking for feedback:
>
>
>     * Expressivity. The current PoC implementation only permits
>     unconditionally prefix-ing all modules that would have been
>     brought into scope by the mixin; e.g., transforming module A to
>     Prefix.A. Edward Kmett has expressed that in some cases, he would
>     like it if you could implement the import as a suffix. One could
>     also imagine allowing arbitrary string transformations. Opinions
>     on where to draw the line for expressivity are solicited.
>
>
>     * Syntax. The current syntax is "pkgname qualified Prefix" as it
>     is symmetric with "pkgname hiding (A, B)" and it was simple to
>     implement. But I am not particularly attached to this syntax, and
>     am open to other suggestions. If we permit suffixing, a wildcard
>     based syntax like "pkgname (* as *.Suffix)" may be preferable
>     (though modestly more complex to specify and implement; for
>     example, is the glob recursive over dots?). Edward Kmett has
>     offered some other possibilities
>     at https://github.com/haskell/cabal/issues/7290#issue-812744575
>
>
>     Thanks Oleg for reminding me to send this RFC to this mailing list.
>
>
>     Cheers,
>
>     Edward
>
>     _______________________________________________
>     cabal-devel mailing list
>     cabal-devel at haskell.org <mailto:cabal-devel at haskell.org>
>     http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
>
>
> _______________________________________________
> cabal-devel mailing list
> cabal-devel at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/cabal-devel/attachments/20210226/52d1afe3/attachment.html>