Hi
What is the speed of hProjectByLabel/s in Data.HList.Record? . The documentation in hackage http://hackage.haskell.org/packages/archive/HList/latest/doc/html/Data-HList...does not mention it. Perhaps this is because Hlist is designed for supposedly short records and this does not matter too much. looking at the code I guess that everything in HList is O(n) because it uses type-level list structure, but I think that nothing prevents from using a type level balanced tree, Data.Map style, instead.
This would permit to implement large heterogeneous Maps with fast access and strongly typed. AFAIK, the alternative is to use a fast data container with data elements encapsulated within Data.Dynamic, that is weakly typed, produces type errors at runtime, which is unsatisfactory and dangerous.
Any comments? Hi Alberto, I think this idea isn't unreasonable, and I am curious whether it would
Alberto G. Corona schrieb: pay off in practice. I think you are right with your O(n) guess for the standard HList implementation. Rebalancing the trees at the type level and mirroring the rebalancing efficiently at the term level could be a little bit tricky though. Btw, I found type-level functions to be more comfortable than type classes when playing with heterogenous lists. cheers, benedikt
------------------------------------------------------------------------
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe