Opened 7 years ago

Last modified 15 months ago

#1316 new feature request

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 Difficulty: Unknown
Test Case: Blocked By:
Blocking: Related Tickets:

Description

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

Change History (9)

comment:1 Changed 7 years ago by igloo

  • Milestone set to 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 7 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 7 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 6 years ago by simonmar

  • Milestone changed from 6.8 branch to 6.10 branch
  • Owner set to simonpj

comment:5 Changed 6 years ago by simonmar

  • Architecture changed from Unknown to Unknown/Multiple

comment:6 Changed 6 years ago by simonmar

  • Operating System changed from Unknown to Unknown/Multiple

comment:7 Changed 5 years ago by igloo

  • Milestone changed from 6.10 branch to _|_

comment:8 Changed 4 years ago by igloo

  • Type of failure set to None/Unknown

See also #3691.

comment:9 Changed 15 months 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.

Note: See TracTickets for help on using tickets.