On 10/11/10 12:36, Yves Parès wrote:
I think this idea is a stairway to duck typing.
I exagerate, of course, but here is my point:
It shouldn't be difficult to make a class:
class HasName a where
name :: a -> String
For accessing parts of data structures that have the same type, I agree
that a type-class is best. However, this doesn't cover the situation
where the type of the field is different across types, e.g.
data SomeXmlDerivedThingy = C { name :: Maybe String }
data Person = P { name :: String }
Then you'd need a fundep on your class, which begins to get ugly:
class HasName a b | a -> b where
name :: a -> b
It also doesn't work when the two instances of name come from totally
separate libraries that don't know anything about each other (e.g. one's
an xml library, the other is a database library). Then you have to add
such a class in your own code to resolve the conflict. But having read
the wiki page, it seems TDNR doesn't work in where I would particularly
want it (e.g. record updating), so I'm not sure it's that worthwhile.
As an aside, the rule on the wiki page says "Unlike normal unqualified
variable occurrences, it is legal for there to be many f's in scope. To
resolve which one is intended, find the type of a, and the type of all
of the in-scope f's. If there is exactly one f whose type matches that
of a, that resolve the occurrence of f. Otherwise the program is in error. "
I wonder if special syntax is actually needed for this. How much of the
language would be broken by adopting the general rule: "If the only
definitions of f are at the top-level or imported, find the type of 'a'
and the type of all the in-scope 'f' s. If there is exactly one match
then use it, otherwise it's an error."?
Thanks,
Neil.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
