Proposal: "Variable registry" and "Data type configurator"

[codemanyak]

Structorizer tolerates (or accepts) certain kinds of type declaration in e. g. assignment instructions but doesn't actually make much use of them. Some code generators even try to transform detected implicit type associations into the target language, including some heuristic type name translations.

I'm thinking about an additional feature for Structorizer (for a later release) allowing to display and configure the parameters and local variables found in a diagram in combination with static type associations. It might look like this (first rough sketch):

Next to the variable name there would be static information about its type - either as parsed from the soubroutine header / the introducing instruction and thus not editable here or as entered in this very table field and hence editable - then the number of modifying elements (e. g. input or assignment instructions or FOR loop headers) and the number of elements merely referencing its value. Possibly there might be further columns, e.g. to indicate conflicting re-declarations of parameters or other variables.

Possible interactive functions:

• The name field might be editable, a name change here would refactor the variable name troughout the diagram, where name collisions could be tested before. The colour of the name field would allow to distinguish among subroutine parameters and local variables, where parameters would always stay at the top of the table.
• A click on the "Name" column header might sort the parameter names and the remaining variable names, each ones within their group, lexicographically upwards or downwards.
• The "Type" field might be edited if the type isn't derived from an element. The colour of the type description (or its background) might indicate editability. Clicking on a non-editable type field should select the element specifying the displayed type (usually an assignment), double-clicking should open it in the editor.
• The count fields (number of modifying elements and number of referencing elements) might be associated with a pull-down list presenting the respective elements by rows, each consisting of the element type symbol and the beginning of its first text line (similar to collapsed elements in the figure below but just using one single line each). Clicking an element row could select the element in the diagram, double-clicking should open its editor. Clicking on the count field itself might temporarily highlight all associated elements in the diagram in a specific colour.
• A click on the header of one of the columns "Modifications" or "Reference" might try to sort the table rows (variables) by the y coordinate of the elements of their first occurrance in the diagram (i.e. the y coordinate of the elements top border). This is a non-trivial and ambiguous order relation, of course, and not necessarily intuitive.
• The "Array" column is a desperate approach to indicate whether a variable was subject to indexed assignments or if there is an array declaration, e.g. in the parameter list. This is a weak point, because often we can only guess. Arrays may be passed through a subroutine completely undetected. All the more, a difficulty would be to keep track of nested data structures (i.e. arrays, as these are the only actually supported data structures by now). The alternative approach to provide verbal type specifications like "array of real" is also lacking functionality inasmuch as there might be an obvious indexed assignment but no clue what kind of elements are assigned. So which part of the type specification array of ? should now be editable? And how?

The type information configured in this table would have to be permanently mapped to the variable names by the Root element. It should then be used to generate declaration areas for those target languages using them on code export. Conversely, the Pascal import should no longer ignore the variable declaration but fill the variable map, such that it can be displayed and continued after he import. If the Executor should react to discrepancies between a statically associated type and drastically differing type on execution might be up to configuration. There might also be a new Diagarm display mode letting the Root element show the information of the first two or three columns as a variable declaration list below its name or header, preferrably in Pascal syntax, i. e. <var_name>: <type_specification>

So, well, these are just my thoughts, open for discussion.

[codemanyak]

A challenge would also be to synchronise the table on editing the diagram under the aspect of the undo/redo mechanism, particularly on removing elements holding the last reference to a variable for which there is manually added type information. Another risk is that all this extra functionality tends to slow down the Structorizer significantly.

[codemanyak]

As in many languages (like C or Pascal), arrays are expected to be dimensioned with a size or index range, a simple checkbox in the Array column will certainly be too poor. Maybe, a positive integer (size i.e. number of elements) or a range (like 1 .. 15) might have to be specified to form an array type with fixed size, also to reflect some parsed array specifications, thus addressing #113 as well. On the other hand, the Executor rather works with dynamically growing arrays, which requires some flexible collection type or template like Vector in Java, C++ etc. on implementation / code export. The type specifications here are rather relevant for code export than for Executor, of course, but if the algorithm itself relies on dynamically growing arrays then a code export assuming fixed-size array would hardly result in somethimg sensible. Hence, a useful design of this "variable configurator" is anything but trivial and needs a clear definition of the requirements to be met.

[codemanyak]

Well, this GUI idea has neither been fixed nor discarded entirely. The part of the issue that had indeed been implemented was an internal type tracking. A solution for #800 is assumed to make the type tracking more powerful and to become a better basis for some graphical data structuring aid as proposed here. So I reopen it.

[codemanyak]

It will make more sense to provide some kind of data type construction tool (type definition assistent), where a type may be formed as record (struct) of components of already registered types, as array over an existing type, as enumeration type, as type alias, or as reference (pointer) type via choice lists, thus deriving the syntactic representation of a type definition from an assisted GUI composition. This might also be used for declaring variables with (basic, user-defined, or anonymous ad-hoc structured) types.

[codemanyak]

Interestingly, the slightly context-sensitive auto-complete mechanism implemented for #1066 has brought us a little closer to the aim of this issue, though on a totally different way:

But it is not of course a game changer or would make this issue redundant. The auto-complete assist only offers the available names (type names where they are expected and variable names else) and doesn't give any visual interpretation or introspection.

Just a remark.