Re: Resolving Ambiguous Types

This is the "closed world assumption" that you want to make. Basically the problem is, what if you write 'bar foo' and expect to get "Zero", but someone else writes another instance of Barable and imports your code. What should happen? The open world assumption (the opposite) says that you never assume that you have all possible instances, and this is the assumption Haskell makes. On Thu, 20 Nov 2003, Jared Warren wrote:

Thanks to Tom Pledger, Brian Boutel, and Keith Wansbrough for helping me with my last type problem, but now I have another one: :)

-----

I understand why it is impossible to infer the intermediate type in `show . read`, but I was hoping someone could help me grasp why this (and only this) is problematic:

...

class Fooable a where foo :: a instance Fooable Char where foo = '0'

...

class Barable a where bar :: a -> String instance Barable Char where bar = const "Zero"

`bar foo` generates an ambiguous type error; but anyone can deterministically see that there is only one intermediate type that satisfies the classes. Why can't the compiler figure it out?

Are there any compiler directives, language extensions, or Template Haskell tricks I can use to make the compiler smarten up? (The requirements of my project rule out explicit type signatures.) If not, does anyone know if Chameleon's type system can avoid this problem?

Thanks for your help, ~ Jared Warren Computing Science, Queen's University

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

-- Hal Daume III | hdaume@isi.edu "Arrest this man, he talks in maths." | www.isi.edu/~hdaume