On Mon, Oct 20, 2014 at 11:57 PM, Mario Blažević
On 14-10-19 08:10 AM, Erik Hesselink wrote:
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.
But right now, we have a useful property that adding imports and code to a module does not break or change other code in that module. With this extension, that changes. I find this kind of local reasoning very useful, IMHO it's one of the most useful things about Haskell in general.
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.
That's a very good point. Given that and the above, I don't understand your conclusion:
Anyway, count me as +1 on the proposal. It would improve the long-term stability of Haskell code.
How is adding more ways to break something "improving the long-term stability"? Regards, Erik