Move to `Accessors.jl` from `Setfield.jl`

[sunxd3]

Changes from Setfield to Accessors

• Accessors is based on ComposeFunction, which means all the optics are either function or functor. Also, no get(obj, optic) interface, but optic(obj).
• Lens abstract type doesn't exist in Accessors, IdentityLens is just identity, ComposedLens is now ComposedOptic (alias for ComposedFunction)
• Inner and Outer are interchanged, l1 ∘ l2 in Setfield is l2 ∘ l1 in Accessors. Accessors adopted ⨟(\bbsemi "opposite compose") from CompositionBase: l1 ∘ l2 in Setfield is l1 ⨟ l2 in Accessors.

Unsure

• The equivalence between VarNames are changed, before @varname(y[:], true) and @varname(y[1:100] (where y = zeros(10,10)) are considered to be ==. But with Accesssors, two IndexLens are generally not equivalent even when they have the same field because they are also functors.
• Accessor.parse_obj_optic and Setfield.parse_obj_lens behave differently when deal with interpolation. I have tried and failed to maintain the current interface with Accessor.parse_obj_optic, so I am keeping Setfield.parse_obj_lens (and Setfield as a dependency), while replace the Lens with optic in the result of Setfield.parse_obj_lens.
• Optics are functions or functors, how would this affect type stability?

[codecov[bot]]

Codecov Report

Attention: Patch coverage is 80.76923% with 20 lines in your changes are missing coverage. Please review.

Project coverage is 82.72%. Comparing base (b342b3d) to head (22ad3fa). Report is 6 commits behind head on main.

Files	Patch %	Lines
src/varname.jl	80.76%	20 Missing :warning:

Additional details and impacted files

```diff @@ Coverage Diff @@ ## main #91 +/- ## ========================================== - Coverage 84.82% 82.72% -2.11% ========================================== Files 3 3 Lines 145 191 +46 ========================================== + Hits 123 158 +35 - Misses 22 33 +11 ```

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[sunxd3]

Before, Setfield has == defined for IndexLens (https://github.com/jw3126/Setfield.jl/blob/e31e1e361bd6a251124aa578122e6198b81197b5/src/lens.jl#L196), and we have AbstractPPL.ConcretizedSlice{Int, Base.OneTo{Int}}(Base.OneTo(100)) == UnitRange(1, 100), so the two VarName is equivalent. By saying "they are functor", I am just making a guess why Accessors doesn't have this == defined as Setfield does: it might be related to the semantic meaning of functions equivalence.

[sunxd3]

@torfjelde another look?

[sunxd3]

Just made some adjustment, Setfield is removed from the deps.

The interpolation is weaker compared to before. It is mainly attributed to Accessors.parse_obj_optic. Now more than one interpolated symbol (e.g. @varname($n1[$n2+1])), and interpolation of the LHS of a . expr (e.g. $name.a[1]) are disallowed.

[torfjelde]

By saying "they are functor", I am just making a guess why Accessors doesn't have this == defined as Setfield does: it might be related to the semantic meaning of functions equivalence.

Might be worth raising an issue and asking about this, as IIUC it should be okay to define == for some of the optics, e.g the getindex one.

[sunxd3]

The interpolation ability was added by @phipsgabler at https://github.com/jw3126/Setfield.jl/pull/168, but this never got ported to Accessors.

I do think the interpolation can be quite handy, but that means we need to keep Setfield around for a while.

[torfjelde]

Is there a reason why we can't just copy-paste the macro? :shrug:

[yebai]

Is there a reason why we can't just copy-paste the macro? 🤷

That should work since it is only a small utility function.

[sunxd3]

@torfjelde @yebai function copied, not sure if it's small, but it should maintain the interpolation ability.