I recently found out that OOP classes turn out to be F-coalgebras:


The coalgebraic perspective on objects and classes in object-oriented programming is elaborated: objects consist of a (unique) identifier, a local state, and a collection of methods described as a coalgebra; classes are coalgebraic (behavioural) specifications of objects. The creation of a 'new' object of a class is described in terms of the terminal coalgebra satisfying the specification

In here, https://stackoverflow.com/questions/16015020/what-does-coalgebra-mean-in-the-context-of-programming the top answer's author describes this class

class C
    x, y  : Int
    _name : String
    name        : String
    position    : (Int, Int)
    setPosition : (Int, Int) → C

as a coalgebra like this:

data C = Obj { x, y  ∷ Int
             , _name ∷ String }

and the public methods like this

position ∷ C → (Int, Int)
position self = (x self, y self)

name ∷ C → String
name self = _name self

setPosition ∷ C → (Int, Int) → C
setPosition self (newX, newY) = self { x = newX, y = newY }

My question is this: Is it possible to actually define the public methods as an F-algebra?

Would this make an OOP class actually a bialgebra like described in here? https://www.researchgate.net/publication/220976988_Categorical_Programming_with_Abstract_Data_Types

The main idea is to represent an ADT by a bialgebra, that is, an algebra/coalgebra pair with a common carrier

Which would explain why so often classes are used to define abstract data types in OOP languages?


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.