Open mcabbott opened 1 year ago
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 "struct
ures" 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 struct
ures."
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).
fstructure
feels consistent for this.
Maybe this should be called
fstructure(x)
since there's nomap
. 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/2PR Checklist