[Haskell-cafe] Design your modules for qualified import

[Isaac Dupree]

Sebastian Sylvan wrote:
> On 6/14/08, Henning Thielemann <lemming at henning-thielemann.de> wrote:
>>
>> On Sat, 14 Jun 2008, Sebastian Sylvan wrote:
>>
>>  On 6/14/08, Henning Thielemann <lemming at henning-thielemann.de> wrote:
>>>>
>>>> On Sat, 14 Jun 2008, Sebastian Sylvan wrote:
>>>>
>>>>  On 6/14/08, Henning Thielemann <lemming at henning-thielemann.de> wrote:
>>>>
>>>>>
>>>>>> The problem would be again that no one knows, where "Window" comes
>>>>>> from.
>>>>>> Better would be
>>>>>>
>>>>>>  I really don't see how this is a big problem. Lots of languages do
>>>>>>
>>>>> hierarchical import (e.g. .Net languages) and I don't think I've ever
>>>>> heard
>>>>> anyone complain about this particular aspect of it.
>>>>>
>>>>>
>>>> It's not a problem for you and thus you do not pay attention to these
>>>> complaints, I suspect. Maybe the people who would complain about the
>>>> importing style, simply don't use the mentioned languages.
>>>>
>>>>  The worst case scenario is that you need a little bit of tool support to
>>>>> help you sort it out. Plus, it's not like you can't just qualify the
>>>>> import
>>>>> to make it easier to see where it comes from if you really think it's a
>>>>> problem:
>>>>>
>>>>>
>>>> Cf.
>>>>  http://www.haskell.org/haskellwiki/Import_modules_properly
>>>>
>>>>  Haskell can re-export modules, which makes tracing identifiers more
>>>> difficult. I want to be able to read modules without using a tool.
>>>>
>>>>
>>> I'm not sure I understand you point. You're so opposed to the *option* of
>>> allowing hierarchical exports (even though you can still import it
>>> qualified
>>> if you personally like having to specify at each callsite exactly where
>>> some
>>> identifier is coming from),
>>>
>> I was concerned with the _import_ part of your proposal. (I haven't thought
>> about the export part so far.)
>>
>>  that you'd rather any library making use of a module hierarchy is forced
>>> to either make the user add dozens of boilerplate import statements (with
>>> "qualified" and "as") or the more common strategy of prefixing each function
>>> call with the module name (buttonNew)? To me a module system that requires
>>> the latter in practice is horribly broken, and I'm suggesting a low-impact
>>> way of fixing it. It may not be the best system available, but it's a tiny
>>> extension of the current.
>>>
>>> I really don't see why adding this option hurts you, when it clearly helps
>>> enable doing what this thread advocates (use qualified modules to
>>> distinguish between functions of the same name, rather than adding a bunch
>>> of prefixes/suffixes to the functions).
>>>
>> Button.new is my favorite, because with current import variants I can
>> easily lookup, what Button and Button.new refer to. I understand your
>> proposal in that way that
>>
>> import Graphics.UI.Gtk
>>
>> brings module qualifications Window and Button into scope although they are
>> not explicitly mentioned. Thus I could no longer find out easily what
>> Butten.new means.
>>
> I don't see why this is so bad when it's exactly what we have for other
> identifiers? E.g. if you import Control.Monad you get mapM, but you can't
> really say for sure where this identifier comes from, which is no better
> than not knowing where "Button.new" comes from. In both cases you have the
> option to qualify the module import so you have to say "Monad.mapM" or
> "GTK.Button.new" which makes it more apparent.
> 
> I suppose you would make the "hiding" clause and the "import list" thing
> work with modules too for consistency, so if you really wanted to you could
> list the modules/identifiers that you bring in.

yeah, we could come up with a syntax. one that gives privileged meaning 
to hierarchy.  If used according to "design your modules for qualified 
import", it would still allow fairly easy use and looking up function uses.

import Graphics.UI.GTK (import qualified Button, import qualified Window)

then you get Button.f (because Graphics.UI.GTK wasn't imported 
qualified), Graphics.UI.GTK.Button.f, (not f or Graphics.UI.GTK.f 
because of qualified Button)  ... they're normal import statements 
inside.  What it saves is the duplication of Graphics.UI.GTK and 
"....Button as Button".  Not sure I like how long "import qualified" is, 
repeated there, but it seemed much less confusing than anything shorter.

import Data (import qualified Map, Map.Map)
or
import Data (import qualified Map, import Map(Map))
or a shortcut for that common pattern of importing a few things unqualified
import Data (import qualified Map and (Map))
aka. import qualified Data.Map as Map and (Map)
aka. import qualified Data.Map as Map (empty,singleton,...) and (Map)
or perhaps "unqualifying" rather than "and"

personally I would like it if we could also import (f as g) if we wanted 
to rename an "f" we were importing, to "g" in the module and re-exports, 
without having to be concerned about (for lowercase) monomorphism 
restriction, (for types) whether a synonym will work properly everywhere 
(not without extensions!), (for constructor, record fields, and classes) 
simple *impossibility*.  That wish is only related in that it's a 
related generalization, though.

hmm.

-Isaac

> Are you saying that you prefer the situation where to use GTK the user would
> have to explicitly import every single sub-module in the hierarchy ("import
> qualified Graphics.UI.GTK.X as X" where X = {Button,Window, ... etc})? I
> don't think that's very nice at all, and I certainly don't like having to
> add the module name to the functions... I think lots of libraries are like
> that, and we need some mechanism of importing lots of related modules
> together so that they come in qualified, without forcing the user to write a
> gazillion lines of boilerplate import statements..
> 
> I think that if GTK did use this system (rather than append the module name
> to the function and export them "flatly") a lot of people would resort to
> ugly hacks like putting the import statements in a file somewhere and using
> the C preprocessor to include it, yuck! (OTOH this may be just what's
> required to convince everyone that we need to improve the module system)...
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe