add match-lens

[AlexKnauth]

No description provided.

[jackfirth]

This is interesting. It seems that it would often be the case that separate target-extraction and view-replacement wouldn't be needed, i.e. the car lens could be defined with just (match-lens a (cons a b)). It might be worthwhile to have a shorthand for that case.

[AlexKnauth]

Yes, and conceptually it should be that simple, but I thought that would be way two restrictive to be useful in much more than the simplest patterns. But that idea was part of my motivation for making this, because conceptually that's how it should be.

[AlexKnauth]

One thing I'm afraid of with a shorthand form like (match-lens* a (cons a b)) is that people will forget that the (cons a b) is used as an expression, and try things like (match-lens* a (cons a _)) or (match-lens* (list a b ...)). The first one is especially bad because (if they use fancy-app) it wouldn't actually raise an error, but would return a procedure for the result of a lens-set or lens-transform call. I wanted to be very clear that this is a match pattern and that is an expression.

[jackfirth]

I think I made that mistake while playing around with this code, so you're definitely right about that. What are some examples where pattern matching lenses are more useful than composing traditional lenses? It feels strange to have most of the library work on the principle of making atomic lenses that go one level down and composing them together, while match lenses operate in a very different fashion.

[AlexKnauth]

Match lenses can still just go one level down and can be composed with other lenses, even if they also allow going deeper. However, I think they can be a very clear and concise way of going "one level down" as well.

[jackfirth]

That's true. I get the feeling they'll be more for one-off cases, but they're still useful to have.