There is one more case that I hadn't considered that would be kind of ambiguous. If you import something like "import Control.Comonad (Comonad(..))" it's unclear if the compiler should automatically treat it as if you added "hiding (Comonad(..))" to implicit imports, or added "hiding (Comonad, extend, extract, duplicate)". The former could hide identifiers from modules that define Comonad differently, and might still cause using Comonads methods to be ambiguous. The latter resolves the ambiguity, but could change what is automatically hidden if the Comonad typeclass is ever changed. In some sense the methods being imported from Comonad could still be considered implicit, since they aren't being imported individually by name. Unless people feel differently, I'd propose neither solution, since users would be confused if they assumed the wrong way the compiler did, and silent changes to what is being imported would be bad things. Instead they would still get an ambiguous occurrence as they do now. It also makes its behaviour more uniform: only identifiers imported *by name* are auto-hidden. For a pragma, AutoHidingImports? htebalaka wrote
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.