<br><br><div><span class="gmail_quote">On 6/14/08, <b class="gmail_sendername">Henning Thielemann</b> <<a href="mailto:lemming@henning-thielemann.de">lemming@henning-thielemann.de</a>> wrote:</span><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="q"><br>
On Sat, 14 Jun 2008, Sebastian Sylvan wrote:<br>
<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="q">
On 6/14/08, Henning Thielemann <<a href="mailto:lemming@henning-thielemann.de" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">lemming@henning-thielemann.de</a>> wrote:<br>
</span><span class="q"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
The problem would be again that no one knows, where "Window" comes from.<br>
Better would be<br>
<br>
</blockquote>
I really don't see how this is a big problem. Lots of languages do<br>
hierarchical import (e.g. .Net languages) and I don't think I've ever heard<br>
anyone complain about this particular aspect of it.<br>
</span></blockquote>
<br><p>
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.</p><span class="q">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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:<br>
</blockquote>
<br></span>
Cf.<span class="q"><br>
<a href="http://www.haskell.org/haskellwiki/Import_modules_properly" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://www.haskell.org/haskellwiki/Import_modules_properly</a><br>
<br></span>
Haskell can re-export modules, which makes tracing identifiers more difficult. I want to be able to read modules without using a tool.<br>
</blockquote></div><br><p>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), 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.</p>
<p>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).<br clear="all">
</p><br>-- <br>Sebastian Sylvan<br>+44(0)7857-300802<br>UIN: 44640862