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 <hessel...@gmail.com> wrote: > 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 > _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users