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.