4 ms·

Why doesn't Haskell support objects? Seems like that would be quite useful. They don't need to be mutable or anything. They could be like records, that scale.

d0m 16y ago
Because there is already support for "records" as you say. Add the static type "interface" and you get a kind-of OO.
silentbicycle 16y ago
Because it has typeclasses, which solve the same problems without creating the new problems that conventional objects do. Why doesn't Java support pattern matching?
- tkahn6 16y ago
  Or have closures yet.
- barrkel 16y ago
  Typeclasses don't solve the same problems as objects do. Typeclasses are a way of getting access to more operations in polymorphic code, which in functional languages is a compile time feature; they're also a way to implement overloading. Objects are a way of implementing protocols without needing to know the details of the object that implements the protocol, even at runtime. Polymorphic code in OO systems is a runtime feature, not a compile time one; objects may be loaded dynamically and almost always are at some level in any large OO system, for configurability and testing if nothing else.
  - tkahn6 16y ago
    Since Haskell is statically typed, I think it's a feature, not a bug, that type parametricity is implemented at compile time. Also, I think what you're describing is the difference between parametric polymorphism and ad-hoc polymorphism.
  - loup-vaillant 16y ago
    Because two features are different doesn't mean they don't solve the same problem. Here, most of the time, class polymorphism is used to solve problem best solved with parametric polymorphism (sometimes called genericness). class Base Base(int i_init) -- constructor virtual int f(int param) -- a method class Inherit1 (extends Base) int f(int param) -- reimplementation 1 class Inherit2 (extends Base) int f(int param) -- reimplementation 2 class Inherit3 … (ad nauseam) We don't need class polymorphism with inheritance, here. We can do simpler: class Base Base(int i_init, int f_init(int)) { f =: f_init; … } int f(int) Or even simpler: int f(int i_init, int f_init(int)) // C-like syntax f: int -> (int -> int) -> int -- Haskell syntax (And don't tell me that passing function as parameters is weird, or complicated. Functions are typically way simpler than "Objects".)
- cmars232 16y ago
  Typeclasses are a fine substitute for polymorphism in behavior (methods). But does Haskell throw out the baby with the bath water? Haskell seems to lack an ability to express a taxonomy of data models. Records are not even close to a substitute. Why can't Haskell make it easier to express data structures? Something "turtles all the way down" introspective, like a MOF (meta-object facility, http://en.wikipedia.org/wiki/Meta-Object_Facility http://en.wikipedia.org/wiki/Meta-Object_Facility) would be nice.

d0m 16y ago

Because there is already support for "records" as you say. Add the static type "interface" and you get a kind-of OO.

silentbicycle 16y ago

Because it has typeclasses, which solve the same problems without creating the new problems that conventional objects do. Why doesn't Java support pattern matching?

tkahn6 16y ago
Or have closures yet.
barrkel 16y ago
Typeclasses don't solve the same problems as objects do. Typeclasses are a way of getting access to more operations in polymorphic code, which in functional languages is a compile time feature; they're also a way to implement overloading. Objects are a way of implementing protocols without needing to know the details of the object that implements the protocol, even at runtime. Polymorphic code in OO systems is a runtime feature, not a compile time one; objects may be loaded dynamically and almost always are at some level in any large OO system, for configurability and testing if nothing else.
- tkahn6 16y ago
  Since Haskell is statically typed, I think it's a feature, not a bug, that type parametricity is implemented at compile time. Also, I think what you're describing is the difference between parametric polymorphism and ad-hoc polymorphism.
- loup-vaillant 16y ago
  Because two features are different doesn't mean they don't solve the same problem. Here, most of the time, class polymorphism is used to solve problem best solved with parametric polymorphism (sometimes called genericness). class Base Base(int i_init) -- constructor virtual int f(int param) -- a method class Inherit1 (extends Base) int f(int param) -- reimplementation 1 class Inherit2 (extends Base) int f(int param) -- reimplementation 2 class Inherit3 … (ad nauseam) We don't need class polymorphism with inheritance, here. We can do simpler: class Base Base(int i_init, int f_init(int)) { f =: f_init; … } int f(int) Or even simpler: int f(int i_init, int f_init(int)) // C-like syntax f: int -> (int -> int) -> int -- Haskell syntax (And don't tell me that passing function as parameters is weird, or complicated. Functions are typically way simpler than "Objects".)
cmars232 16y ago
Typeclasses are a fine substitute for polymorphism in behavior (methods). But does Haskell throw out the baby with the bath water? Haskell seems to lack an ability to express a taxonomy of data models. Records are not even close to a substitute. Why can't Haskell make it easier to express data structures? Something "turtles all the way down" introspective, like a MOF (meta-object facility, http://en.wikipedia.org/wiki/Meta-Object_Facility http://en.wikipedia.org/wiki/Meta-Object_Facility) would be nice.