FluxML
One-argument `fmapstructure(x)`
Maybe this should be called fstructure(x) since there's no map. The point is to strip all the types for saving etc. Apparently others believe this method should exist: https://discourse.julialang.org/t/how-to-load-bson-file-of-the-model-build-with-flux-0-12-10-to-use-with-flux-0-13-flux-diagonal-deprecated-problem/91588/2
PR Checklist
- [ ] Tests are added
- [ ] Documentation, if applicable
Could we find a more descriptive name by ditching the f<verb> convention here? Frankly it only made sense for functions which might've been confused for Base ones, and otherwise mostly serves to confuse folks who don't know about FP idioms.
Is structure(x) going to be confusing next to destructure which isn't the opposite? Other words... plain or simple etc?
As long as it isn't exported I don't see an issue. We've been given to using "restructure" as the inverse of "destructure", after all. That said, made up verbs like "structurize" might also work.
Jax uses tree_structure to return the treedef. I think it could be confusing to use *structure both in verb and noun form. Could we do structural_def(x) or structural(x) to imply that we are keeping the structural definition of the tree?
What I don't like about fmapstructure as a name (in any form) is that the "structures" are precisely what it does not preserve. It preserves the graph of children, it uses only Base objects...
What about tree_def(x) or graph_def(x)? So "give me the graph definition that underlies these nested structures."
There has got to be a nice name somewhere. They aren't strictly trees due to cache. "simple" or "strip" or "raw"... It's basically a recursive application of children, does that go anywhere, "family", "grandkids"?! child_graph(x)?
I think any ancestral tree/graph analogies beyond referring to the parent/children of a single node is confusing. I am okay with something like strip or simplify (or the noun versions).
