qualified exports , what would that mean Re: Add

[Bryan Richter]

> 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, <erkokl at gmail.com> 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 <qdunkan at gmail.com> wrote:
>
>> > On Thu, Feb 21, 2019 at 1:42 PM Levent Erkok <erkokl at gmail.com> 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
>> <carter.schonwald at gmail.com> 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 at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20190222/17da1cfb/attachment.html>