Hiding import behaviour

Mario Blažević mblazevic at stilo.com
Mon Oct 20 21:57:30 UTC 2014


On 14-10-19 08:10 AM, Erik Hesselink wrote:
> I feel that this extension, while looking tempting for writing code
> from scratch, might hurt maintainability of code.

	That depends on how you define maintainability.

> Adding an explicit
> import can suddenly cause type errors in completely unrelated places
> (when it hides an implicit import and the new function is type
> incorrect), or worse, can cause semantic change (when it hides an
> implicit import and the new function is type correct, but has
> different behavior). Remember that not all code is written by the same
> person, or in a short time frame, so not everybody might fully
> understand every module and every import of the code they're editing.

	Your example requires somebody actively editing the import list. A code 
change causes a compile error or worse? That is not all that surprising.

	No, what I find much worse is a cabal update causing an error in a 
module that was correct before the update. Consider

 > module Main where
 >
 > import Foo (foo)
 > import Bar
 >
 > main = foo

	Now suppose Bar came from the package bar-1.0, and the new version 
bar-1.0.1 decides to export foo. With the current behaviour, this change 
would break my module. With Malcolm's proposal the old code would 
continue to work.

	Anyway, count me as +1 on the proposal. It would improve the long-term 
stability of Haskell code.



More information about the Glasgow-haskell-users mailing list