<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">
<div><span class="e" id="q_11a883632923fe47_0"><br>
On Sat, 14 Jun 2008, Sebastian Sylvan wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
On Sat, 14 Jun 2008, Sebastian Sylvan wrote:<br>
<br>
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>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<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>
I really don't see how this is a big problem. Lots of languages do<br>
</blockquote>
hierarchical import (e.g. .Net languages) and I don't think I've ever<br>
heard<br>
anyone complain about this particular aspect of it.<br>
<br>
</blockquote>
<br>
It's not a problem for you and thus you do not pay attention to these<br>
complaints, I suspect. Maybe the people who would complain about the<br>
importing style, simply don't use the mentioned languages.<br>
<br>
<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<br>
help you sort it out. Plus, it's not like you can't just qualify the import<br>
to make it easier to see where it comes from if you really think it's a<br>
problem:<br>
<br>
</blockquote>
<br>
Cf.<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>
Haskell can re-export modules, which makes tracing identifiers more<br>
difficult. I want to be able to read modules without using a tool.<br>
<br>
</blockquote>
<br>
I'm not sure I understand you point. You're so opposed to the *option* of<br>
allowing hierarchical exports (even though you can still import it qualified<br>
if you personally like having to specify at each callsite exactly where some<br>
identifier is coming from),<br>
</blockquote>
<br></span></div>
I was concerned with the _import_ part of your proposal. (I haven't thought about the export part so far.)<span class="q"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
<br>
I really don't see why adding this option hurts you, when it clearly helps<br>
enable doing what this thread advocates (use qualified modules to<br>
distinguish between functions of the same name, rather than adding a bunch<br>
of prefixes/suffixes to the functions).<br>
</blockquote>
<br></span>
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<br>
<br>
import Graphics.UI.Gtk<br>
<br>
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.<br>
</blockquote></div><p>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.</p>
<p>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.</p>
<p>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.. </p>
<p>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)...<br clear="all">
</p><br>-- <br>Sebastian Sylvan<br>+44(0)7857-300802<br>UIN: 44640862