Resolving Ambiguous Types

Hal Daume III hdaume at ISI.EDU
Thu Nov 20 12:01:41 EST 2003


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 <warren at cs.queensu.ca>
> Computing Science, Queen's University
> 
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
> 

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



More information about the Haskell-Cafe mailing list