<div dir="ltr"><div class="gmail_quote">On Fri, Jan 16, 2009 at 4:42 PM, <a href="mailto:eyal.lotem@gmail.com">eyal.lotem@gmail.com</a> <span dir="ltr"><<a href="mailto:eyal.lotem@gmail.com">eyal.lotem@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hi,<br>
<br>
I would like to suggest a change to Haskell prime's handling of<br>
imports.<br>
<br>
First, let me define a few terms:<br>
<br>
Qualified import:<br>
import qualified Data.Map [as Map]<br>
<br>
Closed-unqualified import:<br>
import Data.Map(Map, lookup)<br>
<br>
Open-unqualified import:<br>
import Data.Map<br>
<br>
I believe that the last type, open-unqualified is a really bad idea,<br>
and should be discouraged or even disallowed. It should definitely not<br>
be the default, like it is today.<br>
<br>
These are my reasons:<br>
<br>
A) Most importantly, reading code that has even a few open unqualified<br>
imports makes deciphering where names are coming from really<br>
difficult. The other two forms make it really easy. Code is read<br>
more often than it is written -- lets optimize for the reading case.<br>
<br>
B) Code that has open unqualified imports may break when new symbols<br>
are added to the libraries its importing. This means that libraries<br>
cannot even be considered backwards compatible if they retain<br>
semantics, but add new exported names.<br>
<br>
C) In my experience, Haskell modules can map their semantics to<br>
standard type-classes such as Monoid, Functor, Applicative, etc. This<br>
means that many Haskell modules can do without exporting many names.<br>
Sometimes, they can export no names at all (Only instances). This<br>
means that closed-unqualified imports often do just fine. When there<br>
are many exported names, qualified imports are good.<br>
<br>
-----------------<br>
<br>
I think currently many modules are designed to be imported<br>
unqualified, and this is unfortunate. Haskell' libraries can fix<br>
this. For example, the various Monadic counterparts such as mapM,<br>
replicateM, etc could do without the "M" in their names, and one could<br>
use:<br>
<br>
import qualified Control.Monad as M<br>
<br>
M.for<br>
M.map<br>
<br>
and so on.<br>
<br>
Additionally, I think there are some strong sentiments against the<br>
choice of the function-composition dot as the qualified module name<br>
lookup symbol. It discourages people from using qualified imports.<br>
Some other symbol ought to be used, but its not clear which symbol is<br>
free. Perhaps if unicode operators are allowed, then function<br>
composition can move to the "right" symbol.<br>
<br>
I believe qualified imports should probably have this syntax:<br>
<br>
import Control.Monad as M<br>
<br>
Closed-qualified imports can remain in the same syntax.<br>
Open-qualified imports should probably be discouraged with a syntax<br>
like:</blockquote><div>Correction:<br> <br>Closed-unqualified imports can remain in the same syntax.<br>
Open-unqualified imports should probably be discouraged with a syntax<br>
like:<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<br>
import unqualified Control.Monad<br>
<br>
And symbol clashes with these should probably just always choose the<br>
overriding name.<br>
<br>
Additionally, it would be nice if open unqualified imported were</blockquote><div>imported -> imports <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
considered quick&dirty enough for -Wall to warn that they generate<br>
name clashes or are more difficult to read, to further discourage<br>
them.<br>
<font color="#888888"><br>
Eyal<br>
</font></blockquote></div><br></div>