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@xxxxxxxxxxx'
> > 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@xxxxxxxxxxx
> > | 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
> >