Type synonyms in class associated types behave strangely

[joelteon]

{-# LANGUAGE FlexibleContexts #-}
{-# LANGUAGE TypeFamilies #-}

type Syn a = Associated a

class Eq (Associated a) => Foo a where
    type Associated a :: *
    foo :: a -> Syn a -> Bool

instance Foo () where
    type Associated () = Int
    foo _ x = x == x

In 7.6.3 and 7.8.1-rc2, this file compiles. In 7.8.1 release, GHC produces this error:

    No instance for (Eq (Syn ())) arising from a use of ‘==’
    In the expression: x == x
    In an equation for ‘foo’: foo _ x = x == x
    In the instance declaration for ‘Foo ()’

even though there is an Eq instance for Associated (), and Syn is just a type synonym.

[goldfire]

I just got bit by this, too, on code that worked with 7.8.1 RC2. A perusal through a -ddump-tc-trace makes it look like something in the constraint solver, but I could be wrong.

An easy workaround (if you wrote the type synonym) is to use a one-equation type family instead.

[goldfire]

Could this be from 6ae678e31a5fdd3b0bd1f8613fe164012bb630f4?

[Lemming]

You can find another example in #8979.

[Lemming]

Replying to goldfire:

An easy workaround (if you wrote the type synonym) is to use a one-equation type family instead.

That helped. Thanks for the suggestion!

[joelteon]

The single-equation solution fixes this particular problem, but this is a simplification of library code that's throwing this error now, in which the type family cannot be closed.

[goldfire]

Sorry if I was unclear -- I meant to change the vanilla type synonym into a type family. My guess is that GHC won't care whether the new family is closed or open with one universal equation (if you need backward compatibility). You don't need to change the existing type family for my workaround.

[simonpj]

Ugh. This is my fault; an egregious blunder in a (cool) clean-up of the type flattener. It's easy to fix (patch coming) but the bug is in the released 7.8.1. Will fix in 7.8.2. It just shows, you never have enough regression tests!

It affects any type synonym whose RHS mentions a type family. (Data families are fine.) Such as Syn above, or H in #8979.

Richard's workaround is good; use a type family instead.

Sorry about this.

Simon

[Lemming]

Replying to simonpj:

Ugh. This is my fault; an egregious blunder in a (cool) clean-up of the type flattener. It's easy to fix (patch coming) but the bug is in the released 7.8.1. Will fix in 7.8.2. It just shows, you never have enough regression tests!

Will there be a "nightly snapshot build" for easy testing of the bugfix?

[snoyberg]

This bug has apparently broken a number of my packages, and I'm not certain if all of them can be fixed in a way that's backwards compatible with GHC 7.4 and 7.6 (both of which I still support). Would it be possible to release 7.8.2 with this fix alone, instead of waiting a number of months for the release as would normally be done?

[Simon Peyton Jones <simonpj@…>]

In b8132a9d2fdb93c5d30107b1d531dd73ac27b262/ghc:

Fix egregious blunder in the type flattener

In tidying up the flattener I introduced an error that no
regression test caught, giving rise to Trac #8978, #8979.
It shows up if you have a type synonym whose RHS mentions
type functions, such sas
     type family F a
     type T a = (F a, a)   -- This synonym isn't properly flattened

The fix is easy, but sadly the bug is in the released GHC 7.8.1

[simonpj]

Yes, I'm afraid that if I really have broken a number of significant packages since RC2, we probably should make a quick 7.8.2. Who else has come across this?

Simon

[snoyberg]

Thanks Simon. I'll be happy to do any testing of such a release.

[thoughtpolice]

Merged in 7.8, thanks Simon.

[Lemming]

Replying to simonpj:

Who else has come across this?

I encountered the bug when working on the tfp package. I could fix one problem within the package using the one-equation type family work-around. But the bug also affected the dependending llvm-tf package at several places. Thus I stopped working around and this means, that there might be more yet unseen places where it causes problems. Before a new release I would like very much to get a "nightly snapshot build" or "release candidate" for testing on 64-bit Linux. Otherwise I am afraid that the bugfix causes other subtle problems that will be part of 7.8.2.

[simonpj]

The fix is merged on the 7.8.2 branch, so you can build it and try. I don't know if anyone has a pre-built binary distribution for your platform though.

[Lemming]

Replying to simonpj:

The fix is merged on the 7.8.2 branch, so you can build it and try. I don't know if anyone has a pre-built binary distribution for your platform though.

I can confirm that the problems are gone with the ghc-7.8.1.20140410 built by Michael Snoyman.