search

Lysxia / generic-data

Generic data types in Haskell, utilities for GHC.Generics
https://hackage.haskell.org/package/generic-data
MIT License
44 stars 9 forks source link

Instances for the lattices package #21

Open yairchu opened 5 years ago

yairchu commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

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

yairchu commented 5 years ago

@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 commented 5 years ago

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

yairchu commented 5 years ago

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 commented 5 years ago

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

somethingGeneric :: SemiJoinLattice l => ...
yairchu commented 5 years ago

@phadej Yes exactly!

phadej commented 5 years ago

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 commented 5 years ago

@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.