On Mon, Oct 20, 2014 at 11:57 PM, Mario Blažević <mblaze...@stilo.com> wrote: > 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 _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users