[Haskell-cafe] Design your modules for qualified import

[Henning Thielemann]

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.