"Concat lens": combine multiple lenses side by side about accessors.jl

[jw3126]

I think if you have two "commuting" lenses then you can concatenate them and get a lens again.
By orthogonal I mean that the following holds:

lens1(obj) == lens1(@set lens2(obj) = val2))
lens2(obj) == lens2(@set lens1(obj) = val1))

So for instance @optic _.a and @optic _.b are orthogonal (unless you have weird overloads), while
@optic _[1:2] and @optic _[2:3] are not.

struct ConcatLens{L1,L2}
    lens1::L1
    lens2::L2
end
function (lens::ConcatLens)(obj) 
    (lens.lens1(obj), lens.lens2(obj))
end
function set(obj, l::ConcatLens, (val1, val2))
    obj1 = set(obj, l.lens1, val1)
    set(obj1, l.lens2, val2)
end
function concatenate(lens1, lens2) 
    ConcatLens(lens1, lens2)
end

There are all kinds of fancy optimizations one could do for instance when concatenating property lenses.

You could also make concatenation of arbitrary optics possible in a similar way, by overloading modify, setall, getall.
I think it is only a sane operation for optics that are commuting in the sense that

getall(obj, optic1) == getall(setall(obj, optic2, vals2), optic1)
getall(obj, optic2) == getall(setall(obj, optic1, vals1), optic2)

We don't want to check that at runtime, it would be the user's responsibility.
Syntax can be improved later on. But a recurrent request is to do "batch mode" @set.

[aplavin]

Syntax can be improved later on. But a recurrent request is to do #15.

Yeah, indeed this is basically "multi-set", or "multi-optics" more generally. Here, I intentionally avoided talking about any convenience syntax for the operation, because it's pretty hard (possible at all?..) to come up with something general that's shorter than the full form of two lenses.

Another difference that simplifies the potential implementation is that "ConcatLens" semantically doesn't have to perform all set operations at once. It's explicitly combined from multiple independent lenses, and users should easily understand that these lenses can be applied one by one - requiring that each intermediate state is valid, cf jw3126/Setfield.jl#144 (comment).

There are all kinds of fancy optimizations one could do for instance when concatenating property lenses.

Given the "concat semantic", combining multiple compatible lenses (eg PropertyLens or IndexLens), can be considered a performance optimization and implemented later.

I think it is only a sane operation for optics that are commuting
We don't want to check that at runtime, it would be the user's responsibility.

Totally agree!

I may attempt implementing concatlens soon. Is "concat" the right term here? We need a separate function anyway - cannot reuse eg Base.vcat because lenses can be arbitrary objects/functions.

[jw3126]

I may attempt implementing concatlens soon. Is "concat" the right term here?

I think in haskell it is called productLens.

[aplavin]

Thanks! I understand the reference to the cartesian product here, but to me seems weird to refer to this operation on lenses as a "product" in practice.

[jw3126]

Yup I agree. There is also 'alongside' in Haskell, which does what I would intuitively have called product.

[aplavin]

This functionality is now available in AccessorsExtra in two variants:

• optic ++ optic ++ ... or @optics ...: multivalued optics, support modify/getall/setall
• @optic₊ ...: lense whose value is a container, tuple/array/...; support all operations.

Two variants may seem redundant, but both appear to be useful. See examples, comments and suggestions are welcome.