Hiding import behaviour

[Richard Eisenberg]

I'm having a hard time keeping track of what's going on in this discussion. But, I'm generally in favor of making *some* change along the lines discussed here, and also in #9702 (https://ghc.haskell.org/trac/ghc/ticket/9702). Could the proposers of various features perhaps create a wiki page, naming the individual pieces or proposals, and then we can have something closer to a vote among a stable list of candidates?

Thanks!
Richard

On Oct 21, 2014, at 7:14 AM, Erik Hesselink <hesselink at gmail.com> wrote:

> On Mon, Oct 20, 2014 at 11:57 PM, Mario Blažević <mblazevic at 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 at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>