1

The first two Scrap Your Boilerplate papers describe a way of writing generic functions that work for general types, but have special cases for specific types. For instance, fromJSON from the aeson package, defines a generic function for converting from JSON, but provides special cases for types like list or Int:

parseJSON :: (Data a) => Value -> Parser a
parseJSON j = parseJSON_generic j
             `ext1R` list
             `ext1R` vector
             `ext2R'` mapAny
             `ext2R'` hashMapAny
             -- Use the standard encoding for all base types.
             `extR` (value :: F Integer)
             `extR` (value :: F Int)
              ...

However, as the third SYB paper notes, "all the type-specific cases [need] to be supplied at once, when the recursive knot of generic function definition is tied". The paper then proposes a way to lift this restriction through the type-class mechanism.

The first two SYB papers are (with some modifications) part of the syb package, but the third is not. Is there some other way of lifting the restriction that all type-specific cases need to be specified at once with the implementation of SYB on Hackage?

scvalex
  • 14,931
  • 2
  • 34
  • 43

1 Answers1

1

There's, as far as I know, no way around the restriction within that system. The fact that there isn't is what necessitates introducing a new approach in the third paper. There's working syb-with-class code, implementing the third paper on hackage: http://hackage.haskell.org/package/syb-with-class

However, my recommendation these days would be to try to experiment with the new Generics mechanism, which is faster, more principled, and more flexible (albeit occasionally a real pain :-)).

sclv
  • 38,665
  • 7
  • 99
  • 204
  • 1
    Mhm. My problem with the new Generics framework is that its a pain to reconstruct data if your encoding labels fields. Anyway, thank you. – scvalex Feb 13 '13 at 19:48