For higher kinds, instance declarations need quantification in the context

changed weight to 5

Attached file DerivingError.hs ($249).

closed

As discussed on haskell-cafe, it seems this bug doesn't come about as of GHC 6.9.20080720:

http://www.haskell.org/pipermail/haskell-cafe/2008-July/045404.html

Trac metadata

Trac field	Value
Resolution	Unresolved → ResolvedFixed

Attached file WouterTest2.hs ($258).

Another file producing data derivation bug in GHC 6.9.20080730

reopened

I can reproduce this bug with a slightly different file with $ ghc-6.9.20080730 --version The Glorious Glasgow Haskell Compilation System, version 6.9.20080730

Trac metadata

Trac field	Value
Resolution	ResolvedFixed → Unresolved

Replying to [ticket:2456#comment:25229 ronwalf]:

I can reproduce this bug with a slightly different file with $ ghc-6.9.20080730 --version The Glorious Glasgow Haskell Compilation System, version 6.9.20080730

I can also confirm WouterTest2 still exhibits this problem as of 6.9.20080813.

Trac metadata

Trac field	Value
Version	6.8.3 → 6.9

Excellent point. That is bad. I'll fix.

Meanwhile, in both cases you have

deriving instance Data (Expr Const)
deriving instance Data (Expr Var)

Question: do you really want this? You're generating more or less the same code twice. Why not write this?

deriving instance Data a => Data (Expr a)

Simon

In this case, (a) has the wrong kind (*->*), so trying that line gives:

#WouterTest2.hs:396:39:

Kind mis-match

Expected kind * -> *', but a' has kind *' In the type Expr a'

In the type (Data a) => Data (Expr a)' In the stand-alone deriving instance for (Data a) => Data (Expr a)'

mentioned in commit ec29e12f

I've fixed the original bug of duplicate symbols

Wed Aug 20 13:07:51 GMT Daylight Time 2008  simonpj@microsoft.com
  * Fix Trac #2456: eliminate duplicate bindings when deriving

Simon

changed title from Generics compilation problem: "FATAL:Symbol _XJv_srt already defined." to For higher kinds, instance declarations need quantification in the context

However, concerning your comment above, I had missed the fact that Expr has kind (*->*) -> *. What you really want to say is:

deriving instance (forall a. Data a => Data (f a)) => Data (Expr f)

Notice that the context of the instance has a nested forall. This has been a long-standing want; see Derivable type classes, Section 7.

So I'll retitle this ticket as a feature request for such a feature. But don't hold your breath.

Simon

Trac metadata

Trac field	Value
Type	Bug → FeatureRequest

added Tfeature request label and removed Tbug label

mentioned in issue #3391 (closed)

mentioned in issue #7019 (closed)

Once one adds

{-# LANGUAGE OverlappingInstances, TypeOperators,
    StandaloneDeriving, MultiParamTypeClasses,
    FlexibleInstances, DeriveDataTypeable #-}

6.1 yields:

1 of 1] Compiling DerivingError    ( DerivingError.hs, interpreted )

DerivingError.hs:81:1:
    Duplicate type signature:
      DerivingError.hs:81:1-33: $tExpr :: Data.Data.DataType
      DerivingError.hs:80:1-35: $tExpr :: Data.Data.DataType

DerivingError.hs:81:1:
    Duplicate type signature:
      DerivingError.hs:81:1-33: $cIn :: Data.Data.Constr
      DerivingError.hs:80:1-35: $cIn :: Data.Data.Constr

Is this the expected behavior?

Type system question: do we know that all of these extensions play nicely in a type-theoretic sense? Is the argument that, since they're all expressible in System F_C, we're okay?

Trac metadata

Trac field	Value
TypeOfFailure	- → OtherFailure
Operating system	MacOS X → Unknown/Multiple

In response to the type system question: Essentially, yes, if something is expressible in FC, then it must* be good. But, I know of two loopholes in FC: unsafe coercions (we all knew that), and the !GeneralizedNewtypeDeriving bug (see #1496 (closed), #4846 (closed), which seem, to me, to be duplicates).

FC is a complicated beast these days, and though we've proved it type-safe in theory, we can't be sure in practice. :)

mentioned in issue #8516

closed

Replying to [ticket:2456#comment:25361 simonpj]:

So I'll retitle this ticket as a feature request for such a feature.

Note: doing this makes it more difficult to test whether a ticket can be closed or not, because the description, attached testcases and part of the discussion are still for the original bug.

Nevertheless, this feature request is covered by #2893 (closed) (Implement "Quantified contexts" proposal). Also some discussion in #5927 (closed) and #7019 (closed).

Trac metadata

Trac field	Value
Resolution	Unresolved → ResolvedDuplicate
Related	→ #2893 (closed)

added Tbug label

added Pnormal label

For higher kinds, instance declarations need quantification in the context

Child items ...

Activity

For higher kinds, instance declarations need quantification in the context

Relates to

Activity