Kay Gürtzig

I wrote in https://github.com/fesch/Structorizer.Desktop/issues/1087#issuecomment-1716632402: > It seems to be a sensible way ... It will be an important decision whether to transform all representable defined stuff from the header files...

Again. Try this:  or this:  The diagram is not forced to use `argc` or `argv` but you can provide it. If you don't want to provide arguments then...

Well, the implementation turns out to be more complex than initially assumed, at least if the existing code is not to be rewritten completely. So it will reqire a deeper...

Ah, sorry, now I understand. You propose a kind of built-in function that provides the array of command-line arguments (or alternatively, two such functions, one returning the number of arguments,...

> it would be even more useful if he added a clear documentation how to do so That's certainly the right thing to do. In order to be able to...

> There is no "template" as such, but you could just take on of the existing generator classes, make a copy and adapt it. @mmeiborg There had been a proposal...

I think, one of the major challenges is that most of the interesting mathematical stuff for Octave / Matlab is not directly expressible in Structorizer. Not at least in a...

The discussion will have to keep in mind at least these issues: #61, #113, #335, #368, #408, #423, #739, #800. As Structorizer does not require declaration except in the case...

In an analogy to some Pascal distributions and Oberon we might indeed think of a modified semantics of declarations in future Structorizer versions, particularly for arrays: - An *undeclared* variable...

In addition, we will have to decide whether it is desirable and feasible also to accept declarations in C and/or Java style (then with or without `var` prefix?), particularly, as...