[Haskell-cafe] Type Directed Name Resolution

[Neil Brown]

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20101110/d128fc5e/attachment.html