<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Wed, Aug 5, 2015 at 3:38 PM <<a href="mailto:amindfv@gmail.com" target="_blank">amindfv@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>A couple syntactic concerns (assuming there's a sane semantics with eg typeclass instances):</div><div><br></div><div> - This seems essentially like name shadowing, which is a source of confusion and therefore bugs (-Wall warns about it)</div></div></blockquote><div><br></div><div>It would be the same as normal name resolution. For example, right now you can do</div><div><br></div><div><div><font face="monospace, monospace">foo = id True</font></div><div><font face="monospace, monospace">  where id a = a</font></div></div><div><font face="monospace, monospace"><br></font></div><div><div><font face="monospace, monospace">foo.hs:2:9: Warning:</font></div><div><font face="monospace, monospace">    This binding for ‘id’ shadows the existing binding</font></div><div><font face="monospace, monospace">      imported from ‘Prelude’ at foo.hs:1:1</font></div><div><font face="monospace, monospace">      (and originally defined in ‘GHC.Base’)</font></div></div><div><br></div><div>Prelude.id was introduced in a higher scope, so the definition shadows it.</div><div><br></div><div>If you do this</div><div><br></div><div><div><font face="monospace, monospace">foo = id True</font></div><div><font face="monospace, monospace">  where import Prelude (id)</font></div><div><font face="monospace, monospace">        id a = a</font></div></div><div><br></div><div>Then that should fail with "Ambiguous occurrence 'id'".</div><div><br></div><div>If importing would shadow a top-level definition, then that should probably trigger a warning. E.g.,</div><div><br></div><div><font face="monospace, monospace">import Prelude hiding (id)</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">id a = a</font></div><div><font face="monospace, monospace"><br></font></div><div><div><font face="monospace, monospace">foo = id True</font></div><div><font face="monospace, monospace">  where import Prelude (id)</font></div></div><div><br></div><div>Would warn that the import shadows the top-level definition of id (which is the same behavior as if you declared another id in the where clauses for foo).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div> - This makes me unable to see what a module imports by looking at the import statements at the top of a file</div></div></blockquote><div><br></div><div>Correct. But it does not make it impossible for a tool to determine what imports are available. This is also proposed as an extension, so of course if you don't want to use it, you wouldn't have to.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div> - It seems like using "H.width" and "C.width" isn't very costly</div></div></blockquote><div><br></div><div>In practice I use a lot more than just two symbols. The point is the repeated qualification quickly introduces more noise and obscures the intent of the code. It also introduces a disconnect in the code - where did H come from? Time to jump all the way to the top of the file to find out. Of course, under my proposal it <i>could</i> be even harder to find out where H came from, but that is a decision that the (code) author decided on - and there are already many ways we <i>could</i> make Haskell unreadable.<div dir="auto"><div><br></div><div><i>ocharles</i> </div></div></div></div></div>