On 23/04/2014 20:04, dm-list-haskell-librar...@scs.stanford.edu wrote:
Edward Kmett ekm...@gmail.com writes:
You can wind up in perfectly legitimate situations where the name for the
type you are working with isn't in scope, but where you can write a
combinator that would infer to have that
Not sure.
An even simpler case is something like exporting a Traversal but not
exporting Data.Traversable, which appears in the expansion, etc.
These sorts of things happen in code using lens. Older versions of lens
didn't export all of the types needed to write out the type signature long
hand
Er.. my mistake. Control.Applicative.
That is what it is we don't re-export that is used in Traversal. =)
On Wed, Apr 30, 2014 at 2:47 AM, Edward Kmett ekm...@gmail.com wrote:
Not sure.
An even simpler case is something like exporting a Traversal but not
exporting Data.Traversable, which
Of David Mazieres
| Sent: 22 April 2014 00:41
| To: Simon Peyton Jones; Haskell Libraries (librar...@haskell.org);
| core-libraries-commit...@haskell.org; GHC users
| Subject: [core libraries] Re: Tightening up on inferred type signatures
|
| Simon Peyton Jones simo...@microsoft.com writes
...@haskell.org);
| core-libraries-commit...@haskell.org; GHC users
| Subject: [core libraries] Re: Tightening up on inferred type signatures
|
| Simon Peyton Jones simo...@microsoft.com writes:
|
| GHC generally obeys this rule
|
| * If GHC infers a type f::type, then it's OK for you to add a type
