3 ms·

While I've seen various methods in scheme to emulate objects with closures, I haven't seen a good one from the statically typed FP camp (the ML family, Haskell,

While I've seen various methods in scheme to emulate objects with closures, I haven't seen a good one from the statically typed FP camp (the ML family, Haskell, etc). Meanwhile, objects are able to masquerade as closures very nicely in statically typed OO object systems like Scala and C#. So I lean more towards closure being a poor mans object than vice versa.

deleted 9y ago
[deleted]
tel 9y ago
OCaml, Objective Caml, has a built-in Object system. Objects are immutable which prevents them from carrying identity (though mutation can be opted into to recover this). They're also "just" row-typed records. Classes are a form of constructor function which have inheritance for code sharing purposes. This isn't emulating objects with lambdas, but it is a well-articulated idea of what objects in a pure-ish FP setting might look like. There have been many attempts to bring various forms of "object" into Haskell. It tends to be either a very simple or a very messy affair. On the messy side, strict purity blows up object identity again and there are only very messy ways to recover it. This makes most OO such a pain that you're more likely to factorize it into smaller pure components which appear more functional. On the simple side, corecursive patterns are distinctly "object like" and are used all the time. Laziness gives you infinite data structures which, in effect, give you a limited form of mutability which can be incredibly helpful while still be easy to reason about. --- Finally, I think that practically there is a strong case to be made for introducing actor-like objects into Haskell. It has a great runtime and exception system to support it, and it would allow a bit more structuring "at the highest level" of application architecture. Today these are often managed as imperative programs (built an IO chunk, execute it). This tends to work, but Erlang did it better.
- lacampbell 9y ago
  OCaml, Objective Caml, has a built-in Object system. Objects are immutable which prevents them from carrying identity (though mutation can be opted into to recover this). They're also "just" row-typed records. Classes are a form of constructor function which have inheritance for code sharing purposes. This isn't emulating objects with lambdas, but it is a well-articulated idea of what objects in a pure-ish FP setting might look like. Ocamls objects are great. I'm familiar with them and a big fan. I wish there was a whole language based around them, ie everything is an ocaml style object. That having been said, they do feel odd and out of place in Ocaml, and people don't seem to use them much.
KingMob 9y ago
To extend your point, this was written in the context of Scheme, which like most Lisps, is not statically typed. In Lisps, it's trivial to build up an object with closures. (Create a fn that accepts some data, then return a data structure with fns that close over that data, and voila, object.) Building an OOP system is Lisp is a homework exercise.
kaosjester 9y ago
Perhaps unsurprisingly, Oleg rebuilt the linked implementation in Haskell [0]. It works exactly as you'd expect, right out of the box. 0. https://arxiv.org/abs/cs/0509027 https://arxiv.org/abs/cs/0509027
- lacampbell 9y ago
  The haskell code looks much hairier. Then again I don't know haskell very well, and he did have to spin this out into its own paper.

deleted 9y ago

[deleted]

tel 9y ago

OCaml, Objective Caml, has a built-in Object system. Objects are immutable which prevents them from carrying identity (though mutation can be opted into to recover this). They're also "just" row-typed records. Classes are a form of constructor function which have inheritance for code sharing purposes. This isn't emulating objects with lambdas, but it is a well-articulated idea of what objects in a pure-ish FP setting might look like. There have been many attempts to bring various forms of "object" into Haskell. It tends to be either a very simple or a very messy affair. On the messy side, strict purity blows up object identity again and there are only very messy ways to recover it. This makes most OO such a pain that you're more likely to factorize it into smaller pure components which appear more functional. On the simple side, corecursive patterns are distinctly "object like" and are used all the time. Laziness gives you infinite data structures which, in effect, give you a limited form of mutability which can be incredibly helpful while still be easy to reason about. --- Finally, I think that practically there is a strong case to be made for introducing actor-like objects into Haskell. It has a great runtime and exception system to support it, and it would allow a bit more structuring "at the highest level" of application architecture. Today these are often managed as imperative programs (built an IO chunk, execute it). This tends to work, but Erlang did it better.

lacampbell 9y ago
OCaml, Objective Caml, has a built-in Object system. Objects are immutable which prevents them from carrying identity (though mutation can be opted into to recover this). They're also "just" row-typed records. Classes are a form of constructor function which have inheritance for code sharing purposes. This isn't emulating objects with lambdas, but it is a well-articulated idea of what objects in a pure-ish FP setting might look like. Ocamls objects are great. I'm familiar with them and a big fan. I wish there was a whole language based around them, ie everything is an ocaml style object. That having been said, they do feel odd and out of place in Ocaml, and people don't seem to use them much.

KingMob 9y ago

To extend your point, this was written in the context of Scheme, which like most Lisps, is not statically typed. In Lisps, it's trivial to build up an object with closures. (Create a fn that accepts some data, then return a data structure with fns that close over that data, and voila, object.) Building an OOP system is Lisp is a homework exercise.

kaosjester 9y ago

Perhaps unsurprisingly, Oleg rebuilt the linked implementation in Haskell [0]. It works exactly as you'd expect, right out of the box. 0. https://arxiv.org/abs/cs/0509027 https://arxiv.org/abs/cs/0509027

lacampbell 9y ago
The haskell code looks much hairier. Then again I don't know haskell very well, and he did have to spin this out into its own paper.