Adding a dummy argument is what I've been doing so far, but it feels hackish. Typeclasses add an implicit parameter containing the dictionary of methods, and it seemed reasonable for me to have a more direct influence over its value. If I must add another explicit parameter to specify which dictionary to use, I might as well just pass the dictionary around myself.
On Wed, Aug 5, 2009 at 12:56 PM, Bulat Ziganshin<[email protected]> wrote: > Hello Daniel, > > Wednesday, August 5, 2009, 8:00:06 PM, you wrote: > >> class Moo a b where >> moo :: a -> a > >> instances. Another solution would be to artificially force moo to take >> a "dummy" b so that the compiler can figure out which instance you >> meant. That's what I've been doing in the mean time, but wouldn't it >> be simpler and less hackish to add a some form of "instance >> annotation", like a type annotation, that would make it possible to >> specify what instance you wanted when it's ambiguous? > > imho, no. you propose to add one more feature when existing features > can serve: > > class Moo a b where > moo :: a -> b -> a > > f x = moo x (undefined::Int) > > btw, may be associated types or associated type synonyms (these are > novel features superseding FDs) is what you need? > > > > -- > Best regards, > Bulat mailto:[email protected] > > _______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
