RE: Deriving Typeable instances
On 09 August 2005 17:16, Simon Peyton-Jones wrote: I'm not against this, although you can work around the problem by adding a library that defines the missing type classes (Typeable8, Typeable9 etc), and making your compiler generate the instance itself. There is nothing magic about 'deriving'; it's just convenient. If the arity is 7, couldn't we just generate a Typeable instance, rather than the TypeableN instance? It would mean you wouldn't get the benefits of TypeableN, but at least you'd have Typeable. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Deriving Typeable instances
Yes, you could I suppose. But then there'd be a different peculiar change in behaviour at arity 7. I'm not sure that'd be an advantage. Simon | -Original Message- | From: Simon Marlow | Sent: 10 August 2005 10:58 | To: Simon Peyton-Jones; Frank Huch; glasgow-haskell-bugs@haskell.org | Subject: RE: Deriving Typeable instances | | On 09 August 2005 17:16, Simon Peyton-Jones wrote: | | I'm not against this, although you can work around the problem by | adding a library that defines the missing type classes (Typeable8, | Typeable9 etc), and making your compiler generate the instance | itself. There is nothing magic about 'deriving'; it's just | convenient. | | If the arity is 7, couldn't we just generate a Typeable instance, rather than the TypeableN instance? | It would mean you wouldn't get the benefits of TypeableN, but at least you'd have Typeable. | | Cheers, | Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Deriving Typeable instances
(I agree with the two Simons; just want to throw in a few more considerations.) Just curious ... What's the use case, Frank? (It is probably related to debugging or assertion checking; do you have code details that you want to share?) Do you *really* want to do type-case on those multi-arity parametric types in the sense that you would care about keeping n, n-1, n-2, ..., 1 type positions polymorphic when casting? If you don't, then monomorphic instances of Typeable would be fine. And they are much easier to generate, indeed. (Typeable.h in the Data/include dir (ghc cvs) could be of help to solve the problem before GHC catches up.) It's perhaps useful to recall that the arity-sensitive Typeable business was introduced for the purpose of polymorphic type-case in the context of generic programming with SYB1 and 2 (a bit less at level 3) BTW, for the ICFP 2005 style of SYB (level 3), Typeable instances may be entirely avoidable, depending on programming style and scenario. All the best, Ralf (Once again, sounds like kind-polymorphism would simplify the implementation and the use of Haskell.) -Original Message- From: Simon Peyton-Jones Sent: Wednesday, August 10, 2005 3:32 AM To: Simon Marlow; 'Frank Huch'; 'glasgow-haskell-bugs@haskell.org' Cc: Ralf Lammel Subject: RE: Deriving Typeable instances Yes, you could I suppose. But then there'd be a different peculiar change in behaviour at arity 7. I'm not sure that'd be an advantage. Simon | -Original Message- | From: Simon Marlow | Sent: 10 August 2005 10:58 | To: Simon Peyton-Jones; Frank Huch; glasgow-haskell-bugs@haskell.org | Subject: RE: Deriving Typeable instances | | On 09 August 2005 17:16, Simon Peyton-Jones wrote: | | I'm not against this, although you can work around the problem by | adding a library that defines the missing type classes (Typeable8, | Typeable9 etc), and making your compiler generate the instance | itself. There is nothing magic about 'deriving'; it's just | convenient. | | If the arity is 7, couldn't we just generate a Typeable instance, rather than the TypeableN instance? | It would mean you wouldn't get the benefits of TypeableN, but at least you'd have Typeable. | | Cheers, | Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Deriving Typeable instances
Hi and thanks for your discussion. Our programs have (at the moment) nothing to do with debugging or assertions. We are implementing a Curry-to-Haskell-Compiler. Curry is a functional-logic language, extending Haskell with needed narrowing (efficient (lazy) search for free, logic variables). In the generated Haskell program we need a mapping for bindings of logic variables. The only way we were able to built this mapping is a map from variable identifiers to dynamically typed values. Since Curry provides tuples up to arity 15, we have to provide an instance of the class Typeable to store bindings in the mapping of logic variables. Hence, for the predefined data structures it would be nice to have instances up to 15. However, in Curry programmers are also allowed to define own type constructors with an arity larger than 15 (or seven), as in Haskell. To translate such Curry programs it would be nice to have derivable instances for Typeable for type constructors of arbitrary arity, like ghc-6.2 provided it. For us it is nicer to derive Typeable instance for all data types rather than defining these instances by hand. For the moment, it would be nice if you could provide a restriction to 15 type variables. Otherwise we will define these instances for tuples up to 15 by hand and think about generating instances for arbitrary types later. Thanks and regards, Frank Ralf Lammel schrieb: (I agree with the two Simons; just want to throw in a few more considerations.) Just curious ... What's the use case, Frank? (It is probably related to debugging or assertion checking; do you have code details that you want to share?) Do you *really* want to do type-case on those multi-arity parametric types in the sense that you would care about keeping n, n-1, n-2, ..., 1 type positions polymorphic when casting? If you don't, then monomorphic instances of Typeable would be fine. And they are much easier to generate, indeed. (Typeable.h in the Data/include dir (ghc cvs) could be of help to solve the problem before GHC catches up.) It's perhaps useful to recall that the arity-sensitive Typeable business was introduced for the purpose of polymorphic type-case in the context of generic programming with SYB1 and 2 (a bit less at level 3) BTW, for the ICFP 2005 style of SYB (level 3), Typeable instances may be entirely avoidable, depending on programming style and scenario. All the best, Ralf (Once again, sounds like kind-polymorphism would simplify the implementation and the use of Haskell.) -Original Message- From: Simon Peyton-Jones Sent: Wednesday, August 10, 2005 3:32 AM To: Simon Marlow; 'Frank Huch'; 'glasgow-haskell-bugs@haskell.org' Cc: Ralf Lammel Subject: RE: Deriving Typeable instances Yes, you could I suppose. But then there'd be a different peculiar change in behaviour at arity 7. I'm not sure that'd be an advantage. Simon | -Original Message- | From: Simon Marlow | Sent: 10 August 2005 10:58 | To: Simon Peyton-Jones; Frank Huch; glasgow-haskell-bugs@haskell.org | Subject: RE: Deriving Typeable instances | | On 09 August 2005 17:16, Simon Peyton-Jones wrote: | | I'm not against this, although you can work around the problem by | adding a library that defines the missing type classes (Typeable8, | Typeable9 etc), and making your compiler generate the instance | itself. There is nothing magic about 'deriving'; it's just | convenient. | | If the arity is 7, couldn't we just generate a Typeable instance, rather than the TypeableN instance? | It would mean you wouldn't get the benefits of TypeableN, but at least you'd have Typeable. | | Cheers, | Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Deriving Typeable instances
| data T a b c d e f g h = T a b c d e f g h | deriving Typeable | | fails in ghc-6.4 with the message: | Can't make a derived instance of `Typeable (T a b c d e f g h)' | (`T' has too many arguments) | When deriving instances for type `T' | | In ghc 6.2.2, it was no problem to derive Typeable instances for type | constructors of higher (arbitrary?) arities. Yes, this was a change, I'm afraid, and not a documented one. I've updated the documentation (see below for the diff, and the explanation). | If it is not possible to provide deriving Typeable for arbitrary arity | of type constructors anymore, would it be possible to extend deriving to | at least type constructors of arity 20? We are using Haskell as a target | language of a compiler and here type constructors with many arguments occur. I'm not against this, although you can work around the problem by adding a library that defines the missing type classes (Typeable8, Typeable9 etc), and making your compiler generate the instance itself. There is nothing magic about 'deriving'; it's just convenient. The Read and Show instances for tuples go up to arity 15, and since we have some arbitrary numbers in GHC we might as well have as few as possible. So would arity 15 do? If you really want 20 maybe we should do the same for Read/Show on tuples. If someone likes to volunteer to do the actual work on the library Data.Typeable, I think we could adopt it. It's simple but boring to follow the recipe for Typable1..Typeable7. I'm a bit tied up right now. Simon + paraAn instance of literalTypeable/literal can only be derived if the + data type has seven or fewer type parameters, all of kind literal*/literal. + The reason for this is that the literalTypeable/literal class is derived using the scheme + described in + ulink url=http://research.microsoft.com/%7Esimonpj/papers/hmap/gmap2.ps; + Scrap More Boilerplate: Reflection, Zips, and Generalised Casts + /ulink. + (Section 7.4 of the paper describes the multiple literalTypeable/literal classes that + are used, and only literalTypeable1/literal up to + literalTypeable7/literal are provided in the library.) + In other cases, there is nothing to stop the programmer writing a literalTypableX/literal + class, whose kind suits that of the data type constructor, and + then writing the data type instance by hand. + /para | -Original Message- | From: [EMAIL PROTECTED] [mailto:glasgow-haskell-bugs- | [EMAIL PROTECTED] On Behalf Of Frank Huch | Sent: 04 August 2005 18:00 | To: glasgow-haskell-bugs@haskell.org | Subject: Deriving Typeable instances | | Hi, | | we have a problem with deriving Typeable instances in ghc-6.4. The | following code | | data T a b c d e f g h = T a b c d e f g h | deriving Typeable | | fails in ghc-6.4 with the message: | Can't make a derived instance of `Typeable (T a b c d e f g h)' | (`T' has too many arguments) | When deriving instances for type `T' | | In ghc 6.2.2, it was no problem to derive Typeable instances for type | constructors of higher (arbitrary?) arities. | | If it is not possible to provide deriving Typeable for arbitrary arity | of type constructors anymore, would it be possible to extend deriving to | at least type constructors of arity 20? We are using Haskell as a target | language of a compiler and here type constructors with many arguments occur. | | Regards, | Frank | ___ | Glasgow-haskell-bugs mailing list | Glasgow-haskell-bugs@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
