Symbolic link names in Schemacode/Mindcode #284
Description
Update Schemacode and Mindcode to support symbolic link names. A symbolic link name would be used in Schemacode to label a given block and to link that block to one or more processors. In Mindcode the symbolic name would be used as a linked block name. When compiling Mindcode or Schemacode, the symbolic link names would be resolved to literal block names.
Benefits:
- Simplifies the management of linked blocks in large schematics, as the block can be assigned a symbolic name which can be consistently used in every source file. This makes it easier to copy or move code between processors too.
- Makes it possible for Schemacode to detect an unsatisfied link (a situation where Mindcode expects a certain symbolic block name which doesn't exist in the schematic).
Schemacode
A symbolic link name is a name that doesn't conform to the block name rules, e.g. baseController instead of processor1. Only valid Mindcode identifiers can be used for symbolic block names.
At most one symbolic name can be assigned to a block. Additional actual block names can also be assigned to make it easier to introduce symbolic link names into existing schematics.
Symbolic link names are resolved using these rules:
- Unused symbolic names are ignored with a warning.
- When a symbolic link name is used in a processor, Schemacode compiles the processor's code and uses the name of the block which was resolved during compilation. (A symbolic link name used in several processors can be resolved to different actual block name for each processor.)
- When a processor's code uses a symbolic link name which doesn't exist in the schematic, an error is generated (unsatisfied link).
- When a remote module is declared on a processor linked via symbolic link, Schemacode will ensure the code in the processor matches the remote module code. (This could actually be made for literal block names too.)
Mindcode
A symbolic link must be declared using the linked keyword:
linked @micro-processor var baseController, monoController, polyController;
linked processor2;
linked @memory-bank buildHistory, resourceHistory;
Note: the var keyword is optional.
When compiling the code, the literal block names within the source code are collected first. The symbolic names are then resolved to literal block names in the order of their appearance in the source code, while the literal block names, if any, are skipped.
The symbolic names would be resolved like this:
| Symbolic link | Literal link |
|---|---|
| baseController | processor1 |
| monoController | processor3 |
| polyController | processor4 |
| buildHistory | bank1 |
| resourceHistory | bank2 |
In relaxed syntax, it would be possible to use e.g. processor3 in the source code instead of monoController to enable or disable the processor, or to access its variables using read and write methods, but not to access remote variables or functions (unless they're declared on processor3, of course). In strict syntax, processor3 is not declared and using it would result in an error.
The information in the above table is passed on to the Schemacode builder, which uses it to generate the schematic.
Symbolic link names get resolved in the same way regardless of whether the Mindcode source is compiled separately or as part of the schematics. This allows to recompile and update a single processor code without necessarily having to recompile and update the whole schematics, at least for compatible changes. An incompatible change generally means adding new links.