Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Codata in action, or how to connect FP and OOP

javiercasas.com

Post reply on HN
Print view View original

41–50 of 58 posts

Re: Codata in action, or how to connect FP and OOP

#41

Post by carterschonwald »

For a more concrete example, look at my nearly 5 year old post to Haskell reddit for embedding/faking copatterns in Haskell https://www.reddit.com/r/haskell/comments/4aju8f/simple_exam...

Was based off working to understand agdas notion of copatterns plus wanting to understand how to best mode protocols.

Def the case that copatterns capture the spirit and essence of oop done right. And with immutable or linear logic flavor codata, it becomes possible to also do stronger polymorphic updates than you can traditionally do with oop. Also you can nicely model type state varying apis for a single object

Edit : I also 2-3 years ago did a related live coding lecture which is related and some might Like https://github.com/cartazio/symmetric-monoidal/blob/master/s...

Re: Codata in action, or how to connect FP and OOP

#42

Post by lapinot »

guerrilla wrote: post #17

While we're on this subject, if we were to keep extending the syntax, is this what introProduct would have to look like? data Coproduct a b where InjL :: a -> Coproduct a b InjR :: b -> Coproduct a b elimCoproduct :: (a -> c) -> (b -> c) -> Coproduct a b -> c elimCoproduct f g (InjL x) = f x elimCoproduct f g (InjR y) = g y codata Product a b where ProjL :: Product a b -> a ProjR :: Product a b -> b introProduct :: (…

Exactly! Maybe you've seen them before but what you just wrote are so-called "copatterns". See:

https://www.cs.mcgill.ca/~bpientka/papers/unnesting-copatter...

https://doi.org/10.1017/S0956796819000182

https://agda.readthedocs.io/en/latest/language/copatterns.ht...

Agda even has extra sugar on top for postfix projectors: you could write `myPair .ProjL` (as expression and as copattern). Syntax for pattern-matching anonymous function crucially uses that (yup, we have multi-clause anonymous functions!). You'd write:

  introProduct f g z .ProjL = f z
  introProduct f g z .ProjR = g z
or

  introProduct = λ { f g z .ProjL → f z
                   ; f g z .ProjR → g z }
Note that most languages already have that "codata" thing but it's usually called "record" or "struct".

Re: Codata in action, or how to connect FP and OOP

#43

Post by jacinabox »

dustingetz wrote: post #36

> 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…

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.

Re: Codata in action, or how to connect FP and OOP

#44

Post by kjeetgill »

MaxBarraclough wrote: post #26
kjeetgill wrote: post #9

Earlier quoted context omitted.

Any OOP with inheritance does multiple dispatch. Java, C++ vitual functions, python via ducktyping. The article's concern is real but overstated in my opinion. When adding a new function in a hierarchy you'll either have a good default or you'll be implementing via type matching branches or 10 implementations in each type behind multiple dispatch. The difference, to me, is minimal.

> Any OOP with inheritance does multiple dispatch. Java, C++ vitual functions This is incorrect. C++ and Java are typical examples of languages that lack multiple dispatch, but are able to emulate it using the visitor pattern, as tsimionescu already mentioned. https://en.wikipedia.org/wiki/Multiple_dispatch#Emulating_mu...

Ah, yea. I was confusing dynamic dispatch for multiple dispatch.

My bad!

Re: Codata in action, or how to connect FP and OOP

#46

Post by DonaldPShimoda »

willtim wrote: post #21

This paper on "Object Algebras": https://www.cs.utexas.edu/~wcook/Drafts/2012/ecoop2012.pdf is a great example of using ideas from functional programming and category theory to improve on the visitor pattern, such that the expresson problem can be solved. The value of such mathematics is that it enables us to formalise some of these patterns and generalise them.

> such that the expresson problem can be solved.

I'll add this paper to my reading list (because this is very much something I'm interested in), but in the meantime could you explain what you mean by "solving" the expression problem?

My understanding has been that EP is more of a lens through which to evaluate the usefulness of solutions along the objects-or-functions spectrum, rather than an actual problem to be solved in a traditional sense. Does the paper you linked design a system in which the full breadth of that spectrum is made expressible with no concessions?

Re: Codata in action, or how to connect FP and OOP

#47

Post by drol3 »

Cool :)

Sometimes seeing the same concept from different perspectives makes it easier to understand. For a scala treatment of the same topic see

https://underscore.io/blog/posts/2017/06/02/uniting-church-a...

Also in Scala; an interesting solution to the expression problem:

https://i.cs.hku.hk/~bruno/papers/Modularity2016.pdf

Its a paper, but its very light on dense academic prose and very heavy on copy pastable code :)

Re: Codata in action, or how to connect FP and OOP

#48

Post by wk_end »

rjsw wrote: post #39

I know people who are members of CODATA [1], didn't know they were working on this kind of thing. Maybe people could search for previous uses when they are picking a name for a concept, I think there are websites that let you do that /s. [1] https://en.wikipedia.org/wiki/Committee_on_Data_for_Science_...

Category theory, which is where the convention of using a "co-" prefix to refer to the "arrow-flipped" dual of a category comes from, predates CODATA by nearly twenty years. Maybe the CODATA folks shouldn't have presumed that they were the category-theoretic dual of data?

Re: Codata in action, or how to connect FP and OOP

#49

Post by [deleted] »

jacinabox wrote: post #43
dustingetz wrote: post #36

> 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…

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 w…

[deleted]
Post reply on HN