Janis Voigtlaender writes: (snip)

Yes, as long as enough type information is provided for the typechecker to decide what is the correct instance to use. (snip)

I've always been a little surprised when this doesn't happen more widely for things other than instances. For instance, when IntMap.size, Map.size and Set.size (or whatever) are all in scope as "size", it should be fairly obvious what (size x) is about once we've inferred, for other reasons, that x is an IntMap. Similarly with records, if we had field names that cause functions for extracting the value of those fields, where we used the same field name in two different record types, I figure that there's usually no ambiguity because we can usually infer the type of the object to which the 'extractor' is being applied. Am I just not seeing the big picture, or would people not find this use of type information to resolve such ambiguities as nice as I would, or is it harder to do that than I'm expecting? -- Mark

Hello Mark, Friday, August 4, 2006, 3:03:54 PM, you wrote:

I've always been a little surprised when this doesn't happen more widely for things other than instances. For instance, when IntMap.size, Map.size and Set.size (or whatever) are all in scope as "size", it should be fairly obvious what (size x) is about once we've inferred, for other reasons, that x is an IntMap. Similarly with records, if we had

this is called ad-hoc polymorphism which is not supported by Haskell. instead Haskell supports parametric polymorphism via type classes. i'm not a language lawyer ;) but thinks that difference between C++ which supports former and Haskell that supports later is the following: C++ can infer only result type based on arguments type while Haskell can infer in _both_ directions. i can imagine C++ type inferring algorithm, with a little imagination i even can think about Haskell's algorithm :) but two-way type inferring together with ad-hoc polymorphism make me a little nervous :) how about, for example, two ad-hoc-polymorphic functions: f (g x)? or dozens of such calls enclosed? how error messages should be generated: "it may be Int::f with Char::g or Char::f with Bool::g or ... or ... or ..." ? one more cause is that Haskell was defined by scientists, not practical programmers, and scientists prefer to use more systematic ways to do the same things nevertheless, there is no principal differences. in many cases you can define type classes, include your ad-hoc polymorphic functions into these classes and sleep easy. in particular, as Brian already said, there is a proposal to use automatically generated type classes for record fields -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

Martin Percossi wrote:

Bulat Ziganshin wrote:

...

this is called ad-hoc polymorphism which is not supported by Haskell. instead Haskell supports parametric polymorphism via type classes.

I think you are wrong here Bulat. In fact, I think a) Haskell supports parametric polymorphism, e.g. id :: t -> t id x = x b) Haskell supports ad-hoc polymorphism via type classes

Sometimes a distinction is made between ad-hoc polymorphism of the kind you'd get in C++ with method overloading, and "restricted parametric polymorphism" as in "Monad m =>" ie: 1) id :: t -> t -- Unrestricted parametric polymorphism 2) foo :: Monad m => m a -- Restricted parametric polymorphism for (m) and unrestricted for (a) 3) bar :: Int -> Int -> String bar :: Char -> Bool The only way to describe this is ad-hoc polymorphism, and the fact that any function is of the form A -> B means regardless of the arity of the overloaded functions it can also be supported by typeclasses (*) eg: class Bar a b where bar :: a -> b instance Bar Int (Int -> String) where ... instance Bar Char Bool where ... And a function or value in scope can be making use of unrestricted, restricted, and ad-hoc polymorphism at the same time eg: zap :: Monad m => Char -> m a zap :: Int -> String -> a String class Zap a b where zap :: a -> b instance Monad m => Zap Char (m a) where ... instance Zap Int (String -> a String) where ... (*) But there's one exception: you can't use typeclasses to resolve overloadings between values and functions because non-function values don't have a type of the form A -> B: cool :: Int cool :: Char -> String class Cool -- Ooops! fundamental problem encountered ;-) Regards, Brian. -- Logic empowers us and Love gives us purpose. Yet still phantoms restless for eras long past, congealed in the present in unthought forms, strive mightily unseen to destroy us. http://www.metamilk.com

Bulat Ziganshin wrote:

Hello Brian,

Friday, August 4, 2006, 8:50:25 PM, you wrote:

...

class Bar a b where bar :: a -> b

...

(*) But there's one exception: you can't use typeclasses to resolve overloadings between values and functions because non-function values don't have a type of the form A -> B:

...

cool :: Int cool :: Char -> String

...

class Cool -- Ooops! fundamental problem encountered ;-)

class Cool a where cool :: a

instance Cool Int instance Cool (Char -> String)

?

Yes thanks - someone else pointed this out to me off-list as well. I think that mental block must have been caused by watching too many episodes of Star Trek yesterday! Ok I give up, there's just no excuse... ;-) Brian. -- Logic empowers us and Love gives us purpose. Yet still phantoms restless for eras long past, congealed in the present in unthought forms, strive mightily unseen to destroy us. http://www.metamilk.com