Instances for the lattices package

[yairchu]

It would be useful to implement derivations for PartialOrd, Lattice, BoundedJoinSemiLattice, etc from the lattices package.

Do you think that this should this fit in generic-data? Or rather it should go in the lattices package? Perhaps lattices is the right place for it as it is the more changing package (its interfaces recently changed)

cc @phadej

[Lysxia]

I would like to keep the dependencies of generic-data minimal. And unless the lattices maintainers are keen on taking on a generic implementation, I think a separate lattices-generic package would be the next best solution. I would be glad to help with such an implementation either way.

[phadej]

There are no way to make (Lattice a, Lattice b) => Lattice (Either a b); also there is product partial ord and lexicographic partial ord.

Do you have an example, where generically derived PartialOrd or Lattice would be useful? (My gut feeling that lattice instances one would want are not the ones generic algorithm would give)

[yairchu]

@phadej I had in mind the product partial ord. But this is a good point so I guess this is a good reason to create both options via separate newtype wrappers for DerivingVia.

And deriving the Either case will produce a nice type error that sum type instances are not derivable.

https://github.com/lamdu/syntax-tree/blob/master/test/TypeLang.hs#L121 is an example to instances which could be derived with this mechanism via simply derive Lattice via Generically RConstraints. It's a one-liner and no big deal as it is to manually implement, but I strive that using my library will be as painless as possible :)

[phadej]

Fot that case I'd use Monoid, as there Lattice as in lattices-2 removed semilattices anyway.

[yairchu]

@phadej I was using lattices because the library also expects the actions to abide to their laws which are more than Monoid's. It can also be a Lattice and not just a semilattice, but the other semilattice just wasn't needed.

For lattices that abides to the laws etc, if one only uses their "join" part would you recommend to use Monoid?

[phadej]

@yairchu yes. Semilaatice is commutative and idempotent, but still Monoid.

[yairchu]

Of course it's a Monoid, but lattice has more laws than monoid does, and in my case the code requiring a lattice instance wants the lattice laws to hold!

[phadej]

@yairchu do you have code which works with arbitrary SemiJoinLattice, i.e. do you have functions

somethingGeneric :: SemiJoinLattice l => ...

[yairchu]

@phadej Yes exactly!

[phadej]

Ok, then unfortunately lattices-2 doesn't suit you well. I should write about why I did reogranise the hierarchy. TL;DR there were different trade-offs. If you really need fine-grained lattice classes, check https://hackage.haskell.org/package/semilattices

[yairchu]

@phadej I don't think it's a problem for me that semilattices are no longer supported, although I only use the "join" action I can require Lattice in my case even though I don't use all of its capabilites.