[Haskell-cafe] Is it possible to represent such polymorphism?
sdiyazg at sjtu.edu.cn
sdiyazg at sjtu.edu.cn
Mon Oct 3 10:26:03 CEST 2011
Quoting Andrew Coppin <andrewcoppin at btinternet.com>:
> On 02/10/2011 07:15 PM, Du Xi wrote:
> In C++, the code is inferred from the types. (I.e., if a function is
> overloaded, the correct implementation is selected depending on the
> types of the arguments.)
> In Haskell, the types are inferred from the code. (Which is why type
> signatures are optional.)
> Really, it's just approaching the same problem from a different direction.
> Also, as others have said, you're probably just approaching the problem
> from the wrong angle. You don't design an object-oriented program the
> same way you'd design a procedural program; if you do, you end up with a
> horrible design. Similarly, you don't design a functional program the
> same way you would design an object-oriented one. It takes time (and
> experience) to figure out how to approach FP - or any other radically
> different paradigm, I suppose...
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
Quoting Brandon Allbery <allbery.b at gmail.com>:
> On Sun, Oct 2, 2011 at 15:17, <sdiyazg at sjtu.edu.cn> wrote:
> Not for your meaning of "clean".
> C++ is an object-oriented programming language; given a method call, it
> tries really hard to shoehorn the arguments to the call into some declared
> method somewhere along the inheritance chain. Haskell is a functional
> programming language; it is strongly typed, and typeclasses are a mechanism
> to allow that typing to be weakened in a strictly controlled fashion. In
> some sense, it's not *supposed* to be convenient, because the whole point is
> you're not supposed to throw arbitrarily-typed expressions at arbitrary
> functions. Instead, a properly designed program is characterized by its
> types; if the types are well designed for the problem being solved, they
> very nearly write the program by themselves.
> This doesn't mean that use of typeclasses / ad-hoc polymorphism is
> automatically a sign of a poor design, but it *does* mean you should think
> about what you're trying to do whenever you find yourself considering them.
> Nor does it mean that C++ is in some sense "wrong"; it means the languages
> are fundamentally different, and the appropriate design of a program is
> therefore also usually different between the two.
> brandon s allbery allbery.b at gmail.com
> wandering unix systems administrator (available) (412) 475-9364 vm/sms
This has nothing to do with OOP or being imperative.It's just about types.
More information about the Haskell-Cafe