<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none"><!-- p { margin-top: 0px; margin-bottom: 0px; }--></style>
</head>
<body dir="ltr" style="font-size:12pt;color:#000000;background-color:#FFFFFF;font-family:Calibri,Arial,Helvetica,sans-serif;">
<p>> <span style="color: rgb(33, 33, 33); font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px; background-color: rgb(255, 255, 255);">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?</span><br>
</p>
<p><br>
</p>
<p>Oops yes, sorry for omitting this context.<br>
</p>
<p><br>
</p>
<p>> <span style="color: rgb(33, 33, 33); font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px; background-color: rgb(255, 255, 255);">What is the intent of what got implemented, anyway? Are there example use cases?</span><br>
</p>
<p><br>
</p>
<p>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)<br>
</p>
<p><br>
</p>
<p>Edward Kmett described a concrete motivating use case at <a href="https://github.com/haskell/cabal/issues/7290#issuecomment-783540208">https://github.com/haskell/cabal/issues/7290#issuecomment-783540208</a>​ although his use case is a little difficult to
 understand.<br>
</p>
<p><br>
</p>
<p>Edward<br>
</p>
<p><br>
</p>
<div style="color: rgb(33, 33, 33);">
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> Bryan Richter <b@chreekat.net><br>
<b>Sent:</b> Thursday, February 25, 2021 10:06 AM<br>
<b>To:</b> Edward Z Yang<br>
<b>Cc:</b> cabal-devel@haskell.org; ekmett@gmail.com<br>
<b>Subject:</b> Re: [RFC] Qualified module renamings</font>
<div> </div>
</div>
<div>
<div dir="auto">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?
<div dir="auto"><br>
</div>
<div dir="auto">What is the intent of what got implemented, anyway? Are there example use cases?</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">Den tors 25 feb. 2021 18:14Edward Z Yang <<a href="mailto:ezyang@mit.edu" target="_blank" rel="noreferrer">ezyang@mit.edu</a>> skrev:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex; border-left:1px #ccc solid; padding-left:1ex">
<div dir="ltr" style="font-size:12pt; color:#000000; background-color:#ffffff; font-family:Calibri,Arial,Helvetica,sans-serif">
<p>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.<br>
</p>
<p><br>
</p>
<p><a href="https://github.com/haskell/cabal/pull/7303" rel="noreferrer noreferrer" target="_blank">https://github.com/haskell/cabal/pull/7303</a> 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 (<a href="https://github.com/ghc-proposals/ghc-proposals/pull/283" rel="noreferrer noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/283</a>)
 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.<br>
</p>
<p><br>
</p>
<p>There are two primary axes which I am looking for feedback:<br>
</p>
<p><br>
</p>
<p>* 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.<br>
</p>
<p><br>
</p>
<p>* 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 <a href="https://github.com/haskell/cabal/issues/7290#issue-812744575" rel="noreferrer noreferrer" target="_blank">https://github.com/haskell/cabal/issues/7290#issue-812744575</a>​<br>
</p>
<p><br>
</p>
<p>Thanks Oleg for reminding me to send this RFC to this mailing list.<br>
</p>
<p><br>
</p>
<p>Cheers,<br>
</p>
<p>Edward<br>
</p>
</div>
_______________________________________________<br>
cabal-devel mailing list<br>
<a href="mailto:cabal-devel@haskell.org" rel="noreferrer noreferrer" target="_blank">cabal-devel@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel" rel="noreferrer noreferrer noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel</a><br>
</blockquote>
</div>
</div>
</div>
</body>
</html>