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...@chreekat.net> > *Sent:* Thursday, February 25, 2021 10:06 AM > *To:* Edward Z Yang > *Cc:* cabal-devel@haskell.org; ekm...@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 <ezy...@mit.edu > <mailto:ezy...@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@haskell.org <mailto:cabal-devel@haskell.org> > http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel > > > _______________________________________________ > cabal-devel mailing list > cabal-devel@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
_______________________________________________ cabal-devel mailing list cabal-devel@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
