This PR adds support for parsing `.a` as `x->x.a`. This kind of thing has come
up multiple times in the past, but I'm currently finding myself doing a lot
of work on nested structs where this operation is very common.
In general, we've had the position that this kind of thing should be a special
case of the short-currying syntax (e.g. #38713), but I actually think that might
be a false constraint. In particular, `.a` is a bit of a worst case for the curry
syntax. If there is no requirement for `.a` to be excessively short in an eventual
underscore curry syntax, I think that could open more options.
That said, any syntax proposal of course needs to stand on its own, so let me
motivate the cases where I think this plays:
A. Curried getfield
I think this is probably the most obvious and often requested. The syntax
here is very useful for situations where higher order functions operate
on collections of records:
1. `map(.a, vec)` and reductions for getting the fields of an object - also includes things like `sum(.price, items)`
2. Predicates like `sort(vecs, by=.x)` or `filter(!.deleted, entries)`
3. In pipelines `vecs |> .x |> sqrt |> sum`
I think that's mostly what people are thinking of, but the use case
for this syntax is more general.
B. A syntax for lenses
Packages like Accessors.jl provide lens-like abstractions. Currently these are written as
`lens = @optic _.a`. An example use of Accessors.jl is (from their documentation)
```
julia> modify(lowercase, (;a="AA", b="BB"), @optic _.a)
T("aa", "BB")
```
This PR can be thought of as providing lenses first class syntax, as in:
```
julia> modify(lowercase, (;a="AA", b="BB"), .a)
T("aa", "BB")
```
C. Symbol index generalization to hierachical structures
We have a lot of packages in the ecosystem that support named axes
of various forms (Canonical examples might be DataFrames and NamedArrays,
but there's probably two dozen of these). Generally the way that this
syntax works is that people use quoted symbols for indexing:
```
df[5, :col]
```
However, this breaks down when there is hierachical composition involved.
For example, for simulation models, you often build parameter sets and
solutions out of hierarchies of simpler models.
There's a couple of solutions that people have come up with for this problem:
1. Some packages parse out hierachy from symbol names: `sol[:var"my.nested.hierachy.state"]`
2. Other packages have a global root object: `sol[○.my.nested.hierarchy.state]`
2a. A variant of this is using the object as its own root `sol[sol.my.nested.hierarchy.state]`
2b. Yet another variant is having the root object be context specific `sol[sys.my.nested.hierarchy.state]`
3. Yet other packages put symbolic names into the global namespaces `sol[my.nested.hierarchy.state]`
These solutions are all lacking. 1 requires string manipulation for composition, the various variants of 2
are ok, but there is no agreement among packages what the root object looks like or is spelled, and
even so, it's an extra export and 3 pollutes the global namespaces.
By using the same mechanism here, we essentially standardize the solution `2`,
but make the root object implicit.`