Re: [Haskell-cafe] Design your modules for qualified import

On Sat, 14 Jun 2008, Sebastian Sylvan wrote:

On 6/14/08, Henning Thielemann wrote:

...

On Sat, 14 Jun 2008, Sebastian Sylvan wrote:

On 6/14/08, Henning Thielemann 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.