Yes, that _is_ obvious but then puts the burden on the programmer to
define the getters. It also misses the setters issue entirely.
Each field can definitely be made into a class and records can be
composed dynamically, HList-style. I think HList is _the_ facility
for doing this.
How do you create a "record" that has a field dictionary for updates
and retrievals and stores the order of the fields for serialization?
I think HList does provide for the order of records since it keeps
them in a list of sorts.
Can serialization of these HList-style records serialization be
efficient in this case? Would updating fields be efficient?
I tried composing my records using HList and that made GHC run out of
memory and bomb out. Simon Peyton-Jones fixed the problem promptly
but since I was not familiar with the profiler at the time I never
got to measuring the pickling efficiency. I figured if it's that
tough on the compiler then maybe I should pick an easier path.
Thanks, Joel
On Jan 4, 2006, at 8:41 AM, Ketil Malde wrote:
Isn't the obvious solution to declare a class here? I.e.
class HasProfits h where profits :: h -> Word64
data Pot = Pot { pProfits :: !Word64, pAmounts = ![Word64] }
instance HasProfits Pot where profits = pProfits
--
http://wagerlabs.com/
_______________________________________________
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe
