Opened 12 months ago

Last modified 10 months ago

#15687 new feature request

Type synonym unused binds no warning?

Reported by: AntC Owned by:
Priority: normal Milestone: 8.6.1
Component: Compiler (Parser) Version: 8.6.1
Keywords: Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: GHC accepts invalid program Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description

I was taken aback this was accepted

type Silly a b = Maybe b

x :: Silly Int Bool
x = Just True
y :: Silly Char Bool
y = Just False

z = x == y                    -- returns False

What's with the a in Silly's decl? That's not a phantom type. It's ignored and thrown away. So x and y are the same type, and can be compare for equality.

I expected a rule: all tyvars in the type's head must appear on rhs. Or at least a warning there was something silly. I tried -Wall, -fwarn-unused-binds, -Wunused-type-patterns.

I was just checking up on a remark that type synonyms are at the type level like implicit bidirectional pattern synonyms. For those, all vars must appear on both sides.

Change History (4)

comment:1 Changed 12 months ago by goldfire

I'm not sure why you think that type should introduce a pattern synonym (which, indeed, must mention all its variables on the right-hand side). It just introduces a (not necessarily injective) synonym.

It's true that -XTypeSynonymInstances allows you to use a type synonym in an instance head. This might suggest the pattern-like behavior you seek. But this works via the expansion of the synonym, meaning that a program with both instance C (Silly Int Bool) and instance C (Silly Char Bool) will be rightly rejected.

Note that this behavior is not new.

comment:2 Changed 12 months ago by simonpj

You could argue that you should get a warning about "unused a" in Silly's definition. But we don't warn about

const x y = x

so you might consider it inconsistent to warn about the same thing at the type level.

comment:3 Changed 12 months ago by AntC

Note that this behavior is not new.

Indeed. Probably been there forever: there's nothing in the Report requiring all type vars to appear on rhs.

I can't see there would ever be any sense in it, though; unlike unused vars in other places, for which there's -fwarn-unused-binds.

we don't warn about ...

There's sense to not using all the arguments at term level. Never the less it's sufficiently unusual for GHC to recognise a special form. You can (I usually do) write

const x _ = x
const x _y = x

(Yes I could use _a for Silly, but I can still see no sense to it.)

In some contexs, using _ avoids getting a warning. (I'm thinking this for type could be a small tweak/enhancement for somebody starting GHC development: steal the logic from checking bidirectional patterns.)

comment:4 Changed 10 months ago by Phyx-

Operating System: WindowsUnknown/Multiple

Not Windows specific, reclassifying.

Note: See TracTickets for help on using tickets.