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 <b at chreekat.net> 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, <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/20190221/414cd730/attachment.html>