this post was submitted on 11 Aug 2024
15 points (100.0% liked)

Programming

17432 readers
226 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev



founded 1 year ago
MODERATORS
 

I think object algebras have huge potential to improve the way complex software is written but I've never seen them used in practice. I think one reason why is that the research paper which introduced them is pretty hard to read. This post is my attempt to change that.

I've been working on this post off and on for like two years so I'm really excited to share it with people. It is very long. There's a lot of ground to cover.

you are viewing a single comment's thread
view the rest of the comments
[–] jnkrtech@programming.dev 1 points 3 months ago (1 children)

Yes, this pattern is covered in my post on algebraic data types (linked at the start of the object algebras post.) The problem you mention about adding new data variants is exactly what object algebras solves. With object algebras data and functions are only co-located at the smallest possible granularity, so the desired functions and the desired data types can be composed as needed.

[–] expr@programming.dev 1 points 3 months ago (1 children)

Your post only showed adding functionality over the algebra, not new types on which the algebra operates (or "sorts", as they are otherwise known). In other words, you can't easily extend Expr to support Boolean logic in addition to addition itself. For a concrete example, how could you represent ternary operators like in the expression 2 + 2 == 4 ? 1 : 2, such that it's well typed and will never result in an exception? With GADTs, this is very simple to do:

data Expr a where
  Lit :: Int -> Expr Int
  Add :: Expr Int -> Expr Int -> Expr Int
  Eq :: Expr Int -> Expr Int -> Expr Bool
  If :: Expr Bool -> Expr Int -> Expr Int ->  Expr Int

eval :: Expr a -> a
eval expr = case expr of
  Lit n -> n
  Add a b -> eval a + eval b
  Eq a b -> eval a == eval b
  If p a b -> if eval p then eval a else eval b

-- >> eval example == 1 => true
example :: Expr Int
example =
  If ((Lit 2 `Add` Lit 2)  `Eq` Lit 4) (Lit 1) (Lit 2)
[–] jnkrtech@programming.dev 1 points 3 months ago

lemmy seems to have lost my response to this, so I'll type it again and hope that it doesn't show up twice

There's three separate issues here:

  1. The ability to express multi-sorted algebras

  2. The ability to extend algebras with new sorts

  3. The ability to extend a single sort of an algebra with new variants

For point 1, object algebras do support this even though I didn't show it in the post:

interface ExprAlg<Num, Bool> {
    lit: (value: number) => Num;
    add: (left: Num, right: Num) => Num;
    eq: (left: Num, right: Num) => Bool;
    iff: (interrogee: Bool, then: Num, els: Num) => Num;
}

const evaluate: ExprAlg<number, boolean> = {
    lit: (value) => value,
    add: (left, right) => left + right,
    eq: (left, right) => left === right,
    iff: (interrogee, then, els) => interrogee ? then : els
}

function makeExample<Num, Bool>(alg: ExprAlg<Num, Bool>): Num {
    return alg.iff(
        alg.eq(
            alg.add(alg.lit(2), alg.lit(2)),
            alg.lit(4)),
        alg.lit(1),
        alg.lit(2))
}

console.log(makeExample(evaluate)); // prints 1

For point 2, you are correct that the original Java formulation of object algebras does not support data sort extensibility. I haven't tried to see if TS's more powerful generics change this or not.

For point 3, consider what happens if you want to add a new variant to the data type. In this case, add a Mult variant for multiplication. With GADTs this is not possible without modifying or duplicating the existing evaluation code, but I can do it with object algebras:

type ExtendedExprAlg<Num, Bool> = ExprAlg<Num, Bool> & {
    mult: (left: Num, right: Num) => Num;
}

const extendedEvaluate: ExtendedExprAlg<number, boolean> = Object.assign({}, evaluate, {
    mult: (left: number, right: number) => left * right
})

function makeExtendedExample<Num, Bool>( alg: ExtendedExprAlg<Num, Bool>): Num {
    const one = alg.mult(alg.lit(1), alg.lit(1));
    return alg.iff(
        alg.eq(one, makeExample(alg)),
        alg.lit(3),
        alg.mult(alg.lit(2), alg.lit(2))
    )
}

console.log(makeExtendedExample(extendedEvaluate)); // prints 3

This is the point of object algebras. ADTs and GADTs can't do this out of the box; this is the essence of the expression problem and is why more advanced techniques like final tagless encodings and datatypes a la carte exist.