<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>How this will work with packages adding modules.<br>
<br>
For concrete example:<br>
<br>
- parsec-backpack-0.1 provides two modules Parsec.Prim and
Parsec.Combinators<br>
- in my library, I instantiate Parsec.* to Parsec.Text.*, and
Parsec.String.*, I get four modules. That is nice.<br>
- parsec-backpack-0.1.1 is released adding Parsec.Error. I get six
modules. That is still fine as they are not exported.<br>
<br>
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.<br>
<br>
As far as I can see it, reexported-modules and wildcards are no
go.<br>
<br>
Something like<br>
<br>
reexported-modules: [ [ Parsec.Text.m, Parsec.String.m] | m
<- [ Prim, Combinators ] ]<br>
<br>
or<br>
<br>
reexported-modules: for m in [Prim, Combinators]:
Parsec.Text.m, Parsec.String.m<br>
<br>
or some variation of that idea which fits cabal/module syntax
would be both explicit and still more convenient.<br>
<br>
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.<br>
<br>
- Oleg<br>
<br>
</p>
<div class="moz-cite-prefix">On 25.2.2021 23.01, Edward Z Yang
wrote:<br>
</div>
<blockquote type="cite" cite="mid:1614286880156.80270@mit.edu">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<style type="text/css" style="display:none"><!-- p { margin-top: 0px; margin-bottom: 0px; }--></style>
<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"
moz-do-not-send="true">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 style="font-size:11pt"
face="Calibri, sans-serif" color="#000000"><b>From:</b>
Bryan Richter <a class="moz-txt-link-rfc2396E" href="mailto:b@chreekat.net"><b@chreekat.net></a><br>
<b>Sent:</b> Thursday, February 25, 2021 10:06 AM<br>
<b>To:</b> Edward Z Yang<br>
<b>Cc:</b> <a class="moz-txt-link-abbreviated" href="mailto:cabal-devel@haskell.org">cabal-devel@haskell.org</a>; <a class="moz-txt-link-abbreviated" href="mailto:ekmett@gmail.com">ekmett@gmail.com</a><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" moz-do-not-send="true">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"
moz-do-not-send="true">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"
moz-do-not-send="true">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"
moz-do-not-send="true">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" moz-do-not-send="true">cabal-devel@haskell.org</a><br>
<a
href="http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel"
rel="noreferrer noreferrer noreferrer" target="_blank"
moz-do-not-send="true">http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel</a><br>
</blockquote>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
cabal-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:cabal-devel@haskell.org">cabal-devel@haskell.org</a>
<a class="moz-txt-link-freetext" href="http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel">http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel</a>
</pre>
</blockquote>
</body>
</html>