qualified exports , what would that mean Re: Add

[Evan Laforge]

> 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.