by Theo Verelst, but feel free to add of course (lots of links could be add, for sure).
This page will not contain a script or bwise graph even starting to do what the title suggest for time to come, I'm sure, unless somebody feels called to do a job... The idea, which is important enough to even make more than one page about for mathematically shaded reasons, is that bwise blocks could replace every procedure and command in the script which implements bwise.
Clearly, the advantage would be a visual langauge rendered in it's own visual programming blocks, which is a strong idea, good for insight, portability and theoretical reasons.
Is that possible ? Well, in principle every procedure to begin with can even automatically be rendered as a bwise block with inputs corresponding to the formal procedure arguments. However using globals or uplevel spoils the general applicability of this idea to any tcl program containing procedures.
A script can be rendered as a row of sequential blocks standing for seperate or grouped tcl commands. That leaves the problem of feeding the global state to all those blocks, and the output of functional blocks (if they are that) back to the global state. Just like the state and behaviour of for instance fileevent and bind are hard to model exactly as bwise blocks.
Loops and control structures are possible, but for efficiency sake it may be very desirable to digress from strict functional analysis there, and include some sort of trigger mechanism like has been present but not often used yet in bwise.
Is there a major point to this? Certainly, programming with blocks is like making circuit diagrams, which is possibly a very succesfull design method, see the normal habits of electrical engineers which on average design and make work circuits and systems with incredibly higher complexity than most software engineers ever would attempt. also it is a clear way to communicate programmatic ideas, and can more easily be compared with theoretical programming issues like CSP and CCS and to the field of distributed (parallel) programming in practice.