I meant shaddowing warning. As Brent more correctly said. On Sun, Feb 17, 2019 at 10:39 AM Carter Schonwald < carter.schonwald@gmail.com> wrote:

There’s at least two reasons why I think this would be a bad idea

1) everyone uses e as a local variable name, or at least it happens often enough. This would breaklots of code

2 ) I’m not sure if there’s ever a better definition than exp 1. Is there?

3) more strongly , does every instance in the Wild give a full ish precision exact up to representation limits answer at exp 1,?

I only thought of the name space issue after I stated writing this email , but I think that kills it.. but I am genuinely curious : can we treat exp 1 as being the actual definition for any all quality instances ?

On Sun, Feb 17, 2019 at 12:14 AM chessai . wrote:

...

We have the 'pi' constant in the floating typeclass and some trigonometric functions, as well as things like exp/log/expm1/log1p.

Why not provide an 'e' constant?

A default implementation could just be 'exp 1'. _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

While I understand the intent of your point yitzchak, inverse sine is less intrinsically uniquely defined than exp. in at least the sense that it’s not uniquely defined in two senses 1)inverse sine and inverse cosine only are defined over the interval -1 through +1, a domain restriction that can’t be modeled all that well 2) we are usually talking about the “branch cut” of solutions in the closed/open interval [0,2pi), but the set of numbers pi *(1+2n), for n an integer are all valid solutions. A similar issue comes up with the natural logarithm when we look at things over the complex numbers There’s no such holes or gaps in relating e and exp. You do raise a good point about computing ... and the answer I think depends on whether the data type of interest has a static or dynamic character to its precision in representation. And or the precision / compute tradeoffs thereof. Let alone anything with explicit support for computer algebra fun! On Sun, Feb 17, 2019 at 2:34 PM Yitzchak Gale wrote:

Shaddowing of 'e' is not a reason not to do this - it's only a reason not to call it 'e'. There has never been a shortage of bikeshedding skills in this community. I'm sure we could come up with something if we decide to do it. At least as good as things like "GHC.Float.log1mexp" that have already been added to this typeclass.

I think Carter's remarks about exp 1 are more to the point. Can we assume that every implentation special cases exp 1, or is computing exp 1 once and sharing it really satisfactory? And if so - then what's so much worse about 2 * asin 1?

On Sun, Feb 17, 2019 at 5:41 PM Carter Schonwald wrote:

...

I meant shaddowing warning. As Brent more correctly said.

On Sun, Feb 17, 2019 at 10:39 AM Carter Schonwald <

...

...

There’s at least two reasons why I think this would be a bad idea

1) everyone uses e as a local variable name, or at least it happens

often enough. This would breaklots of code

...

2 ) I’m not sure if there’s ever a better definition than exp 1. Is

...

...

3) more strongly , does every instance in the Wild give a full ish

...

...

I only thought of the name space issue after I stated writing this

email , but I think that kills it.. but I am genuinely curious : can we

...

...

On Sun, Feb 17, 2019 at 12:14 AM chessai .

wrote:

...

...

We have the 'pi' constant in the floating typeclass and some

carter.schonwald@gmail.com> wrote: there? precision exact up to representation limits answer at exp 1,? treat exp 1 as being the actual definition for any all quality instances ? trigonometric functions, as well as things like exp/log/expm1/log1p.

...

...

...

Why not provide an 'e' constant?

A default implementation could just be 'exp 1'. _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

Lennart's question "Is it really worth it?" is the most important one. And no, probably it isn't. But Chessai is correct that this is a weird asymmetry in the Floating class. My own experience is that I user neither e nor pi very much, but neither one more than the other. Branch cuts of inverse trig functions are not relevant. The report doesn't explicitly state this, but it's clear that these functions are expected to return the standard ranges of values as in other programming languages. You can be quite certain that acos (-1) is pi in Haskell. And in fact, we have (at least on my computer) Prelude> acos (-1) == pi True So there isn't any more or less reason to have e than pi as a separate class member. On Sun, Feb 17, 2019 at 10:15 PM Lennart Augustsson wrote:

Is it really worth it? How frequent are uses of e, except used like exp? On the other hand, pi has more frequent standalone use cases. Also, e has a simple definition (exp 1), whereas pi is somewhat more involved.

The logp1 and expm1 functions where added for good numerical reasons. The same would not be true for e.

On Sat, Feb 16, 2019 at 21:14 chessai . wrote:

...

We have the 'pi' constant in the floating typeclass and some trigonometric functions, as well as things like exp/log/expm1/log1p.

Why not provide an 'e' constant?

A default implementation could just be 'exp 1'. _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

Yeah, I think it probably shouldn't be added to the typeclass then. The asymmetry should probably be mentioned in the report though. On Wed, Feb 20, 2019, 9:22 PM Carter Schonwald wrote:

either way, we're not gonna add e :)

On Wed, Feb 20, 2019 at 8:30 AM Yitzchak Gale wrote:

...

Lennart's question "Is it really worth it?" is the most important one. And no, probably it isn't.

But Chessai is correct that this is a weird asymmetry in the Floating class. My own experience is that I user neither e nor pi very much, but neither one more than the other.

Branch cuts of inverse trig functions are not relevant. The report doesn't explicitly state this, but it's clear that these functions are expected to return the standard ranges of values as in other programming languages. You can be quite certain that acos (-1) is pi in Haskell. And in fact, we have (at least on my computer)

Prelude> acos (-1) == pi True

So there isn't any more or less reason to have e than pi as a separate class member.

On Sun, Feb 17, 2019 at 10:15 PM Lennart Augustsson wrote:

...

Is it really worth it? How frequent are uses of e, except used like

...

Also, e has a simple definition (exp 1), whereas pi is somewhat more involved.

The logp1 and expm1 functions where added for good numerical reasons. The same would not be true for e.

On Sat, Feb 16, 2019 at 21:14 chessai . wrote:

...

We have the 'pi' constant in the floating typeclass and some

exp? On the other hand, pi has more frequent standalone use cases. trigonometric functions, as well as things like exp/log/expm1/log1p.

...

...

Why not provide an 'e' constant?

A default implementation could just be 'exp 1'. _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

---

Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

asymmetry in presence, not use. When I was first learning Haskell, the absence of e along with the presence of pi in Floating confused me. It is not a disservice to users to note this asymmetry in documentation and why it is not there. On Thu, Feb 21, 2019, 1:22 PM Carter Schonwald wrote:

i dont see it as an assymetry, theres a lot of very simple volume / area / probability /geometry calculations where pi comes up, i dont know any for e that aren't just exp. can you share some?

On Wed, Feb 20, 2019 at 10:50 PM chessai . wrote:

...

Yeah, I think it probably shouldn't be added to the typeclass then.

The asymmetry should probably be mentioned in the report though.

On Wed, Feb 20, 2019, 9:22 PM Carter Schonwald < carter.schonwald@gmail.com> wrote:

...

either way, we're not gonna add e :)

On Wed, Feb 20, 2019 at 8:30 AM Yitzchak Gale wrote:

...

Lennart's question "Is it really worth it?" is the most important one. And no, probably it isn't.

But Chessai is correct that this is a weird asymmetry in the Floating class. My own experience is that I user neither e nor pi very much, but neither one more than the other.

Branch cuts of inverse trig functions are not relevant. The report doesn't explicitly state this, but it's clear that these functions are expected to return the standard ranges of values as in other programming languages. You can be quite certain that acos (-1) is pi in Haskell. And in fact, we have (at least on my computer)

Prelude> acos (-1) == pi True

So there isn't any more or less reason to have e than pi as a separate class member.

On Sun, Feb 17, 2019 at 10:15 PM Lennart Augustsson wrote:

...

Is it really worth it? How frequent are uses of e, except used like

...

Also, e has a simple definition (exp 1), whereas pi is somewhat more involved.

The logp1 and expm1 functions where added for good numerical reasons. The same would not be true for e.

On Sat, Feb 16, 2019 at 21:14 chessai . wrote:

...

We have the 'pi' constant in the floating typeclass and some

exp? On the other hand, pi has more frequent standalone use cases. trigonometric functions, as well as things like exp/log/expm1/log1p.

...

...

Why not provide an 'e' constant?

A default implementation could just be 'exp 1'. _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

---

Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

I think Carter outlined really good reasons for not including `e`; but it's hard not to sympathize with the request. I often felt shy of adding similar definitions in my libraries for fear that they would pollute the name space. But their absence is rather annoying. The classic solution is to put it in a library, internal module etc, and make a new class if necessary; which is often overkill and misses the simplicity sought in the first place. I often wonder if Haskell can have a "qualified export" feature for these cases. Just like we can "import qualified," why not "export qualified" some names, which means if you simply import the module the name will still be available qualified. (You can of course always import qualified.) I haven't thought too much about the implications of this, but it might be an easy solution to this problem. Would love to hear thoughts on this; is there any language that has this feature? How costly would it be to add it to GHC? On Thu, Feb 21, 2019 at 10:32 AM chessai . wrote:

asymmetry in presence, not use.

When I was first learning Haskell, the absence of e along with the presence of pi in Floating confused me. It is not a disservice to users to note this asymmetry in documentation and why it is not there.

On Thu, Feb 21, 2019, 1:22 PM Carter Schonwald wrote:

...

i dont see it as an assymetry, theres a lot of very simple volume / area / probability /geometry calculations where pi comes up, i dont know any for e that aren't just exp. can you share some?

On Wed, Feb 20, 2019 at 10:50 PM chessai . wrote:

...

Yeah, I think it probably shouldn't be added to the typeclass then.

The asymmetry should probably be mentioned in the report though.

On Wed, Feb 20, 2019, 9:22 PM Carter Schonwald < carter.schonwald@gmail.com> wrote:

...

either way, we're not gonna add e :)

On Wed, Feb 20, 2019 at 8:30 AM Yitzchak Gale wrote:

...

Lennart's question "Is it really worth it?" is the most important one. And no, probably it isn't.

But Chessai is correct that this is a weird asymmetry in the Floating class. My own experience is that I user neither e nor pi very much, but neither one more than the other.

Branch cuts of inverse trig functions are not relevant. The report doesn't explicitly state this, but it's clear that these functions are expected to return the standard ranges of values as in other programming languages. You can be quite certain that acos (-1) is pi in Haskell. And in fact, we have (at least on my computer)

Prelude> acos (-1) == pi True

So there isn't any more or less reason to have e than pi as a separate class member.

On Sun, Feb 17, 2019 at 10:15 PM Lennart Augustsson wrote:

...

Is it really worth it? How frequent are uses of e, except used like

...

Also, e has a simple definition (exp 1), whereas pi is somewhat more involved.

The logp1 and expm1 functions where added for good numerical reasons. The same would not be true for e.

On Sat, Feb 16, 2019 at 21:14 chessai . wrote: > > We have the 'pi' constant in the floating typeclass and some

exp? On the other hand, pi has more frequent standalone use cases. trigonometric functions, as well as things like exp/log/expm1/log1p.

...

> > Why not provide an 'e' constant? > > A default implementation could just be 'exp 1'. > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

---

Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

On Thu, Feb 21, 2019 at 1:42 PM Levent Erkok wrote:

...

I think Carter outlined really good reasons for not including `e`; but it's hard not to sympathize with the request. I often felt shy of adding similar definitions in my libraries for fear that they would pollute the name space. But their absence is rather annoying. The classic solution is to put it in a library, internal module etc, and make a new class if necessary; which is often overkill and misses the simplicity sought in the first place.

I often wonder if Haskell can have a "qualified export" feature for these cases. Just like we can "import qualified," why not "export qualified" some names, which means if you simply import the module the name will still be available qualified. (You can of course always import qualified.)

I haven't thought too much about the implications of this, but it might be an easy solution to this problem. Would love to hear thoughts on this; is there any language that has this feature? How costly would it be to add it to GHC?

On Thu, Feb 21, 2019 at 11:04 AM Carter Schonwald wrote:

hey Levent, I can't claim to have thought about it that deeply, but naively, it seems like a qualified export approach might not play nice with certain approaches to seperate compilation (not that GHC does it that much), because the names qualifications wouldn't match possible import modules, Or at least the qualified names in scope wouldn't match what you see from the import lines, and thus you'd have a harder time supporting good quality error messages? (i could be totally wrong)

its definitely an interesting idea, and i certainly dont have clarity on what the implications would be

If I interpret it correctly, I think what it becomes is that some symbols can never be imported unqualified. Or maybe that the default "import all unqualified" actually means "everything except these things." So it would just be an extra rule for what `import` brings into scope. Python has such a mechanism, if you have an `__all__ = [x, y, z]` then `from m import *` will just get you x, y, and z. That said, to me it seems like too many ways to do it. The user can already get a qualified import if they want it. When you write an unqualified "import *", the price you pay is losing control over your namespace, and that's a known cost. A bit more finesse on what exactly is imported won't change the basic tradeoff.

Another pet peeve: Export constructors but only for pattern matching purposes, i.e., elimination; not for construction--we'd export smart constructors for the latter which would ensure invariants

I believe you are in luck. Since 7.8.1, GHC supports "unidirectional pattern synonyms", as described somewhere in this section: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts... On Thu, 21 Feb 2019, 23.13 Levent Erkok, wrote:

Evan: I liked how you put it: "A bit more finesse on what exactly is imported won't change the basic tradeoff." But still seems to me that Haskells exporting mechanism can be improved. (Another pet peeve: Export constructors but only for pattern matching purposes, i.e., elimination; not for construction--we'd export smart constructors for the latter which would ensure invariants. But that's a whole another can of worms.)

I think there's design space here to be explored; in the end, it's the end-users who will have to judge what's useful and what's not.

On Thu, Feb 21, 2019 at 12:46 PM Evan Laforge wrote:

...

...

On Thu, Feb 21, 2019 at 1:42 PM Levent Erkok wrote:

...

I think Carter outlined really good reasons for not including `e`; but

it's hard not to sympathize with the request. I often felt shy of adding similar definitions in my libraries for fear that they would pollute the name space. But their absence is rather annoying. The classic solution is to put it in a library, internal module etc, and make a new class if necessary; which is often overkill and misses the simplicity sought in the first place.

...

I often wonder if Haskell can have a "qualified export" feature for

these cases. Just like we can "import qualified," why not "export qualified" some names, which means if you simply import the module the name will still be available qualified. (You can of course always import qualified.)

...

I haven't thought too much about the implications of this, but it

might be an easy solution to this problem. Would love to hear thoughts on this; is there any language that has this feature? How costly would it be to add it to GHC?

On Thu, Feb 21, 2019 at 11:04 AM Carter Schonwald wrote:

...

hey Levent, I can't claim to have thought about it that deeply, but naively, it

seems like a qualified export approach might not play nice with certain approaches to seperate compilation (not that GHC does it that much), because the names qualifications wouldn't match possible import modules, Or at least the qualified names in scope wouldn't match what you see from the import lines, and thus you'd have a harder time supporting good quality error messages? (i could be totally wrong)

...

its definitely an interesting idea, and i certainly dont have clarity

on what the implications would be

If I interpret it correctly, I think what it becomes is that some symbols can never be imported unqualified. Or maybe that the default "import all unqualified" actually means "everything except these things." So it would just be an extra rule for what `import` brings into scope. Python has such a mechanism, if you have an `__all__ = [x, y, z]` then `from m import *` will just get you x, y, and z.

That said, to me it seems like too many ways to do it. The user can already get a qualified import if they want it. When you write an unqualified "import *", the price you pay is losing control over your namespace, and that's a known cost. A bit more finesse on what exactly is imported won't change the basic tradeoff.

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

On Fri, 22 Feb 2019, Bryan Richter wrote:

...

Another pet peeve: Export constructors but only for pattern matching purposes, i.e., elimination; not for construction--we'd export smart constructors for the latter which would ensure invariants

I believe you are in luck. Since 7.8.1, GHC supports "unidirectional pattern synonyms", as described somewhere in this section: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts...

In some cases you can even solve it in Haskell 98. If you have data T = Cons Char and you want to let users match Cons without exporting it, you may export a "destructor" like uncons :: T -> Char uncons (Cons a) = a or you export a continuation passing function: withT :: (Char -> a) -> T -> a withT f (Cons a) = f a and the user would no longer write g :: Int -> T -> Ordering -> Bool g x (Cons y) z = foo x y z but g :: Int -> T -> Ordering -> Bool g x = withT $ \y z -> foo x y z

Qualified exports seem very unproblematic to me. And they should be easy to implement. It’s just an extra flag on each exported entity that tells compiler if the unqualified name should be entered into the symbol table or not. — Lennart On Thu, Feb 21, 2019 at 11:04 Carter Schonwald wrote:

hey Levent, I can't claim to have thought about it that deeply, but naively, it seems like a qualified export approach might not play nice with certain approaches to seperate compilation (not that GHC does it that much), because the names qualifications wouldn't match possible import modules, Or at least the qualified names in scope wouldn't match what you see from the import lines, and thus you'd have a harder time supporting good quality error messages? (i could be totally wrong)

its definitely an interesting idea, and i certainly dont have clarity on what the implications would be

On Thu, Feb 21, 2019 at 1:42 PM Levent Erkok wrote:

...

I think Carter outlined really good reasons for not including `e`; but it's hard not to sympathize with the request. I often felt shy of adding similar definitions in my libraries for fear that they would pollute the name space. But their absence is rather annoying. The classic solution is to put it in a library, internal module etc, and make a new class if necessary; which is often overkill and misses the simplicity sought in the first place.

I often wonder if Haskell can have a "qualified export" feature for these cases. Just like we can "import qualified," why not "export qualified" some names, which means if you simply import the module the name will still be available qualified. (You can of course always import qualified.)

I haven't thought too much about the implications of this, but it might be an easy solution to this problem. Would love to hear thoughts on this; is there any language that has this feature? How costly would it be to add it to GHC?

On Thu, Feb 21, 2019 at 10:32 AM chessai . wrote:

...

asymmetry in presence, not use.

When I was first learning Haskell, the absence of e along with the presence of pi in Floating confused me. It is not a disservice to users to note this asymmetry in documentation and why it is not there.

On Thu, Feb 21, 2019, 1:22 PM Carter Schonwald < carter.schonwald@gmail.com> wrote:

...

i dont see it as an assymetry, theres a lot of very simple volume / area / probability /geometry calculations where pi comes up, i dont know any for e that aren't just exp. can you share some?

On Wed, Feb 20, 2019 at 10:50 PM chessai . wrote:

...

Yeah, I think it probably shouldn't be added to the typeclass then.

The asymmetry should probably be mentioned in the report though.

On Wed, Feb 20, 2019, 9:22 PM Carter Schonwald < carter.schonwald@gmail.com> wrote:

...

either way, we're not gonna add e :)

On Wed, Feb 20, 2019 at 8:30 AM Yitzchak Gale wrote:

> Lennart's question "Is it really worth it?" is the most important > one. > And no, probably it isn't. > > But Chessai is correct that this is a weird asymmetry in the Floating > class. My own experience is that I user neither e nor pi very much, > but neither one more than the other. > > Branch cuts of inverse trig functions are not relevant. The report > doesn't explicitly state this, but it's clear that these functions > are > expected to return the standard ranges of values as in other > programming languages. You can be quite certain that acos (-1) is pi > in Haskell. And in fact, we have (at least on my computer) > > Prelude> acos (-1) == pi > True > > So there isn't any more or less reason to have e than pi as a > separate > class member. > > On Sun, Feb 17, 2019 at 10:15 PM Lennart Augustsson > wrote: > > > > Is it really worth it? How frequent are uses of e, except used > like exp? On the other hand, pi has more frequent standalone use cases. > > Also, e has a simple definition (exp 1), whereas pi is somewhat > more involved. > > > > The logp1 and expm1 functions where added for good numerical > reasons. The same would not be true for e. > > > > On Sat, Feb 16, 2019 at 21:14 chessai . > wrote: > >> > >> We have the 'pi' constant in the floating typeclass and some > trigonometric functions, as well as things like exp/log/expm1/log1p. > >> > >> Why not provide an 'e' constant? > >> > >> A default implementation could just be 'exp 1'. > >> _______________________________________________ > >> Libraries mailing list > >> Libraries@haskell.org > >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > > > _______________________________________________ > > Libraries mailing list > > Libraries@haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

I don’t really see how it subverts anything. If you rename the module on import, then that’s the module name you have to use when accessing a qualified export. On Thu, Feb 21, 2019 at 23:28 Henning Thielemann < lemming@henning-thielemann.de> wrote:

On Thu, 21 Feb 2019, Lennart Augustsson wrote:

...

Qualified exports seem very unproblematic to me. And they should be easy to implement. It’s just an extra flag on each exported entity that tells compiler if the unqualified name should be entered into the symbol table or not.

But it subverts the idea of disambiguation by renaming the module name at the import site.

Right. On Thu, Feb 21, 2019 at 23:38 Henning Thielemann < lemming@henning-thielemann.de> wrote:

On Thu, 21 Feb 2019, Lennart Augustsson wrote:

...

I don’t really see how it subverts anything. If you rename the module on import, then that’s the module name you have to use when accessing a qualified export.

That is, "qualified export" is only a flag for each identifier and not a module name per identifier?

Sure, but with a lot more overhead. I’m not a proponent of qualified export. I just think it would an unproblematic feature to add if we feel it’s important. On Thu, Feb 21, 2019 at 23:43 Henning Thielemann < lemming@henning-thielemann.de> wrote:

On Thu, 21 Feb 2019, Lennart Augustsson wrote:

...

Right.

Then my suggestion of providing two modules would solve the problem, too. Right?

There is a ghc proposal for among other things qualified exports: https://github.com/ghc-proposals/ghc-proposals/pull/205 —Adam

On 22 Feb 2019, at 07:58, Henning Thielemann wrote:

...

On Thu, 21 Feb 2019, Lennart Augustsson wrote:

Sure, but with a lot more overhead.

It would look like this:

module Unqualified (...) where

module Qualified ( module Unqualified, e, ) where

If the list of qualified exports is long, then it might even be less to write than adding 'qualified' to many identifiers. I don't like to make the already complicated module system even more complicated for promoting a feature that has code smell anyway (namely, unrestricted unqualified imports). _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

On Thu, 21 Feb 2019, Levent Erkok wrote:

I often wonder if Haskell can have a "qualified export" feature for these cases. Just like we can "import qualified," why not "export qualified" some names, which means if you simply import the module the name will still be available qualified. (You can of course always import qualified.)

I haven't thought too much about the implications of this, but it might be an easy solution to this problem. Would love to hear thoughts on this; is there any language that has this feature? How costly would it be to add it to GHC?

Why not providing two modules: One that exports all identifiers and one that exports only identifiers that are likely not to clash with others. The first module would export 'e' and the second one would not. The first module would preferably be imported with qualification and the second one without. However, unrestricted unqualified imports (like for the second module) are most oftenly not what you want because you have to restrict the imported package to a specific minor version then (according to PVP).