Functorizing Functors

[ToucheSir]

Since there's been a lot of talk about the current interface and limitations thereof, I thought I'd clean up and post a experimental branch that seeks to straighten out the library and make it more flexible. For those of you who saw me talking about recursion schemes and whatnot, this is what that was for ;)

The tests contain examples from this blog series as well as real-world problems that have come up before in Flux (e.g. FluxML/Flux.jl#1284). I plan on adding some Optimisers.jl-related ones and more as this develops. Obviously everything is very, very breaking, so if the experiment works out we'll have to think about potential migration plans. But until then, feedback and use cases where Functors.jl currently fails (e.g. when a custom walk function is required) are welcome!

[CarloLucibello]

Can you summarize what this PR does?

[ToucheSir]

There were two main motivations for this PR:

1. We're constantly having to override _walk in fmap for custom functions, if not ignore it altogether. This should be low-level internal functionality, so such frequent usage suggests the need for a better interface/abstraction.
2. Functors.jl currently allocates a lot of closures. What's more, you have to hold onto these closures to reconstruct many types because they capture non-functored fields as well. What ChainRulesCore showed with Tangent and ProjectTo is that reifying the transformed value into its own type can help quite a bit here. Yes it's nice to have a plain NamedTuple, but that has no additional semantic meaning which would allow you to tie it back to the original type it was created from.

One of the underlying issues with the current implementation is that the "functors" aren't really Functors in an FP sense. Functors.functor works fine for flattening, but my understanding is the goal was always to support generalized tree (well, DAG) traversals. Otherwise, the value proposition of Functors.jl over https://github.com/rafaqz/Flatten.jl becomes somewhat dubious. Thus, this PR aims to address any instance where we've had to work around Functors.jl functions in order to make something work. That includes every open Functors-related PR in this repo, Flux or Optimisers.jl. I won't belabour the point enumerating every instance, so if you're curious about a specific one then we can discuss from there.

[ericphanson]

this is the pre- #25 version of this code fwiw

[ToucheSir]

Oh, this entire directory shouldn't exist. I just haven't removed it from the source tree yet.

[ToucheSir]

In the spirit of not keeping too many Zombie PRs around, this was an interesting experiment but is unlikely to become reality any time soon. In particular, the programming interface is a little too "un-julian". Some of the interesting bits are also already in Functors or Optimisers as separate commits/PRs.