Separate isomorphisms from lenses

[jackfirth]

It might be a cleaner API for isomorphisms to be treated as separate entities from lenses. There could be a isomorphism->lens function that turns isomorphisms into lenses, as well as isomorphism-compose, isomorphism-to, and isomorphism-from functions for using isomorphisms.

I personally like explicitly requiring turning isomorphisms into lenses, and it removes isomorphism lenses' dependency on a generic interface for lenses.

@AlexKnauth Thoughts?

[AlexKnauth]

I think isomorphisms are perfectly valid lenses. It might make sense to have isomorphisms as a "subtype" of lenses, and operations that only work on isomorphisms, like isomorphism-compose. That could simplify lens-compose (etc.) because then it wouldn't need the special case of making sure that composing isomorphisms results in an isomorphism.
Note: If you really hate generic interfaces that much, then isomorphisms don't require them. You would just have to explicitly make the lens? predicate accept both structs, make the lens/c contracts recognize both, and allow both structs in lens-view and lens-set, instead of having the generic interface handle all of that for you.
Lenses are a wonderful abstraction, and that wonderful abstraction includes the case of isomorphisms as a subset. Otherwise it's like saying functions of the form y=mx+b shouldn't be functions because there are things you can do with y=mx+b functions that you can't do for another arbitrary function, and you would require an explicit (two-dimensional-affine-non-vertical-line->function y=mx+b-thing) conversion before you could do anything function-y with it. What?

[jackfirth]

It's less an aversion to generic interfaces, more an aversion to subtyping in general. In this scenario, lens/c wouldn't accept isomorphisms, you'd have to explicitly convert them to lenses first, because isomorphisms don't act as lenses by default - you have to choose that behavior explicitly. I tend to prefer the Haskell approach where there's no subtyping, but compile time polymorphism is achievable with typeclasses. That has it's own pile of messes however, and it's definitely not "Rackety". So upon reflection, keeping the generic interface and subtyping approach is fine with me.

Re isomoprhism-compose - yes I really like the idea of providing that and not implementing that behavior in lens-compose.

[AlexKnauth]

I just remembered something I said yesterday at RacketCon that I think I should put here, partly to remind myself. I think it makes perfect sense for lens-view and other functions that consume lenses to work on isomorphisms as a subtype, but it doesn't necessarily make sense for functions that return lenses to return isomorphisms for special cases. That job should be given to functions like isomorphism-compose.

That way it's safer too, because you know from looking at it that it returns an isomorphism. But if you used lens-compose with a special case that you were relying on returning a subtype, the output could easily change, and you wouldn't know right away what happened. So that's why returning subtypes for outputs in special cases is bad, but subtyping for inputs doesn't have that problem.

[jackfirth]

Closing in favor of current implementation. Future uses for isomorphisms on their own may require revisiting this.