Hiding import behaviour

[htebalaka]

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,
>>>>
>>>> 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-tp5758155p5758346.html
Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.