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.