Hiding import behaviour

htebalaka goodingm at gmail.com
Sun Oct 19 19:02:52 UTC 2014


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.


More information about the Glasgow-haskell-users mailing list