Pass out more semantic info via visualization events

[wixette]

When implementing the first SeedLang+Unity demo I found that the client code would require more semantic info for every visualization event. Here are some examples:

1. For the AssignmentEvent, the only thing client can get is the name of the variable. How can the client code know the variable counter is in the global scope or the local function scope? How can the client code tell if the variable counter is a function parameter?

2. For the BinaryEvent, the client code can get the left value and the right value, but how can the client code know if the left value is retrieved from a local variable counter?

... ...

This issue is kind of related to the topic of the semantic tokens that are to be highlighted in the code editor. Probably for every visualizer event, we need to pass out an EventContext object to the visualizer. The EventContext may contain:

• The corresponding source code.
• The semantic parse result of the corresponding source code.
• The relationship (if SeedLang Runtime can figure out) between the semantic tokens in the source code and the event parameters such as left value, right value, variable name, etc.

Just some random thoughs.

[codingpotato]

I'm thinking about the design of visualization in SeedVM. Because only compiler has all the information visualizers need, all of them must be generated by the compiler and saved into the bytecode or chunk. After balancing the requirements and performance, the most promising design could be:

1. Introduce a opcode VISNOTIFY for all the visualizer notification.
2. If users register a certain notification event, the compiler will generate a VISNOTIFY opcode and the event information in the corresponding place of the chunk.

    Bytecode: [..., VISNOTIFY "index of event_info", ...]

    Event Information: [event_info 0, event_info 1, ...]

3. The event information could be a hierarchical classes like:

class EventInfo {
  Range range;
  TokenType[] types;      // Will it be too big to impact the performance?
}

class BinaryEventInfo: EventInfo {
  uint leftRegister;
  uint rightRegister;
  uint resultRegister;
  Operator op;             // Do we need this? Is it included in the EventInfo already?
}

class XXXEventInfo: EventInfo {
  ...
}

4. SeedVm could execute the VISNOTIFY opcode, collect all needed information, create the corresponding event, and send to visualizers.

By this design, it's possible to remove following design from current implementation:

1. Code range for each bytecode is not needed.
2. AST tree execution could be removed to reduce the maintenance works in the future, because the compiler has all the information in the AST tree, and can generate all the information we need for the visualizers.

[wixette]

1. Adding an opcode VISNOTIFY is good for the running performance of the bytecode. It requires that the code must be re-compiled every time the user updates the visualizer registry (e.g., adding a new visualizer or deleting an existing visualizer) - this is acceptable I guess.

2. As for the way how to manage the event info structure, doesn't it look like the management of the debugging info in the compiler/debugger toolchain? For example, can SeedLang's compiler define, generate and store a separate Visualization Infomation Section in parallel with the bytecode section into the output? The format of the Visualization Infomation Section can be a significantly simplified version of any one of the popular Debugging Info formats. for example (at least we can take them as references when designing XXXEventInfo structures):
   1 DWARF format
   2 STABS format
   3 Microsoft PDB format