Why (co)algebra classes final?

[schernichkin]

Any good reason to keep it final? I found useful to define an abstract class with helper function for building complex algebra, I think it would be nice to extend algebra class itself.

[andyscott]

Originally all of the algebra types were simply type aliases for plain functions. It turns out, though, that it's a bit easier to work with the Scala typer if you treat algebras as their own distinct types. For the time being the easiest way to do this was to use value classes. Longer term I'd like like to use opaque types, if they ever land in mainstream Scala :).

That being said, I can see some utility being able to extend algebra types. What kind of operations were you hoping to add?

[schernichkin]

I have a co-algebra which adds inherited attributes to underlying co-algebra. At each step it calculates inherited attributes, run underlying co-algebra to get result and map it to extend carrier with attributes. Underlying co-algebra is replaceable (e.g. one implementation reads files from disk when other uses predefined in-memory structure). I have several options here, such as passing underlying co-algebra as parameter (but actually it was a simplified example, I my task I have to parameterize underlying co-algebra as well and thing get ugly); or I can use abstract builder object with method coalgebra which will perform necessary bindings and construct final coalgebra. But I see no reason why builder can't implement coalgebra itseft by overriding run method.

Though can't be sure making co-algebras extendable is better in any scene than opaque types. As for me, I would prefer type aliases (btw, function trait in Scala not final) and working type checker.

[andyscott]

Makes sense. It might be okay for us to mark the various algebras as non final.

Regarding type aliases: they simply proved to be problematic to use since the Scala type checker would often get confused. Class based algebras get better type inferencing.