Alberto G. Corona schrieb:
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-Record.html#t%3AH2ProjectByLabels>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
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
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
