> Now if all of this is the case, then we must ask whether we shouldn't > just allow fields in [type] class definitions. I don't see any > particular *use* for fields in a type class, but at the same time I > see no need to exclude them arbitrarily.
I've never programmed with type classes (or concepts), so I have little intuition about how they "ought" to work. But this made me think of Jeremy Siek's 2005 paper, "Essential Language Support for Generic Programming". One of the examples there is of a Monoid concept, which most naturally maps to a type class with a field for the identity element value. Having a well-founded way of expressing algebraic structures and properties could be a worthwhile use case for fields in type classes. http://ecee.colorado.edu/~siek/pubs/pubs/2005/siek05_fg_pldi.pdf _______________________________________________ bitc-dev mailing list bitc-dev@coyotos.org http://www.coyotos.org/mailman/listinfo/bitc-dev
