Hiding import behaviour
Erik Hesselink
hesselink at gmail.com
Tue Oct 21 11:14:37 UTC 2014
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
More information about the Glasgow-haskell-users
mailing list