[Haskell-cafe] Design your modules for qualified import
lemming at henning-thielemann.de
Sat Jun 14 13:53:48 EDT 2008
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
>>> 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
>> 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
brings module qualifications Window and Button into scope although they
are not explicitly mentioned. Thus I could no longer find out easily what
More information about the Haskell-Cafe