[Haskell-cafe] Type Directed Name Resolution

[Yves Parès]

> Then you'd need a fundep on your class, which begins to get ugly

> 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.

I agree with you in those cases.
But why would TDNR not work in the second case?


2010/11/10 Neil Brown <nccb2 at kent.ac.uk>

>  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 at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20101110/c093bba8/attachment.html