Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

User-configurable template-based code export? #850

Open
codemanyak opened this issue Apr 19, 2020 · 0 comments
Open

User-configurable template-based code export? #850

codemanyak opened this issue Apr 19, 2020 · 0 comments

Comments

@codemanyak
Copy link
Collaborator

codemanyak commented Apr 19, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant