add warning for local type signatures that use the same type variable names as outer type signatures

for a (poor) example,

f :: a -> a
f x = x
   where
     g :: a  --this is (forall x. x) not the 'a' from f's type signature
             -- So, warn about this signature.
     g = undefined

Because it is likely to be confusing, as well as interfering with any possibility of the type variables being considered scoped by default. In fact, this may be a helpful/explanatory message in cases where there will also be a type error due to the type variables not actually being scoped. (although, detecting those cases particularly and giving a recommended solution for how to give such a type signature, would be a more difficult endeavor (what to recommend?))

Trac metadata

Trac field	Value
Version	6.6.1
Type	FeatureRequest
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	Compiler
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system	Unknown
Architecture	Unknown

changed weight to 5

added Tfeature request Trac import labels

I don't think this is a warning that we would want in -Wall, as common practice is to reuse the same type variables (a, b, c) for each type signature.

However, it would be useful to people want to see how much of an effect scoped type ariables would have on existing code (which it sounds like is Isaac's motivation).

Indeed. How to interact with local recursive bindings such as let? I think it had better not warn about type variable names being shared between those, as I'm sure that is natural common practice.

More generally, scoped type variables are a little limited; personally, I like the (type X) / let type X approach (I wonder if there would be a particularly great difficulty implementing that in Haskell systems weaker than GHC's? GHC and JHC have strong enough internal type systems, Yhc/nhc98 have untyped internal representations, GHC doesn't even use its internal representation for typechecking...)

So I think it can be specified by: would the program be affected by using explicit GHC-style foralls at the beginning of all the type-signatures that have implicit universal quantification?

well, saying "like ghc foralls" is to say, the same scoping considerations. Just adding foralls everywhere at once wouldn't actually be the right sort of thing here.

changed milestone to %6.10 branch

assigned to @simonpj

Trac metadata

Trac field	Value
Architecture	Unknown → Unknown/Multiple

Trac metadata

Trac field	Value
Operating system	Unknown → Unknown/Multiple

removed milestone

mentioned in issue #3691 (closed)

See also #3691 (closed).

Trac metadata

Trac field	Value
TypeOfFailure	- → OtherFailure

To summarize, the proposal is that code like the o.p.'s should produce a warning when -XScopedTypeVariables is not in effect.

mentioned in issue #9244

mentioned in issue #11438 (closed)

closed

Closing as a duplicate of #9244, which has a more complete test case, and suggestions for how to implement this.

Also reported as #11438 (closed).

Trac metadata

Trac field	Value
Resolution	Unresolved → ResolvedDuplicate
Related	- → #11438 (closed)

mentioned in issue #12716 (closed)

added Pnormal label