Add missing ! to setindex in setting with a lens

[programmeroftheeve]

No description provided.

[jw3126]

Thanks for the PR. setindex! is missing on purpose, however. All lens operations should be pure. This means that they never should mutate an object, which setindex! does. Do you have a use case for this PR?

[programmeroftheeve]

My use case was modifing the value in a ref or array.

struct Foo
    a::Int
end

foo = Ref(Foo(1))

refLens = @lens _[].a

set(foo, refLens, 2)

It is for the modification of immutable objects inside of containers.

Equivalent code for current code base.

nonRefLens = @lens _.a
foo[] = set(foo[], nonRefLens, 2)

[programmeroftheeve]

But the pure-ness makes sense, perhaps a set! function is needed?

[tkf]

I've been thinking about how to support in-place operations in Setfield API. There are two possible semantics:

1. Mutate-if-mutable: Always use in-place operation for mutable object. This throws when the value cannot be convert'ed.
2. Try-mutate: Try to use in-place operation first; if the type cannot hold the new field value, re-construct the new container. (I implemented this semantics in BangBang.setindex!!. It should be easy to wrap it as a lens.)

An interesting consequence is that, when a.b :: Int, a.b = 1.0 would mutate a in-place with the mutate-if-mutable semantics while a would be re-constructed with the try-mutate semantics.

In terms of the (low-level) API, there are two possibilities

1. Per-call policy: Use one of the three "mutation policies" (i.e., current "always re-construct" plus above two).
2. Per-lens policy: Define (say) IndexLensMutateIfMutable and/or IndexLensTryMutate.

The surface syntax for the per-call policy would be relatively easy to implement as we just need to implement entry points that work like @set. Unfortunately, we already have @set! which is the most obvious syntax to use. But adding support after a deprecation period is not so bad.

The surface syntax for the per-lens policy would be a bit challenging. One possibility is:

@set a.(!b).c = value
@set a.(![1]).c = value

[jw3126]

In very early version of Setfield there was a per call option for mutation. See also #32.
I did not like it in practice however. I only rarely used it and it made defining ad hoc lenses more annoying. But as more practical need arises, I am open for impure lenses.

• decouple flattening and transformations tpapp/TransformVariables.jl#13
• https://github.com/tkf/BangBang.jl

I think to get this started I would prefer the per lens approach. The advantage is that it does not interfer with the current implementation. The disadvantage is that it is probably less dry, as you need to define multiple versions of each lens.

As for syntax I think we should start with something simple stupid. We could have @lens, @lens! @lens!! and @set, @set!, @set!!:

• The @set macros would be equivalent to a lens definition and a set. For instance:

@set!! o.a.b.c.d = x 

would be equivalent to

let l = @lens!!(_.a.b.c.d)
     set(o, l, x)
end

• If you want fine grained control of where to use which policy in a long chain a.b.c.d you would need composition: @lens(_.a.b) ∘ @lens!!(_.c.d).

[colinxs]

Any update on this? This functionality would be quite useful for wrapping deeply-nested C structs where the top level struct may or may not be mutable. Happy to help out as well!

[jw3126]

No, I think nothing happened here in this direction. If you want to contribute, that is awesome. I think the hardest decisions are where the mutation is controlled. Quoting @tkf:

In terms of the (low-level) API, there are two possibilities

1. Per-call policy: Use one of the three "mutation policies" (i.e., current "always re-construct" plus above two).

2. Per-lens policy: Define (say) `IndexLensMutateIfMutable` and/or `IndexLensTryMutate`.

I lean towards 2. Maybe @tkf has some opinions on 1. vs 2. or entirely different ideas?

[colinxs]

I took a stab at the per-lens approach and it's not too bad. I'll push the branch when I'm back at my desk. If that's the approach we want to go with I'm happy to flesh things out a bit more. I'm hoping to release a suite of software packages soon and having the ability to mutate objects would greatly help, so the motivation is there :) Colin X Summers University of Washington Personal Robotics Lab www.colinxsummers.com

…

On Mon., 7 Oct. 2019, 13:05 Jan Weidner, ***@***.***> wrote: No, I think nothing happened here in this direction. If you want to contribute, that is awesome. I think the hardest decisions are where the mutation is controlled. Quoting @tkf <https://github.com/tkf>: In terms of the (low-level) API, there are two possibilities 1. Per-call policy: Use one of the three "mutation policies" (i.e., current "always re-construct" plus above two). 2. Per-lens policy: Define (say) `IndexLensMutateIfMutable` and/or `IndexLensTryMutate`. I lean towards 2. Maybe @tkf <https://github.com/tkf> has some opinions on 1. vs 2. or entirely different ideas? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#71?email_source=notifications&email_token=AELLS2DJOIWOVD2KBZ5WW43QNOI7HA5CNFSM4IFSYGAKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEART65Q#issuecomment-539180918>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AELLS2DD4P5WVLMZVNXKQO3QNOI7HANCNFSM4IFSYGAA> .

[tkf]

@jw3126 Yeah, I think per-lens mutation policy is the way to go. Also, using BangBang.jl for a while, I think try-mutate semantics is more useful than mutate-if-mutable or always-mutate.

[colinxs]

I pushed my quick-and-dirty implementation of the per-lens mutation policy. Hopefully this is along the lines of what you all were thinking! I had to merge #91 because of the circular dependency between BangBangv0.3.1 and Setfield.

Initial thoughts?

[tkf]

Closing, as #92 has more discussion.