Just to elaborate a little bit, IMO, imports are stupid and outdated. The whole way code is organized today is stupid. Files and filesystems are not necessary entirely. And there is a link to "author" and "code" that just shouldn't exist. Haskell allow us to do much better. My view is a kind of global encyclopedia of functions. What I'd suggest is that import dies completely and is replaced by a symbolic linking system that lookups on that encyclopedia. That is, mind this program:
SrPeixinho/PrintOne/main.hs
SrPeixinho.PrintOne.main = IO.print (List.head [1,2,3,4])
This is not a file at all - I'm just defining a symbol on that global repository.
If you try to compile this program with GHC, it will complain IO.print and List.sort are undefined. Instead of failing, it would lookup into that global repository, find the proper entries:
List.head (x : xs) = x
IO.print = ...
It would then download List/head.hs and IO/print.hs to your computer and compile it just fine. Of course, this requires that each symbol ever defined has an unique name, but that is cool. "List.head" has a short name because it is so common. If you are programming a different kind of list, you can just append your name to the namespace. YourName.List.head. Or, even better: you can just be clear about what is the difference and use, instead, "AppendList.head", so the community can help improving on it.
This approach would:
Set us free from ever having to type import again.
Set us free from spending hours trying organize our codebase in awkward modules that almost always don't express correctly the dependencies of your code.
Amenize considerably the cabal hell problem since, now, an update in a function only affects programs using that function. Think about it: today, if we have a module with 500 functions, one of which is buggy and barely used... fixing the definition of function will cause every library depending on your module to break, even if only 0.1% of them used that function! That is just stupid. (And in case someone actually changes the global definition of a function in a way that breaks code can be dealt with just prohibiting it. Instead, that person has to use a different name and trigger an warning that the old function is deprecated. The only drawback is that we will lose a namespace, but the guarantee that code will never break again is a really, really good tradeof.)
Make us the coolest community of the world in general because we have an wikipedia of code integrated with our compiler that is so damn cool.