[RFC] Qualified module renamings

[Bryan Richter]

Thanks. :)

Den sön 28 feb. 2021 22:08Edward Z Yang <ezyang at mit.edu> skrev:

> ​I added this to the PR! Hopefully it is what you are looking for.
> ------------------------------
> *From:* Bryan Richter <b at chreekat.net>
> *Sent:* Thursday, February 25, 2021 10:44 PM
> *To:* Edward Z Yang
> *Cc:* cabal-devel at haskell.org; ekmett at 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 <ezyang at 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 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> 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
>>> 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/20210301/9ff93ed6/attachment.html>