ross:

On Wed, Apr 30, 2008 at 04:55:47PM -0700, Don Stewart wrote:

...

ross:

...

A previous proposal:

http://hackage.haskell.org/trac/ghc/ticket/1773

split the Arrow class, making (>>>) and (<<<) functions in Control.Category. This breaks programs that use Control.Arrow.

To avoid some of the breakage, the proposal is that Control.Arrow should re-export (>>>) and (<<<), imported from Control.Category.

This patch has been applied (xmonad was broken due to the change, so I thought it best to act).

I thought we had a process for API changes.

Yeah, that's my fault. I saw Duncan submitted the proposal about a week ago, and no one had objected, and then I ran into xmonad breaking due to it.

I'm not sure what the right thing is here. I usually prefer to avoid re-exports because they create problems with warnings.

If it is objected to we can revert. -- Don

Quite right. Please a bug report with a repo case if there is a bug. Thanks Simon | -----Original Message----- | From: libraries-bounces@haskell.org [mailto:libraries-bounces@haskell.org] On | Behalf Of Niklas Broberg | Sent: 01 May 2008 19:30 | To: libraries@haskell.org | Subject: Re: proposal #2254: have Control.Arrow re-export (>>>) and (<<<) | | > I'm not sure what the right thing is here. I usually prefer to avoid | > re-exports because they create problems with warnings. | | I think this is a bit sad actually. The situation discussed here is | (IMO) exactly the kind of situation that re-exports are intended for. | That some tools give warnings for re-exports is a flaw in those tools, | not a problem with the re-export per se. | | Generally, if module A exports foo, module B imports A and re-exports | foo, and module C imports both A and B, there should be no ambiguity. | Not even if it reexports all of modules A and B. Why would e.g. GHC | need to warn in that case? | | Cheers, | | /Niklas | _______________________________________________ | Libraries mailing list | Libraries@haskell.org | http://www.haskell.org/mailman/listinfo/libraries

| Is it the same as this one? http://hackage.haskell.org/trac/ghc/ticket/1148 | | I use qualified imports, and I see it on about half the modules I compile. I don't think so. I believe the original message concerned a variable or type that was in scope in two different ways. Niklas said | Generally, if module A exports foo, module B imports A and re-exports | foo, and module C imports both A and B, there should be no ambiguity. | Not even if it reexports all of modules A and B. Why would e.g. GHC | need to warn in that case? Perhaps Niklas can say whether #1148 is the bug he is describing, and if not file a new one? Simon

Aha. So now it's unclear what the desired behaviour is. Do we want a warning for import statements that can be deleted altogether? If not, I can easily remove it! Or is it just the wording of the warning that is bad? S | -----Original Message----- | From: libraries-bounces@haskell.org [mailto:libraries-bounces@haskell.org] On Behalf Of Ross Paterson | Sent: 02 May 2008 09:10 | To: libraries@haskell.org | Subject: Re: proposal #2254: have Control.Arrow re-export (>>>) and (<<<) | | On Fri, May 02, 2008 at 08:30:03AM +0100, Simon Peyton-Jones wrote: | > | Generally, if module A exports foo, module B imports A and re-exports | > | foo, and module C imports both A and B, there should be no ambiguity. | > | Not even if it reexports all of modules A and B. Why would e.g. GHC | > | need to warn in that case? | > | > Perhaps Niklas can say whether #1148 is the bug he is describing, and if not file a new one? | | Niklas's example: | | module A where | foo x = x | | module B(foo) where | import A | | module C where | import A | import B | c = foo 'a' | | ghc -W says | | C.hs:2:0: | Warning: Module `A' is imported, but nothing from it is used, | except perhaps instances visible in `A' | To suppress this warning, use: import A() | | It's true that the import can be deleted, but not that "nothing from it | is used". | _______________________________________________ | Libraries mailing list | Libraries@haskell.org | http://www.haskell.org/mailman/listinfo/libraries

...

Perhaps Niklas can say whether #1148 is the bug he is describing, and if not file a new one?

Niklas's example:

module A where foo x = x

module B(foo) where import A

module C where import A import B c = foo 'a'

ghc -W says

C.hs:2:0: Warning: Module `A' is imported, but nothing from it is used, except perhaps instances visible in `A' To suppress this warning, use: import A()

It's true that the import can be deleted, but not that "nothing from it is used".

This is actually not what I was hinting at, I'll see if I can reproduce the bug I experienced. The basic idea behind it was that module A in package a defines some type class, with member function foo. Modules B and C in packages b and c separately import A and create instances of that class, and reexports foo. Then module D in package D cannot import both B and C and use foo, it will give an "Ambiguous occurence" error. I tried reproducing this in a simpler setting, with ABCD all in one package, but the error wouldn't appear. I hope I wasn't imagining things (or rather, it would be good if I was :-)). There may have been some qualified imports involved too... But there are a few other inconvenient behaviors related only to warnings, for instance module A where foo x = x module B(foo) where import A module C (module A, module B) where import A import B %> ghc --make C.hs -W: C.hs:1:20: Warning: `foo' is exported by `module B' and `module A' That's certainly true, but it's the same 'foo'. Just a warning of course, and I'm not so sure I would argue that it shouldn't be there. It's the same kind of warning as with any other multiple export of a symbol I guess. But this pattern is not uncommon (in my code at least), so the warning is inconvenient. Then again, that particular warning can be turned off. Another, somewhat stranger, behavior: module A where foo x = x module B(foo) where import A module C(foo) where import A module D () where import B import C bar x = foo x %> ghc --make D.hs -W D.hs:2:0: Warning: Module `B' is imported, but nothing from it is used, except perhaps instances visible in `B' To suppress this warning, use: import B() D.hs:3:0: Warning: Module `C' is imported, but nothing from it is used, except perhaps instances visible in `C' To suppress this warning, use: import C() D.hs:4:0: Warning: Defined but not used: `bar' This might be said to be a bug, although it's a bug that would rarely bite you, since it requires that 'bar' is not exported (or used in something that is exported). If you export bar, then the warning talks only of B - which is a rather arbitrary choice. I'll see what I can do about that more serious bug. As regards to this particular discussion though - my main point is that we shouldn't make decisions on libraries based on what tools make of them, rather the other way around. Obvious perhaps (I hope), but bears repeating. :-) Cheers, /Niklas