qualified exports , what would that mean Re: Add

[Levent Erkok]

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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20190221/06fe079f/attachment.html>