Ticket #322 (new bug: None)

Opened 8 years ago

Last modified 3 years ago

fromInteger-related pattern match overlap warnings

Reported by: ashley-y Owned by: simonpj
Priority: normal Milestone: _|_
Component: Compiler Version: 6.4
Keywords: warnings Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Difficulty: Unknown
Test Case: ds060 Blocked By:
Blocking: Related Tickets:

Description (last modified by igloo) (diff)

The compiler incorrectly gives "Warning: Pattern match(es) are 
overlapped" for this file:

{-# OPTIONS -Werror #-}

module Buggy where

	instance (Num a) => Num (Maybe a) where
		(Just a) + (Just b) = Just (a + b)
		_ + _ = Nothing
		(Just a) - (Just b) = Just (a - b)
		_ - _ = Nothing
		(Just a) * (Just b) = Just (a * b)
		_ * _ = Nothing
		negate (Just a) = Just (negate a)
		negate _ = Nothing
		abs (Just a) = Just (abs a)
		abs _ = Nothing
		signum (Just a) = Just (signum a)
		signum _ = Nothing
		fromInteger = Just . fromInteger

	f :: Maybe Int -> Int
	f 1 = 1
	f Nothing = 2
	f _ = 3

Change History

Changed 8 years ago by nobody

Logged In: NO 

If we define the first line as:

f (Just 1) = 1

there is no problem. 

Changed 7 years ago by igloo

  • description modified (diff)
  • testcase set to ds060
  • difficulty set to Unknown
  • architecture set to Unknown
  • milestone set to _|_
  • keywords warnings added
  • os set to Unknown

Changed 6 years ago by simonmar

See #595

Changed 5 years ago by simonmar

  • architecture changed from Unknown to Unknown/Multiple

Changed 5 years ago by simonmar

  • os changed from Unknown to Unknown/Multiple

Changed 3 years ago by marcotmarcot

  • failure set to None/Unknown

I'm thinking about this bug, and the only way I can see to avoid it, is by knowing in compile-time, that is, when the compiler checks if the Patterns are complete, how the value (1 :: Integer) will be converted to (1 :: Maybe Int). This is defined in "fromInteger = Just . fromInteger", which is a user code. So the user code will have to be evaluated in compile time. Is this already done in any case? I don't think so, as this would create the possibility of the compilation not terminating.

Changed 3 years ago by igloo

You can't make the warning perfect, but in cases where we are not sure we have 3 choices:

  • warn
  • don't warn
  • give a different warning, saying that we aren't sure (this warning could be en/disabled separately)
Note: See TracTickets for help on using tickets.