Thanks. :) Den sön 28 feb. 2021 22:08Edward Z Yang <ezy...@mit.edu> skrev:
> I added this to the PR! Hopefully it is what you are looking for. > ------------------------------ > *From:* Bryan Richter <b...@chreekat.net> > *Sent:* Thursday, February 25, 2021 10:44 PM > *To:* Edward Z Yang > *Cc:* cabal-devel@haskell.org; ekm...@gmail.com > *Subject:* Re: [RFC] Qualified module renamings > > Thanks for the context! > > By intent, I meant an example like "Here's what it would like now, and > here's what it would look like with this implemented. For a much longer > example with rationale, see [Kmett's comment]" > > > Den tors 25 feb. 2021 23:01Edward Z Yang <ezy...@mit.edu> skrev: > >> > 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> 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 >>> 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
