[Haskell-cafe] Design your modules for qualified import

[Sebastian Sylvan]

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.

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

-- 
Sebastian Sylvan
+44(0)7857-300802
UIN: 44640862
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080614/60df56e6/attachment.htm