add shortcuts for Elements(), Properties(), @optic

[aplavin]

Allows for shorter and much nicer to read:

• @optic _[∗].a instead of @optic _ |> Elements() |> _.a,
• @optic _[∗ₚ][2] instead of @optic _ |> Properties() |> _[2].

[jw3126]

I wished several times, that these were easier to type. My main issue is that they require so many pipes and underscores around them. I wonder if we could do something like @optic _.@Elements().myfield. Possibly with a shorter name than @Elements. Or another mechanism than @ that makes chaining easier to type, I don't really like to collide with valid getindex usage.
I also wonder if we should have @o as a shorthand for @optic, I think I saw that already in one of your packages.

One downside of the current proposal is that it collides with getindex.

[jw3126]

btw thanks a lot for all the work you put into accessors already this year 😄

[aplavin]

My main issue is that they require so many pipes and underscores around them.

Same with me. These shortcuts (and @o for optic as well) are included in AccessorsExtra, and turned out to be the features I use the most :) And miss the most, when using Accessors alone.

One downside of the current proposal is that it collides with getindex.

Especially for Elements, getindex seems quite natural visually: xxx[∗]. What exactly is the "collision" you have in mind? Note that ∗ (\ast) is not *, so it's not type piracy! It's a unicode shortcut, I think it's fine to have unicode symbols as shortcuts as long as it's not the only way.

Alternatively, @optic _ |> ∗ |> _.a could be the intermediate approach – but unfortunately ∗ requires parentheses here.

That's why I went with getindex: it's short, convenient, doesn't require extra chaining syntax, and basically impossible to encounter accidentally (need to type ∗ or Elements()).

[aplavin]

btw thanks a lot for all the work you put into accessors already this year 😄

Yeah, from time to time I look at AccessorsExtra and my adhoc scripts to see what can and makes sense to be upstreamed here :)

[jw3126]

Especially for Elements, getindex seems quite natural visually: xxx[∗]. What exactly is the "collision" you have in mind? Note that ∗ (\ast) is not *, so it's not type piracy! It's a unicode shortcut, I think it's fine to have unicode symbols as shortcuts as long as it's not the only way.

∗= 3
f = @optic _[∗]
@assert f([1,2,42]) == 42 # will fail with this proposal

is a gotcha.

[aplavin]

Heh, nice edge case :) We can fix that by always resolving ∗ within @optic context as Accessors.∗.
Oh, and not even export these symbols to avoid potential clashes.

[aplavin]

After some thinking, I believe the regular export approach is both most straightforward, and least like to cause inconsistencies. Your example is similar to someone defining a variable/function/... named Elements or If: the effect is the same, corresponding Accessors exports become shadowed in this case. That's just how Julia works.

[jw3126]

Your example is similar to someone defining a variable/function/... named Elements or If: the effect is the same, corresponding Accessors exports become shadowed in this case. That's just how Julia works.

In these cases the correct scope is used:

using Accessors

struct Elements end

(::Elements)(x) = 2*x


o = @optic _ |> Elements()

@assert o(1)  == 2 # works

[jw3126]

This looks much better than doing it at "parse time". Can you add a test where the user defines these symbols?

[jw3126]

Optionally we could add a layer of indirection and instead of overloading the IndexLens constructor with something that is not an IndexLens, do this dispatch in another function index_like_lens.

[jw3126]

Oh I think I misread your code from the very beginning. The problem I imagined with symbols being pulled from the wrong scope might never have existed. Can you add a testcase like this:

∗= 3
f = @optic _[∗]
@test f([1,2,42]) == 42

and then it is good to go.

[aplavin]

And I also misread your "gotcha example", thinking that you suggest that ∗ should always be resolved as Elements() no matter what the user has defined :)

Added tests.

[aplavin]

The @o shortcut is so nice, I really enjoy using it :)
Even shorter than an anonymous function (same length with brackets), but reads cleaner somehow:

x -> x.a + 1
@o _.a + 1
(@o _.a + 1)

[jw3126]

I also like it.