A feature being &quot;more complicated&quot; for the users to use or for the implementers to implement cannot be the SOLE reason for that feature to be discarded. If we consider implementation concerns, then we can see that the Haskell designers have included many features that are certainly candidates deserving the title: &quot;very much complicated&quot;; <br>

<div style="margin-left:40px"><br>e.g. various constructs from category theory, or <br>       support for lazy evaluation, or <br>       features being targeted for the &quot;Data Parallel Haskell&quot;<br>and so on<br></div>

<br>In particular, I am interested in knowing whether this feature is in direct conflict with any other features the Haskell has.<br><br>- Damodar<br><br><div class="gmail_quote">On Sun, Sep 16, 2012 at 5:50 PM, Edward Z. Yang <span dir="ltr">&lt;<a href="mailto:ezyang@mit.edu" target="_blank">ezyang@mit.edu</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Excerpts from damodar kulkarni&#39;s message of Sun Sep 16 12:37:41 +0200 2012:<br>
<div class="im">&gt; Do you know any document pointing out the rationale behind this decision<br>
&gt; about modules taken by the Haskell designers?<br>
<br>
</div>While I don&#39;t know about the rationale behind this particular decision,<br>
Haskell&#39;s module system is purposely quite simple.  Languages like ML<br>
have more complicated module systems which allow the sort of things that<br>
you mentioned (and more!) but while they are more expressive they are also<br>
more complicated.<br>
<span class="HOEnZb"><font color="#888888"><br>
Edward<br>
</font></span></blockquote></div><br><br clear="all"><br><br>