[Hs-Generics] Re: gMap in SYB1
mrchebas at gmail.com
Tue Jul 29 10:35:42 EDT 2008
On Wed, Jul 2, 2008 at 12:11 PM, Claus Reinke <claus.reinke at 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
> 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
There are other examples of serialization-based generic functions: the
implementation of generic transpose by Norell and Jansson , and also the
generic conversion work by Atanassow and Jeuring.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Generics