> Codata looks a lot like objects and methods, where the codata value is the object, and the eliminators are the methods. ... the usual Functional Programmer has been an Object Oriented Programmer before. Because of this, he is likely to know codatafrom OO, and now is starting to understand data from FP
To me Python, Java, C++ are about encapsulation of imperative effects, but article is not about that kind of OOP
I think article is talking about v.f() "eliminator" vs f(v) "constructor" and that objects and closures are equivalent, but I am missing the deep insight beyond that. I don't understand how this helps with the expression problem (lets me not recompile my code to add new match cases to add additional data constructors)
Functions (or closures) are the prototypical codata... a co-inductive codata can be presented as a function space from an inductive datatype into some other type. It has a coinduction principle, derived from the induction principle of the parameter type. Traditional imperative code can be represented through the use of a free monad over a functor representing some command language, and the free monad is a codata as well.
To me Python, Java, C++ are about encapsulation of imperative effects, but article is not about that kind of OOP
I think article is talking about v.f() "eliminator" vs f(v) "constructor" and that objects and closures are equivalent, but I am missing the deep insight beyond that. I don't understand how this helps with the expression problem (lets me not recompile my code to add new match cases to add additional data constructors)