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,
I guess my central point is I don't see how anyone can benefit from
Am Samstag, den 18.10.2014, 11:02 -0700 schrieb htebalaka: 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-tp5758155p57583... Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.