At least in the case where something being hidden causes an unintended type error, compiler errors could /potentially/ be aware of the extension, though defining unintended seems non-trivial. You don't want actual type errors being replaced with "maybe you didn't realize this other function is being auto-hidden", and you definitely don't want to have to type check for different combination of hidden functions. I don't think it's really worth extending the scope, unless there's some trivial solution I'm missing.
What I want to be able to do is use a not-too-large set of more general (IO -> MonadIO) or differently monomorphic (String -> Text) functions than what I'm implicitly importing. In either case I think the change is semantically safe: any type errors you encounter are actual type errors. This should make that kind of use a little more lightweight than it is currently. I'll definitely concede it could be unsuitable behaviour by default for large projects. My coding is mostly personal-use stuff, so that's where my experience is. Is there a good example proposal somewhere for what kind of format I should follow. I'm somewhat busy at the moment, but I'll write up a more detailed proposal on the wiki by the end of the week unless someone feels compelled to beat me to it. Erik Hesselink wrote > I feel that this extension, while looking tempting for writing code > from scratch, might hurt maintainability of code. 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. > > Erik > > On Sun, Oct 19, 2014 at 1:32 AM, David Feuer < > david.feuer@ > > wrote: >> I'm generally in favor of the proposal, but I figured I should mention >> one >> situation when I personally might find this confusing. If the module >> import >> list is very long, and includes an unrestricted import of a well-known >> module, it might be easy to assume a certain well-known function comes >> from >> there, when in fact it comes from some other module on the other end of >> the >> import list. >> >> On Oct 18, 2014 6:39 PM, "Joachim Breitner" < > mail@ > > >> wrote: >>> >>> Hi, >>> >>> Am Samstag, den 18.10.2014, 11:02 -0700 schrieb htebalaka: >>> > I guess my central point is I don't see how anyone can benefit from >>> the >>> > current behaviour. For instance, a simple real world example: >>> > >>> > import Prelude >>> > import Data.Text.Lazy.IO (putStrLn) >>> >>> I find this quite convincing. If I bother to explicitly write out „take >>> putStrLn from Data.Text.Lazy.IO“, why should the compiler assume that I >>> might have meant some putStrLn from somewhere else. >>> >>> Of course, order should not matter (I don’t think anyone suggested it >>> should, I think Austin simply mis-read that). >>> >>> Greetings, >>> Joachim >>> >>> >>> -- >>> Joachim “nomeata” Breitner >>> > mail@ > • http://www.joachim-breitner.de/ >>> Jabber: > nomeata@ > • GPG-Key: 0xF0FBF51F >>> Debian Developer: > nomeata@ >>> >>> >>> _______________________________________________ >>> Glasgow-haskell-users mailing list >>> > Glasgow-haskell-users@ >>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >>> >> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> > Glasgow-haskell-users@ >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@ > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users -- View this message in context: http://haskell.1045720.n5.nabble.com/Hiding-import-behaviour-tp5758155p5758327.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users