To define a tree as node or leaf (Caps = type, lower = constructor or record field):
Tree = leaf | node
leaf = Number
node = left: Tree, right: Tree
Today I believe I need to write:
leaf(n) and node(l, r) constructors to encode a type tag + fields as a list
isLeaf, isNode predicates to check type tag
leafNumber, nodeLeft, nodeRight accessors
etc.
Would this be the recommended approach today?
Would any of the macro-like initiatives make this easier in the future? Snap does wonderfully on the function-design side, I'm hoping to also teach data design with type-based design principles, akin to HtdP, with less overhead than today.
Yes, that's what you need. Depending on what algorithms you plan to use with trees the "etc." part would be mutators for the nodes.
You could avoid the need for type tags, if you want, by using the block. Then a leaf would just be a number (supposing you don't intend to mutate leaf nodes), and a branch node (in my dialect, a leaf is a node, and the distinction is leaf node vs. branch node) would just be a list. In effect you'd be using Snap!'s internal type tags as your type tags.
And yes, one of the things you could accomplish with macros once we have them is a Define Type block that would take a list of fields and generate the corresponding constructor, selectors, and mutators.
Could a single Define Type expand into a single (compound?) Snap form that included all constructors, accessors, predicates, etc? Any hint what that might look like?
Is v7 likely to have enough functionality for Define Type?
Define Type would carry out a bunch of definitions of custom blocks, so if you say Define Type cereal [Snap, Crackle, Pop] you get new blocks
make cereal, snap: %snap crackle: %crackle pop: %pop
Snap from cereal %cereal
Crackle from cereal %cereal
Pop from cereal %pop
cereal? %thing
and maybe (via a Boolean input to Define Type?)
replace Snap of cereal %cereal with %thing
replace Crackle of cereal %cereal with %thing
replace Pop of cereal %cereal with %thing
Lots of questions to answer, e.g., does this new type get a new palette category color? But, the thing is, Define Type would be defined entirely in user code, so if you don't like my version you can write your own! (Some flavor of user-defined categories will be in v7, for the benefit of extension writers.)
I'm interested enough in this that I might enter the source code rabbit hole ... any suggestion where I might start if I wanted to build a Define Type button? Also, which version / branch should I dig into?
block. Then a leaf would just be a number (supposing you don't intend to mutate leaf nodes), and a branch node (in my dialect, a leaf is a node, and the distinction is leaf node vs. branch node) would just be a list. In effect you'd be using Snap!'s internal type tags as your type tags.