wrote:
> Proposal is up for your viewing pleasure:
> http://www.haskell.org/haskellwiki/PermissiveImportsProposal
>
>
>
> --
> View this message in context:
> http://haskell.1045720.n5.nabble.com/Hiding-import-behaviour-tp5758155p5758553.html
> Sent from the Haskell - Glasgow-ha
Proposal is up for your viewing pleasure:
http://www.haskell.org/haskellwiki/PermissiveImportsProposal
--
View this message in context:
http://haskell.1045720.n5.nabble.com/Hiding-import-behaviour-tp5758155p5758553.html
Sent from the Haskell - Glasgow-haskell-users mailing list archive at
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
sting ambiguous identifier occurrence
error could still fire. Really just depends where in the pipeline the change
is implemented.
I suppose I'll describe both possible implementations. Functionally they're
the same, but maybe this one is simpler.
--
View this message in
Note that the bar-1.0.1 upgrade wasn't even a major version
>> change.
>> This is correct according to the PVP:
>
> You're right, I misread your message. I understand now, and you're
> right that this is currently something that can break your package,
>
On Tue, Oct 21, 2014 at 4:55 PM, Mario Blažević wrote:
> On 14-10-21 07:14 AM, Erik Hesselink wrote:
>>
>> On Mon, Oct 20, 2014 at 11:57 PM, Mario Blažević
>> wrote:
>>> No, what I find much worse is a cabal update causing an error in
>>> a
>>> module that was correct before the update.
On 14-10-21 07:14 AM, Erik Hesselink wrote:
On Mon, Oct 20, 2014 at 11:57 PM, Mario Blažević wrote:
On 14-10-19 08:10 AM, Erik Hesselink wrote:
Adding an explicit
import can suddenly cause type errors in completely unrelated places
(when it hides an implicit import and the new function is typ
Hi Erik,
> But right now, we have a useful property that adding imports and code
> to a module does not break or change other code in that module. With
> this extension, that changes.
So your biggest concern is about silent breakage of code, that suddenly
a different function is used which has t
I'm having a hard time keeping track of what's going on in this discussion.
But, I'm generally in favor of making *some* change along the lines discussed
here, and also in #9702 (https://ghc.haskell.org/trac/ghc/ticket/9702). Could
the proposers of various features perhaps create a wiki page, na
On Mon, Oct 20, 2014 at 11:57 PM, Mario Blažević wrote:
> On 14-10-19 08:10 AM, Erik Hesselink wrote:
>>
>> 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 caus
On 14-10-19 08:10 AM, Erik Hesselink wrote:
I feel that this extension, while looking tempting for writing code
from scratch, might hurt maintainability of code.
That depends on how you define maintainability.
Adding an explicit
import can suddenly cause type errors in completely unre
nk Austin simply mis-read that).
>>>>
>>>> Greetings,
>>>> Joachim
>>>>
>>>>
>>>> --
>>>> Joachim “nomeata” Breitner
>>>>
>> mail@
>> • http://www.joachim-breitner.de/
>>>> Jabber:
>> nomeata@
>>
@
>>>
>>>
>>> ___
>>> Glasgow-haskell-users mailing list
>>>
> Glasgow-haskell-users@
>>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>&
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 caus
On 2014-10-19 at 00:39:42 +0200, Joachim Breitner wrote:
>> 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 bo
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
t
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 bot
l be ambiguous, unless you hide it from every
>>>> other module that might
>>>> export a function with the same name. I would think the fact that it
>>>> shouldn't be implicitly imported from other modules would directly
>>&
>
>>> I can't speak to tooling, though I suppose if this doesn't get
>>> implemented
>>> I'll write my own. Just to be very clear, supposing you have some Import
>>> datatype which stores a list of any identifiers that are being
>>>
ap fmap appendHiddenImports) <*> collectOnly where
>> collectOnly :: [Import] -> [Identifier]
>> collectOnly = concat . mapMaybe getExplicitImports
>> appendHiddenImports :: [Identifier] -> Import -&g
icitly
>> imported unqualified (or conversely, a list of any identifiers that are
>> being hidden), then the behaviour I'm suggesting is a pragma to enable
>> something like this:
>>
>> hide :: [Import] -> [Import]
>> hide = flip (fmap fmap appendHiddenIm
collectOnly :: [Import] -> [Identifier]
> collectOnly = concat . mapMaybe getExplicitImports
> appendHiddenImports :: [Identifier] -> Import -> Import
> getExplicitImports :: Import -> Maybe [Identifier]
>
> where appendHiddenImports would only change import stateme
> Import -> Import
> getExplicitImports :: Import -> Maybe [Identifier]
>
> where appendHiddenImports would only change import statements that import
> an
> unspecified number of unqualified identifiers, like "import X hiding (x,
> y)"
> or "import Y".
>
&g
s that import an
unspecified number of unqualified identifiers, like "import X hiding (x, y)"
or "import Y".
--
View this message in context:
http://haskell.1045720.n5.nabble.com/Hiding-import-behaviour-tp5758155p5758246.html
Sent from the Haskell - Glasgow-haskell-use
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 17/10/14 00:40, Austin Seipp wrote:
> Maybe there are some cases today where something like this could
> happen, but this seems awfully, awfully implicit and hard-to-follow
> as a language feature.
>
> In general I think a program that has impor
View this message in context:
http://haskell.1045720.n5.nabble.com/Hiding-import-behaviour-tp5758155p5758166.html
Sent from the Haskell - Glasgow-haskell-users mailing list archive at
Nabble.com.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-
have access to that information
> though.
>
>
>
> --
> View this message in context:
> http://haskell.1045720.n5.nabble.com/Hiding-import-behaviour-tp5758155p5758161.html
> Sent from the Haskell - Glasgow-haskell-users mailing list archive at
> Nabble.com.
> __
need to be aware that Foo exports x,
because otherwise there would be no way to know that x needs to be hidden
from Bar. I assume GHC already would have access to that information though.
--
View this message in context:
http://haskell.1045720.n5.nabble.com/Hiding-import-behaviour-tp5758155p57
My first thought is: Wouldn't this make it impossible to reorder or
sort imports lexicographically (or otherwise), without fully parsing,
renaming and typechecking the code?
For example, I often use ghc-mod plus stylish-haskell to order and
format my imports. If there is no syntactic indication th
I think this is a great idea. I also think it should apply to the name
shadowing warning—identifiers imported implicitly should never trigger that.
On Thu, Oct 16, 2014 at 6:19 PM, Malcolm Gooding wrote:
> With the prelude changes that people have been discussing recently
> I've been wondering i
With the prelude changes that people have been discussing recently
I've been wondering is there any reason why importing an identifier
explicitly and unqualified doesn't automatically hide any implicit
imports of the same identifier? Specifically I'm wondering about cases
where you've imported an i
31 matches
Mail list logo
