That all depends... In theory all the HList stuff happens at compile time, and what you are left with is normal function application... Of course compilers arn't that good yet, but as a reasonable idea, consider just that value level... Most of the extra work is the packing/unpacking of pairs "(,)". I have used HList for database schemas like the "Cow" example database (see attached) with no problems. The DB code includes code to generate the database from this "Schema" so is doesn't need to be entered twice, and it also typechecks the database against the schema in a one-way extensional manner on program start. The performance of the DB app is good, better than with scripting languages like perl/python, and type-safe. This code uses records made from HLists (see the paper for examples). Keean. Joel Reymont wrote:
Keean,
I sort of gave up on HList for the time being since I found easier ways to solve my problem.
Mainly, I could not estimate the impact it would have on run-time performance of my code and GHC not being able to compile the code was not a good indication. Simon PJ fixed that error since.
My idea was to, basically, create my own record sans labels. I wanted to specify picklers and default values for each field instead. I have over 250 records, though, and some have over 10 fields. There is a lot of sharing of fields between the records but I still think this is too much for GHC to handle.
Can you venture a guess on runtime performance of such code?
Thanks, Joel
On Nov 22, 2005, at 4:07 PM, Keean Schupke wrote:
hMarkAll Just hlist
class HList l => HMarkAll c l m | c l -> m where hMarkAll :: (forall a . a -> c a) -> l -> m instance HMarkAll c HNil HNil where hMarkAll _ _ = HNil instance HMarkAll c l m => HMarkAll c (HCons e l) (HCons (c e) m) where hMarkAll c (HCons e l) = HCons (c e) (hMarkAll c l)