add getkeypath and haskeypath

[CarloLucibello]

Some convenience functions for KeyPath on top of #74 so that we can have

x = Dict(:a => 3, :b => Dict(:c => 4, "d" => [5, 6, 7]))
kp = KeyPath(:b, "d", 2)
@assert haskeypath(x, kp)
@assert getkeypath(x, kp) == 6

The possibly controversial part of this PR is that we define indexing with a KeyPath for @functorized types.
This would be no longer possible if we decide to functorize everything by default as proposed in #49, so maybe better leave the indexing part out?

TODO

• wait for extend fmapstructure and add KeyPath, fmap_with_path, fmapstructure_with_path #74 to be merged
• add a convenience macro constructor kp":a.1.'a'"? (not worth it at the moment)

[ToucheSir]

What's your thought on extensibility for arbitrary types? Do we care about that or is it not a problem because functor is always called first? If we do care, what's the API for extension? Would it be worth piggybacking off an existing library/API like Accessors.jl for that purpose?

[CarloLucibello]

I'm not sure what you mean, getkeypath and haskeypath do not rely on functor and can be used on arbitrary types.

The convenience of using indexing x[kp] instead of getkeypath is something provided by the @functor macro, but I think that maybe tying like that orthogonal functionalities is better avoided, especially since with indexing are adding little extra value.

[ToucheSir]

I'm not sure what you mean, getkeypath and haskeypath do not rely on functor and can be used on arbitrary types.

One example I thought of is types like Tangent from ChainRules which try to hide their internal details and ask users to call getproperty instead. Since Optimisers claims to work with these structural tangent types, it would be nice if the keypath functions treated them the same way as, say, a NamedTuple with the same fields. Presently, I think an extra key would be required on the keypath for each nested Tangent to access its internal backing field.

[CarloLucibello]

ok now I understand.

As you said maybe we don't have to care because in a recurrence one calls functor and constructs the KeyPath object along the way. If needed we can point users to overload _haskey and _getkey for their types.

Or we can tie these new methods to functor and do something like

_haskey(x, k::Symbol) = k in children(x)

function _getkey(x, k::Symbol)
    assert _hasjey(x, k)
    return getproperty(x, k)
end

I'm not sure which one is better.

[ToucheSir]

Do you think we could make the keypath functions use getproperty and propertynames instead of getfield and fieldnames? I can't think of any cases where that would fail currently, and it would align with how .field access lowers to getproperty.

[CarloLucibello]

I didn't know about the existence of propertynames. Yes it seems the sensible thing to do, I'll change the implementation.

[CarloLucibello]

ready to go