algebra
algebra copied to clipboard
Binary compatibility and typeclass surface
Looking at transformation methods in typeclasses, I wonder about how to keep binary compatibility in the future.
Suppose that library A depends on non/algebra version 1 to implement a few typeclasses.
In non/algebra version 2, helper methods such as Semilattice.asMeetPartialOrder
are added.
Now, suppose that library B depends on non/algebra version 2; on objects originating from library A, the Semilattice.asMeetPartialOrder
methods will either not be available, or subtly break down (see scala/scala-dev#35).
My opinion: typeclasses should expose a minimal surface consisting of the operations of the algebraic structure only. Implicit extension methods should then be used to provide asMeetPartialOrder
, even taking an implicit parameters to allow specialized transformations.
Another point to settle about binary compatibility: additional typeclasses can be added without breaking binary compatibility, except when they are inserted in the inheritance scheme. As of now, non/algebra is not including semicategories, categories, groupoids, magmas, quasigroups, loops ( according to https://en.wikipedia.org/wiki/Algebraic_structure ). I'm not in favor of including everything and the kitchen sink --- we should decide on what's not included and document it.
(We have to be extra-careful about binary compatibility --- if successful as an unifying project, non/algebra will be depended on by many projects for interoperability).