Hiding import behaviour

[Erik Hesselink]

On Tue, Oct 21, 2014 at 4:55 PM, Mario Blažević <mblazevic at stilo.com> wrote:
> On 14-10-21 07:14 AM, Erik Hesselink wrote:
>>
>> On Mon, Oct 20, 2014 at 11:57 PM, Mario Blažević <mblazevic at stilo.com>
>> wrote:
>>>          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"?
>
>
>         You seem determined to misunderstand every message in this thread.
> What I said was that the change from bar-1.0 to bar-1.0.1 breaks the example
> code *with the current behaviour*. The proposal removes this breakage.
> Anything that keeps the old code compiling and working with new libraries
> improves its long-term stability in my book.
>
>         Note that the bar-1.0.1 upgrade wasn't even a major version change.
> This is correct according to the PVP:

You're right, I misread your message. I understand now, and you're
right that this is currently something that can break your package,
although it happens so rarely that people still depend on major
version ranges, even though they sometimes don't use explicit or
qualified imports.

Regards,

Erik