Coherence may also arise because of an ambiguous type.
Here's the classic example.
class Read a where read :: String -> a
class Show a where show :: a -> String
f s = show (read s)
f has type String->String, therefore we can pick
some arbitrary Read/Show classes.
If you want to know more about coherence/ambiguity in the Haskell context.
Check out
@TechReport{jones:coherence,
author = "M. P. Jones",
title = "Coherence for qualified types",
institution = "Yale University, Department of Computer Science",
year = 1993,
month = "September",
type = "Research Report",
number = "YALEU/DCS/RR-989"
}
and
@Article{overloading-journal,
author = {P.~J.~Stuckey and M.~Sulzmann },
title = {A Theory of Overloading},
journal = {ACM Transactions on Programming Languages and Systems
(TOPLAS)},
publisher = "ACM Press",
year = "2005",
pages = "1-54",
volume = 27,
number = 6,
preprint =
{http://www.comp.nus.edu.sg/~sulzmann/chr/download/theory-journal.ps.gz}}
As far as I know, the term "coherence" was coined by
@article{breazu-tannen-etal:inhertiance-coercion,
author = "V. Breazu{-}Tannen and T. Coquand and C. Gunter
and A. Scedrov",
title = "Inheritance as Implicit Coercion",
journal = "Information and Computation",
volume = 93,
number = 1,
month = jul,
year = 1991,
pages = "172--221"
}
Martin
william kim writes:
> Thank you Martin.
>
> >Coherence (roughly) means that the program's semantics is independent
> >of the program's typing.
> >
> >In case of your example below, I could type the program
> >either use the first or the second instance (assuming
> >g has type Int->Int). That's clearly bound.
>
> If g has type Int->Int, it is not hard to say the first instance should
> apply.
> But how about g having a polymorphic type? In this case it seems to me
> choosing the second instance is an acceptable choice as that is the only
> applicable one at the moment. What is the definition of a "coherent"
> behaviour here? Or is there one?
>
>
> >Non-overlapping instances are necessary but not sufficient to
> >obtain coherence. We also need that types/programs are unambiguous.
>
> Do you therefore imply that coherence is not defined without the
> non-overlapping assumption?
>
> --william
>
> _________________________________________________________________
> Get MSN Hotmail alerts on your mobile.
> http://mobile.msn.com/ac.aspx?cid=uuhp_hotmail
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
