I'm totally out of my depth (coming from Java I'm probably one of these people with a weird understanding of polymorphism (-:) probably here, but I agree with Yves. It seems to me that if we accept that, in Ozgur's example, name can take either a Foo or a Bar, then his getName function could also be called name and also accept Either Foo Bar. So all of this smells strongly of type classes. So I think Yves' idea of generating a StringName type class or something, that all records with a field called name of type String are automatically instances of, and adding new instances for other types manually as need be, is good. Crazy, maybe, but good. If it quacks like a duck and has signed the duck good behavior charter aka type class definition, it's a duck.

JP


On Wed, Nov 10, 2010 at 1:36 PM, Yves Parès <limestrael@gmail.com> wrote:
I think this idea is a stairway to duck typing.
I exagerate, of course, but here is my point:

It shouldn't be difficult to make a class:
class HasName a where
  name :: a -> String

The problem is when declaring Foo and Bar instances of HasName, since you have to copy code :
data Foo = Foo String
data Bar = Bar String
instance HasName Foo where
  name (Foo n) = n
instance HasName Bar where
  name (Bar n) = n

I'm sure one can automatize this using TemplateHaskell, but it is not really simple.

What I mean is that GHC should give a means to automatize this kind of situation, for instance:

data Foo = Foo { name :: String }
  (deriving HasName)

Or even:
data Foo = Foo { HasName.name }

Just an idea.

2010/11/10 Ozgur Akgun <ozgurakgun@gmail.com>
I still don't know whether I like this idea or not, but here is the simplest definition I can think of about what it promises.

Using TDNR, it will be possible to write the following code:

data Foo = Foo { name :: String }
data Bar = Bar { name :: String }

getName :: Either Foo Bar -> String
getName (Left  f) = name f
getName (Right b) = name b

However, currently you cannot: "Multiple declarations of 'name'"

There are basically two things you can do to solve this "problem".
 - Use different names for your functions, a la "fooName, barName". This clutters up your code, and sometimes you may not have access to that part of the code.
 - Define these 2 data types in different modules and import qualified, a la "Foo.name, Bar.name". One might still think this clutters up your code.

In any case, as a programmer you need to resolve which function to use depending on types while defining 'getName'. However compiler has enough information to automate this decision for you. This is not a way to do polymorphism, this is merely a way to allow programmers define more than one function with the same name, but different types.

This kinda sounds like what java people think polymorphism is :P

--
Ozgur Akgun

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



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




--
JP Moresmau
http://jpmoresmau.blogspot.com/