[RFC] Qualified module renamings

[Edward Z Yang]

> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/cabal-devel/attachments/20210225/7d708a25/attachment-0001.html>