On Wed, Aug 5, 2015 at 3:38 PM
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*