Opened 7 years ago

Closed 4 months ago

#2456 closed feature request (duplicate)

For higher kinds, instance declarations need quantification in the context

Reported by: ronwalf Owned by:
Priority: normal Milestone:
Component: Compiler Version: 6.9
Keywords: Cc:
Operating System: Unknown/Multiple Architecture: x86
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: #2893 Differential Revisions:

Description

$ rm -f DerivingError.o DerivingError.hi; ghc --make DerivingError.hs
[1 of 1] Compiling DerivingError    ( DerivingError.hs, DerivingError.o )

/var/folders/C0/C0SledGV2RaxbU+8ZLDnVU+++TI/-Tmp-//ghc27223_0/ghc27223_0.s:6080:0:
   FATAL:Symbol _XxG_srt already defined.

Attachments (2)

DerivingError.hs (2.4 KB) - added by ronwalf 7 years ago.
WouterTest2.hs (12.5 KB) - added by ronwalf 7 years ago.
Another file producing data derivation bug in GHC 6.9.20080730

Download all attachments as: .zip

Change History (12)

Changed 7 years ago by ronwalf

comment:1 Changed 7 years ago by thoughtpolice

  • Resolution set to fixed
  • Status changed from new to 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

Changed 7 years ago by ronwalf

Another file producing data derivation bug in GHC 6.9.20080730

comment:2 follow-up: Changed 7 years ago by ronwalf

  • Resolution fixed deleted
  • Status changed from closed to 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

comment:3 in reply to: ↑ 2 Changed 7 years ago by batterseapower

  • Version changed from 6.8.3 to 6.9

Replying to 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.

comment:4 Changed 7 years ago by simonpj

  • difficulty set to Unknown

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

comment:5 Changed 7 years ago by ronwalf

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)'

comment:6 Changed 7 years ago by simonpj

I've fixed the original bug of duplicate symbols

Wed Aug 20 13:07:51 GMT Daylight Time 2008  [email protected]
  * Fix Trac #2456: eliminate duplicate bindings when deriving

Simon

comment:7 follow-up: Changed 7 years ago by simonpj

  • Milestone set to _|_
  • Summary changed from Generics compilation problem: "FATAL:Symbol _XJv_srt already defined." to For higher kinds, instance declarations need quantification in the context
  • Type changed from bug to feature request

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

comment:8 Changed 2 years ago by morabbin

  • Operating System changed from MacOS X to Unknown/Multiple
  • Type of failure set to None/Unknown

Once one adds

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

7.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?

comment:9 Changed 2 years ago by goldfire

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, #4846, 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. :)

comment:10 in reply to: ↑ 7 Changed 4 months ago by thomie

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

Replying to 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 (Implement "Quantified contexts" proposal). Also some discussion in #5927 and #7019.

Note: See TracTickets for help on using tickets.