You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
G. Franzkowiak asked (inspired by a no longer supported tool G.E.S.y bzw. WinG.E.S.y) for a way to allow users to configure code export for some new programming language from Structorizer.
At first, having had in mind the enormous efforts to implement and maintain the different code generators in Structorizer, this idea didn't seem feasible or even sensible.
But after having pondered the idea some time, and particularly after the hard work to implement #828 for the bunch of existing generators, and regarding the fact that the flowchart editor Flowgorithm successfully went this way by means of well-documented text-based configuration templates, I start to think different.
Of course, the configuration templates must provide cerain degree of complexity, particularly conditioned rules with many variables. The Flowgorithm templates show a way how this can be achieved. They seem to be a good start though the ones for Structiorizer would have to be still more complex as Structorizer provides way more syntactical freedom and more export modes (at least since #828 ...). This approach may not work for all languages (e.g. COBOL, lisp, or Smalltalk should hardly fit into a template model), but could facilitate both diversity and maintainability.
So certain export language may still require a completely coded or et least complementary generator class, but ideally for most export languages specific code generator classes would not be necessary any longer.
A prerequisite for the correct transformation of expressions (i.e. operators, built-in functions etc.) is of course a solution for issue #800, even if the syntax trees will not permanently be cached with the elements but only temporarily be derived for code export (though, regarding live code preview, a comparative performance analysis will be necessary anyway).
A detailed specification what configurable assets the templates would need to specify should be the next step here.
The text was updated successfully, but these errors were encountered:
G. Franzkowiak asked (inspired by a no longer supported tool G.E.S.y bzw. WinG.E.S.y) for a way to allow users to configure code export for some new programming language from Structorizer.
At first, having had in mind the enormous efforts to implement and maintain the different code generators in Structorizer, this idea didn't seem feasible or even sensible.
But after having pondered the idea some time, and particularly after the hard work to implement #828 for the bunch of existing generators, and regarding the fact that the flowchart editor Flowgorithm successfully went this way by means of well-documented text-based configuration templates, I start to think different.
Of course, the configuration templates must provide cerain degree of complexity, particularly conditioned rules with many variables. The Flowgorithm templates show a way how this can be achieved. They seem to be a good start though the ones for Structiorizer would have to be still more complex as Structorizer provides way more syntactical freedom and more export modes (at least since #828 ...). This approach may not work for all languages (e.g. COBOL, lisp, or Smalltalk should hardly fit into a template model), but could facilitate both diversity and maintainability.
So certain export language may still require a completely coded or et least complementary generator class, but ideally for most export languages specific code generator classes would not be necessary any longer.
A prerequisite for the correct transformation of expressions (i.e. operators, built-in functions etc.) is of course a solution for issue #800, even if the syntax trees will not permanently be cached with the elements but only temporarily be derived for code export (though, regarding live code preview, a comparative performance analysis will be necessary anyway).
A detailed specification what configurable assets the templates would need to specify should be the next step here.
The text was updated successfully, but these errors were encountered: