Store lens composition as a list

[cfhammill]

Collapse them at over/view, this would facilitate editing lens stacks. @bcdarwin care to weigh in?

[cfhammill]

I think I've mostly convinced Ben this would be useful. The remaining questions are:

1. Are lists the right thing, or would writing lazy compose with appropriate lenses be better.
2. How (in)efficient would this be. My guess is it would be fine, but remains to be tested.

[bcdarwin]

I don't mind lenses being represented as an explicit AST (e.g., %.%, map_l, etc. merely store their arguments). In this case we might have some (lens!) combinators for various traversals of such a tree, but I guess the only thing you could do at a leaf is compare for identity, so I guess each lens would now have a name field which would ideally be the name of the lens plus a freshly generated symbol.

[cfhammill]

Generating symbols seems unnecessary as we both noticed, I'm fine with naming and equality checking as the primary way to inspect the elements of the lens composition, with shady folks like me potentially doing runtime code inspection for rare occasions where that would be useful.