From ezyang at mit.edu  Thu Feb 25 16:13:54 2021
From: ezyang at mit.edu (Edward Z Yang)
Date: Thu, 25 Feb 2021 16:13:54 +0000
Subject: [RFC] Qualified module renamings
Message-ID: <1614269634603.68860@mit.edu>

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

From b at chreekat.net  Thu Feb 25 18:06:12 2021
From: b at chreekat.net (Bryan Richter)
Date: Thu, 25 Feb 2021 20:06:12 +0200
Subject: [RFC] Qualified module renamings
In-Reply-To: <1614269634603.68860@mit.edu>
References: <1614269634603.68860@mit.edu>
Message-ID: <CAH9BU=xJ=cohwyNWWJvZ8Ag4enLVn+rTXw6WA6E_-Bzr1WMNaw@mail.gmail.com>

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/20210225/7e30c29c/attachment.html>

From ezyang at mit.edu  Thu Feb 25 21:01:20 2021
From: ezyang at mit.edu (Edward Z Yang)
Date: Thu, 25 Feb 2021 21:01:20 +0000
Subject: [RFC] Qualified module renamings
In-Reply-To: <CAH9BU=xJ=cohwyNWWJvZ8Ag4enLVn+rTXw6WA6E_-Bzr1WMNaw@mail.gmail.com>
References: <1614269634603.68860@mit.edu>,
 <CAH9BU=xJ=cohwyNWWJvZ8Ag4enLVn+rTXw6WA6E_-Bzr1WMNaw@mail.gmail.com>
Message-ID: <1614286880156.80270@mit.edu>

> 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>

From oleg.grenrus at iki.fi  Thu Feb 25 22:01:19 2021
From: oleg.grenrus at iki.fi (Oleg Grenrus)
Date: Fri, 26 Feb 2021 00:01:19 +0200
Subject: [RFC] Qualified module renamings
In-Reply-To: <1614286880156.80270@mit.edu>
References: <1614269634603.68860@mit.edu>
 <CAH9BU=xJ=cohwyNWWJvZ8Ag4enLVn+rTXw6WA6E_-Bzr1WMNaw@mail.gmail.com>
 <1614286880156.80270@mit.edu>
Message-ID: <465389bf-96f3-523e-e076-dd9009930299@iki.fi>

How this will work with packages adding modules.

For concrete example:

- parsec-backpack-0.1 provides two modules Parsec.Prim and
Parsec.Combinators
- in my library, I instantiate Parsec.* to Parsec.Text.*, and
Parsec.String.*, I get four modules. That is nice.
- parsec-backpack-0.1.1 is released adding Parsec.Error. I get six
modules. That is still fine as they are not exported.

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.

As far as I can see it, reexported-modules and wildcards are no go.

Something like

    reexported-modules: [ [ Parsec.Text.m, Parsec.String.m] | m <- [
Prim, Combinators ] ]

or

    reexported-modules: for m in [Prim, Combinators]: Parsec.Text.m,
Parsec.String.m

or some variation of that idea which fits cabal/module syntax would be
both explicit and still more convenient.

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.

- Oleg

On 25.2.2021 23.01, Edward Z Yang wrote:
>
> > 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
>
>
> _______________________________________________
> 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/20210226/52d1afe3/attachment.html>

From b at chreekat.net  Fri Feb 26 06:44:47 2021
From: b at chreekat.net (Bryan Richter)
Date: Fri, 26 Feb 2021 08:44:47 +0200
Subject: [RFC] Qualified module renamings
In-Reply-To: <1614286880156.80270@mit.edu>
References: <1614269634603.68860@mit.edu>
 <CAH9BU=xJ=cohwyNWWJvZ8Ag4enLVn+rTXw6WA6E_-Bzr1WMNaw@mail.gmail.com>
 <1614286880156.80270@mit.edu>
Message-ID: <CAH9BU=yn3aOg9gHOph-L5FwsnEM9iEN1_jHG1=TW4NJJ-_wkjA@mail.gmail.com>

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/20210226/82242307/attachment-0001.html>

From ezyang at mit.edu  Sun Feb 28 19:37:38 2021
From: ezyang at mit.edu (Edward Z Yang)
Date: Sun, 28 Feb 2021 19:37:38 +0000
Subject: [RFC] Qualified module renamings
In-Reply-To: <465389bf-96f3-523e-e076-dd9009930299@iki.fi>
References: <1614269634603.68860@mit.edu>
 <CAH9BU=xJ=cohwyNWWJvZ8Ag4enLVn+rTXw6WA6E_-Bzr1WMNaw@mail.gmail.com>
 <1614286880156.80270@mit.edu>,<465389bf-96f3-523e-e076-dd9009930299@iki.fi>
Message-ID: <1614541058608.47518@mit.edu>

I agree that transitive dependency is a problem, and I suppose one that cannot even be fixed by sdist elaboration.


As a partial fix (which I believe would be acceptable for Edward) What if reexport wildcards were only permitted for modules that came from the local package? Since we have internal libraries, one might reasonably define a bunch of modules, and then in the same cabal file, want to reexport them from another internal library. If we take care in writing the error message, this restriction may not even be too hard for users to understand. I suppose if we take the theme from your suggestion, which is Cabal files as honest to goodness programs, this would be equivalent to being able to define module lists and then reuse them elsewhere (perhaps after some string processing; similar to common stanzas).


As a more general thought: I noticed in a few other situations where traditional PVP does a poor job at addressing situations where API stability depends on packages you yourself depend on. For example, let's say I wanted to make a metapackage that took a few packages and reexported their modules. You don't even have to talk about the module level: at the declaration level, what identifiers are available from this package will depend on the version choices of its dependencies. But it's infeasible to publish combinatorially many versions of the metapackage for each possible version of its dependency; instead, you'd rather just say that the API of this package depends not only on the package itself, but also some other subpackages. Without some expressivity like this, you just can't write packages like this.


Edward



________________________________
From: cabal-devel <cabal-devel-bounces at haskell.org> on behalf of Oleg Grenrus <oleg.grenrus at iki.fi>
Sent: Thursday, February 25, 2021 2:01 PM
To: cabal-devel at haskell.org
Subject: Re: [RFC] Qualified module renamings


How this will work with packages adding modules.

For concrete example:

- parsec-backpack-0.1 provides two modules Parsec.Prim and Parsec.Combinators
- in my library, I instantiate Parsec.* to Parsec.Text.*, and Parsec.String.*, I get four modules. That is nice.
- parsec-backpack-0.1.1 is released adding Parsec.Error. I get six modules. That is still fine as they are not exported.

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.

As far as I can see it, reexported-modules and wildcards are no go.

Something like

    reexported-modules: [ [ Parsec.Text.m, Parsec.String.m] | m <- [ Prim, Combinators ] ]

or

    reexported-modules: for m in [Prim, Combinators]: Parsec.Text.m, Parsec.String.m

or some variation of that idea which fits cabal/module syntax would be both explicit and still more convenient.

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.

- Oleg


On 25.2.2021 23.01, Edward Z Yang wrote:

> 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><mailto:b at chreekat.net>
Sent: Thursday, February 25, 2021 10:06 AM
To: Edward Z Yang
Cc: cabal-devel at haskell.org<mailto:cabal-devel at haskell.org>; ekmett at gmail.com<mailto: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



_______________________________________________
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/20210228/eb446161/attachment.html>

From ezyang at mit.edu  Sun Feb 28 20:08:46 2021
From: ezyang at mit.edu (Edward Z Yang)
Date: Sun, 28 Feb 2021 20:08:46 +0000
Subject: [RFC] Qualified module renamings
In-Reply-To: <CAH9BU=yn3aOg9gHOph-L5FwsnEM9iEN1_jHG1=TW4NJJ-_wkjA@mail.gmail.com>
References: <1614269634603.68860@mit.edu>
 <CAH9BU=xJ=cohwyNWWJvZ8Ag4enLVn+rTXw6WA6E_-Bzr1WMNaw@mail.gmail.com>
 <1614286880156.80270@mit.edu>,
 <CAH9BU=yn3aOg9gHOph-L5FwsnEM9iEN1_jHG1=TW4NJJ-_wkjA@mail.gmail.com>
Message-ID: <1614542926073.30694@mit.edu>

​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<mailto: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<mailto:b at chreekat.net>>
Sent: Thursday, February 25, 2021 10:06 AM
To: Edward Z Yang
Cc: cabal-devel at haskell.org<mailto:cabal-devel at haskell.org>; ekmett at gmail.com<mailto: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/20210228/89b42735/attachment-0001.html>