On Wed, Aug 5, 2015 at 3:38 PM <amindfv@gmail.com> wrote:
A couple syntactic concerns (assuming there's a sane semantics with eg typeclass instances):

 - This seems essentially like name shadowing, which is a source of confusion and therefore bugs (-Wall warns about it)

It would be the same as normal name resolution. For example, right now you can do

foo = id True
  where id a = a

foo.hs:2:9: Warning:
    This binding for ‘id’ shadows the existing binding
      imported from ‘Prelude’ at foo.hs:1:1
      (and originally defined in ‘GHC.Base’)

Prelude.id was introduced in a higher scope, so the definition shadows it.

If you do this

foo = id True
  where import Prelude (id)
        id a = a

Then that should fail with "Ambiguous occurrence 'id'".

If importing would shadow a top-level definition, then that should probably trigger a warning. E.g.,

import Prelude hiding (id)

id a = a

foo = id True
  where import Prelude (id)

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).
 
 - This makes me unable to see what a module imports by looking at the import statements at the top of a file

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.
 
 - It seems like using "H.width" and "C.width" isn't very costly

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 could 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 could make Haskell unreadable.

ocharles