Add 'e' to Floating typeclass

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
32 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: qualified exports , what would that mean Re: Add

Levent Erkok
Thanks Bryan! I was completely unaware of unidirectional pattern synonyms. Very cool indeed!

On Thu, Feb 21, 2019 at 9:28 PM Bryan Richter <[hidden email]> 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.html#extension-PatternSynonyms


On Thu, 21 Feb 2019, 23.13 Levent Erkok, <[hidden email]> 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 <[hidden email]> wrote:
> On Thu, Feb 21, 2019 at 1:42 PM Levent Erkok <[hidden email]> 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
<[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: qualified exports , what would that mean Re: Add

Henning Thielemann
In reply to this post by Lennart Augustsson

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.
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: qualified exports , what would that mean Re: Add

Lennart Augustsson
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 <[hidden email]> 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.

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

export constructors only for matching (Was: qualified exports)

Henning Thielemann
In reply to this post by Bryan Richter-2

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.html#extension-PatternSynonyms

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
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: qualified exports , what would that mean Re: Add

Henning Thielemann
In reply to this post by Lennart Augustsson

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?
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: qualified exports , what would that mean Re: Add

Lennart Augustsson
Right.

On Thu, Feb 21, 2019 at 23:38 Henning Thielemann <[hidden email]> 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?

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: qualified exports , what would that mean Re: Add

Henning Thielemann

On Thu, 21 Feb 2019, Lennart Augustsson wrote:

> Right.

Then my suggestion of providing two modules would solve the problem, too.
Right?
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: qualified exports , what would that mean Re: Add

Lennart Augustsson
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 <[hidden email]> wrote:

On Thu, 21 Feb 2019, Lennart Augustsson wrote:

> Right.

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

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: qualified exports , what would that mean Re: Add

Levent Erkok
In reply to this post by Henning Thielemann
Two modules would indeed solve it, and I alluded to it in my original message. (I used the term "internal" module, but I see that it was confusing.) However, the whole point is that you want to avoid that.

I'm not suggesting this has the biggest ROI; but I can see it would have a few use cases and would be an easy solution to an annoying problem as the original poster was arguing. (And Lennart says that'd be easy to implement, after quite a bit of bikeshedding on the precise syntax I suppose.) 

On Thu, Feb 21, 2019 at 11:43 PM Henning Thielemann <[hidden email]> wrote:

On Thu, 21 Feb 2019, Lennart Augustsson wrote:

> Right.

Then my suggestion of providing two modules would solve the problem, too.
Right?
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: qualified exports , what would that mean Re: Add

Henning Thielemann
In reply to this post by Lennart Augustsson

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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: qualified exports , what would that mean Re: Add

Adam Sandberg Eriksson
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 <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

RE: qualified exports , what would that mean Re: Add

Haskell - Libraries mailing list
In reply to this post by Bryan Richter-2

I believe you are in luck. Since 7.8.1, GHC supports "unidirectional pattern synonyms

 

Yes, but a pattern synonym is a bit of heavyweight way to expose a data constructor for pattern matching but not for construction.  The latter seems simpler somehow.  I’ve wanted this too.

 

And yet, and yet, it’s one more piece of complexity, at least the export list (and maybe an import list too!). 

 

And someone is sure to want to export it for construction but not pattern matching :-).  For that we routinely make a term-level function for construction and don’t export the constructor at all.  The pattern synonym is the natural dual of this.

 

TL;DR: you can do both today but you have to write some boilerplate. Whether it’s worth abbreviating I’m not sure.

 

Simon

 

From: Libraries <[hidden email]> On Behalf Of Bryan Richter
Sent: 22 February 2019 05:29
To: Levent Erkok <[hidden email]>
Cc: [hidden email]
Subject: Re: qualified exports , what would that mean Re: Add

 

> 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.html#extension-PatternSynonyms

 

 

On Thu, 21 Feb 2019, 23.13 Levent Erkok, <[hidden email]> 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 <[hidden email]> wrote:

> On Thu, Feb 21, 2019 at 1:42 PM Levent Erkok <[hidden email]> 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
<[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
12