Hi Claus,
On Wed, Jul 2, 2008 at 12:11 PM, Claus Reinke
ps. gmap itself is somewhat tricky to use, depending on type information from the context, and failing with runtime errors if that type information doesn't match.
*GMap> gmap not (True,True) :: (Bool,Char) (False,*** Exception: gunfold
But then, SYB generally operates at the borders of type safety (what one would expect to be a type error often just leads to unexpected behaviour - there are so few gaps between well-typed SYB programs that the type system, instead of noting that things go wrong, can only cause things to go elsewhere).
Are the other generic programming libraries better behaved in this area?
A small (and late) reaction to this point. The reason that this particular SYB gmap behaves badly is that deserialization is partial. You will have a runtime error (or exceptional return value) if you deserialize an input as a value of type X while it has been serialized as a value of type Y. Since this version of gmap is based on serialization followed by deserialization, you will obtain such errors when demanding incompatible types (as in your example). I think that Oleg's latest version enforces additional type safety (by means of the gmap2 wrapper) so this problem is no longer present. Other libraries (for example EMGM and RepLib) represent type constructors explicitly, so gmap can be implemented directly without the need of serialization/deserialization. There are no such runtime problems in those approaches. There are other examples of serialization-based generic functions: the implementation of generic transpose by Norell and Jansson [1], and also the generic conversion work by Atanassow and Jeuring[2]. Cheers, Alexey [1] http://citeseer.ist.psu.edu/649955.html [2] http://citeseer.ist.psu.edu/583900.html