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
