Programming with visual / blockly languages (scratch, makecode, etc) is quite common in the young ages. A more intuitive approach to this kind of programming is the creation of many threads/scenarios that communicate through messages. Yet, in many cases the resulting flow is tricky to follow, but very useful from an educational perspective. We will make a tool to reveal this flow, mainly the inter-thread communication. The input programming language will be processed as json structures, that could fold and unfold in the visualization. Communication among different threads and components will be shown explicitly. Different visualization methods will be available, that will fit to many programming languages.
The primary flow is, in most cases, the set of threads that run concurrently. In python we can create threads, but this is not very common. We usually start only main.
Other languages, like MIT scratch are based on threads. Every object has its own threads (called scenarios), that start with When ... events (with a variety of sources (such as the keyboard, the mouse or other devices). Any program can additionally broadcast messages to initiate more threads that start with When I receive message X, and sometimes it will wait for their return (broadcast message X and wait). Each event or message can initiate many concurrent threads. This is the flow that I consider primary, and we should start from that.
The MIT scratch demonstrates such a programming style, and is a good example for the possible input.
The actual scratch code is stored in json (inside a zip file), which make the parsing code easier, and we can concentrate on the visualization.
The visualization can be a graph, or a some text-based layout (with pieces of code and the appropriate edges with arrows). We can use a graph tool / library to handle the graph layout issues.
One such visualization in common use is codeOrama. The codeOrama is often used to provide a higher level of code description, but it is constructed manually. The idea is to make a tool to create codeOramas (as export / printing operation).
Here are also some output examples - there is more material, but it is in Greek. Nevertheless, the output layout of codeOramas is quite clear. Our output does not have to be the same, but has to be beautiful and clear.
Here are some implementation ideas / discussion.
When the primary flow is trivial, or when we are focusing on smaller pieces of code (or when using an interactively tool), we can display / focus on the secondary flow: code flow that is already serialized, where we can demonstrate the loops and conditionals.
The proposal will specify the implementation language, environment, ...