Opened 10 years ago

Closed 18 months ago

#1316 closed feature request (duplicate)

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

Reported by: Isaac Dupree Owned by: simonpj
Priority: normal Milestone:
Component: Compiler Version: 6.6.1
Keywords: Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: #11438 Differential Rev(s):
Wiki Page:


for a (poor) example,

f :: a -> a
f x = x
     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?))

Change History (10)

comment:1 Changed 10 years ago by igloo

Milestone: 6.8

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).

comment:2 Changed 10 years ago by Isaac Dupree

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?

comment:3 Changed 10 years ago by Isaac Dupree

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.

comment:4 Changed 10 years ago by simonmar

Milestone: 6.8 branch6.10 branch
Owner: set to simonpj

comment:5 Changed 9 years ago by simonmar

Architecture: UnknownUnknown/Multiple

comment:6 Changed 9 years ago by simonmar

Operating System: UnknownUnknown/Multiple

comment:7 Changed 8 years ago by igloo

Milestone: 6.10 branch_|_

comment:8 Changed 7 years ago by igloo

Type of failure: None/Unknown

See also #3691.

comment:9 Changed 4 years ago by morabbin

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

comment:10 Changed 18 months ago by thomie

Resolution: duplicate
Status: newclosed

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

Also reported as #11438.

Note: See TracTickets for help on using tickets.