Hi Claus,

On Wed, Jul 2, 2008 at 12:11 PM, Claus Reinke <claus.reinke@talk21.com> wrote:

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