Closed timholy closed 1 year ago
Do you want that type, possibly together with its printing functions, to live here?
I think maybe we don't? It's obviously useful, but there might be more fields needed for specific purposes.
Generally I feel there's may possible fields which might be needed in various analyses or transformations and we can't hope to cover them all. (JuliaFormatter, for example, has its own entire set of fields for formatting purposes.)
I'm super happy to cover the common cases if we know what they are. Or somehow just make it really easy to build custom trees with "extra" fields. mutable struct TreeNode{NodeData}
seems like a good start on that.
I now think that the best way to handle https://github.com/JuliaDebug/Cthulhu.jl/pull/345 is to create
Do you want that type, possibly together with its printing functions, to live here? Or should it be a separate package?
A more invasive but extensible approach would be to factor out the "data" of nodes from the tree structure. Then assembly and traversal become orthogonal from content. So we'd have
mutable struct TreeNode{NodeData}
withparent
,children
, andval::Union{NodeData,Nothing}
, whereval
(for any node that isn't just a container of other nodes) might beThen we'd only need
TypedSyntaxData
with an extratyp
field; everything else would be reusable.