Opened 7 years ago

Closed 15 months ago

#1050 closed bug (fixed)

Using an inferred type as a type signature fails

Reported by: simonpj Owned by:
Priority: low Milestone:
Component: Compiler (Type checker) Version: 6.6
Keywords: Cc: a.dcolour@…
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Difficulty: Unknown
Test Case: Blocked By:
Blocking: Related Tickets:

Description

See the thread starting here
http://www.haskell.org/pipermail/glasgow-haskell-users/2006-December/011714.html.
Here's a short example:

class C a b where
   op :: a -> a

-- f :: C a b => a -> a
f x = op x

It doesn't get much simpler than that! With the type sig, GHC can't see that the (C a b) provided can satisfy the (C a b1) which arises from the call to op. However, without the constraint, GHC simply abstracts over the constrains arising in the RHS, namely (C a b1), and hence infers the type

        f :: C a b1 => a -> a

It is extremely undesirable that the inferred type does not work as a type signature, but I don't see how to fix it easily. It doesn't affect many programs, I think; hence low priority

Change History (6)

comment:2 Changed 7 years ago by guest

  • Cc a.dcolour@… added

I'm interested in the resolution of this. Added to CC.

comment:3 Changed 6 years ago by simonmar

  • Architecture changed from Unknown to Unknown/Multiple

comment:4 Changed 6 years ago by simonmar

  • Operating System changed from Unknown to Unknown/Multiple

comment:5 Changed 15 months ago by morabbin

  • Type of failure set to None/Unknown

Defect still present in GHC 7.6.1, but I'm seeing some oddness in the number of errors presented with multiples:

{-# LANGUAGE MultiParamTypeClasses #-}

class C a b where
   op :: a -> a

f1 :: C a b => a -> a
f1 x = op x

f2 :: C a b => a -> a
f2 x = op x

If we give both type signatures, both fail. If we give neither, both fail (albeit with a different error). Leave out only one type signature, and only that function fails to type. Or, more likely, the other failure is not reported.

I have files to attach if deemed worthwhile (no patch, just files that show the four behaviors).

comment:6 Changed 15 months ago by simonpj

  • Resolution set to fixed
  • Status changed from new to closed

GHC always checks each type signature for ambiguity; if that faile, it just stops, since ambiguous signatures can lead to futher errors. If there are no sigatures, it goes ahead and tries to typecheck both defns, finding an ambiguous inferred type for each.

It's not perfect, but I think it's good enough.

Simon

Note: See TracTickets for help on using tickets.