[Hs-Generics] FW: [Haskell-cafe] SYB vs HList (again)

[Simon Peyton-Jones]

Dear generics mailing list

This message from Alex should be of interest, if you have not already seen it.

(Alex: this group is trying to create a single library --- or perhaps a couple with well-articulated tradeoffs --- for generic programming.  Maybe you should join it.)

Simon

-----Original Message-----
From: haskell-cafe-bounces at haskell.org [mailto:haskell-cafe-bounces at haskell.org] On Behalf Of S. Alexander Jacobson
Sent: 14 March 2007 23:40
To: haskell-cafe at haskell.org
Subject: [Haskell-cafe] SYB vs HList (again)

Right now I am looking at using either SYB (Scrap Your Boilerplate) or
HList Records to eliminate boilerplate for:

   * parsing URLEncoded strings into application data structures
   * generating XML/JSON from application data structures
   * handling adding new fields to serialized data structures
   * creating indexed collections of application data structures

I am looking for insights from people here on which approach they
think is better and why.  Here are my current thoughts on the issue

== Both HList and SYB require data structures redesign ==
HLists require you to define Labels and basically only use label
values that are themselves either scalar or HLists.  SYB basically
requires the same thing except that you use data/newtype to define
labels instead of HLists more cumbersome label constructions.

== Defaults: HList gives you compile time errors, SYB only runtime errors ==
SYB does not seem to provide a way of having the compiler tell you
that you are accessing a field that is unavailable in the type.  HList
will give you a type error if you do that.  I don't know exactly how
HList handles default values but I assume you can restrict use of
those values to explicit deserialization contexts.  Is that correct?

== HList allows more informality ==
With HList you can specify the type of a record ad hoc using
obj::(Record Foo .*. Bar .*.Baz).  SYB requires that you define data
structures in separate data declarations.

It would be really nice if there was some way to tell Haskell that
HLists have no more fields than the ones you happen to be getting and
setting in your code.  Effectively that would mean you get data
structure inference not just function type inference which would be
really cool!  That is probably not possible but it couldn't hurt to
ask (Oleg?).

== SYB doesn't require template haskell to make it usable ==
With SYB you create field labels using newtype (or data) declarations
e.g.

   data Salary = S {salary::Float}

With HList, label declarations are really verbose e.g.

   data SalaryLabel deriving(Typeable)
   type Salary = Field (Proxy SalaryLabel) Int
   salary = proxy :: Proxy FooLabel

You can make this more concise using TemplateHaskell but TH looks
alien and adds fear to the use of any code.

== Performance issues ==
SYB requires a linear traversal of all field elements using dynamic to
get or transform a value.  HList traverses an HCons list.  I don't how
bad this is as compared with traditional data structure access
using pattern matching or field labels.

My current bias is towards using HList because if we are going to
force a conversion to a new data structure convention I'd rather have
the typesystem on my side.  With SYB it is too easy to let haskell
field labels creep in to your data definitions and end up with subtle
errors to correct.

Any opinions on these issues would be very appreciated.

-Alex-






_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe at haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe