but these are different problems:
- macros for diagrams, n-bit-adder for any n - "boxing up" diagrams, or some sort of nesting of diagrams - management of state
there are separated concepts in our tool, macros are a 'meta language', in principle one can write functions in the host language that generate diagrams and then proof that those diagrams are well behaved in some way. there is theory on how to do this for diagrams, but we have not implemented any of this yet
boxing up is a natural operation of the system; we get that for free sort of
state is handled by folding functions over the history, so you get a nice and clean way of dealing with state
but you are right, this ability is very important; it is a lot harder to do tho, but it's possible now I think
For example, each module in an audio program you're wiring together is basically a function with a ton of internal state. But you also need to be able to create your own modules composed of other modules, and maybe some lower level functions, e.g. EQ, signal sources, delay/reverb, etc.
The only visual system I've used is GNU Radio, which requires XML/Python/C++ to create your own blocks AFAICT.