Please, pack the 'Value.hs' funtions into type classes

[Anton-Latukha]

lmap is Profunctor
lift is MonadTrans
unlift is MonadTransUnlift
hoist are used only inside the module only to form lift/unlift
bind is Monad
iter is Free
sequence is Traversable traverse

[Anton-Latukha]

Of course, accounting for the lawful/unlawful implementations and provide tests.

[Anton-Latukha]

The RankNTypes use in functions and function context around them, and the cross-types use makes the class formation currently difficult. At least some of.
Needs more tries/looks into it. Maybe constraining back from some higher types where it is now possible.

[Anton-Latukha]

If something - it is an "idea to strive for".

I am aware those are not direct iter & such, but they are strong HOFs that very close to be a type class instance implementation.
The HOF functions always can be given default arguments (like id for natural transformations) & be specialized to particular instance implementation.

Due to the design of HNix & how already these HOFs are close to be instances - at some point, it is possible to "suddenly" get them as "weakly lawful" or lawful instances.

Some functions (currently) do not align by types to be for example iter, as iterNValue operates on thunks and transfers its type to NValue - so its signature does not align to iter completely.

Thou from the list there can be cases where implementation gets aligned with famous type classes.

Maybe it is a good idea to create equivalent type classes for those types of functions if we would have several sets of those for different types (aka for N{Expr,Thunk,Value}).

[Anton-Latukha]

With the number of funtions there - it would be ugly, but the functions should be duplicated & useless argument passing removed from them (as it was done in MonadThunk)- that would bring functions closer to type classes. This requires project-wide refactoring.