executor ignores variable types
I've just executed techtonics from worldcities2 COBOL import:

As it has two parameters these are asked to be entered first (which is perfect):

In general this works fine but the type of the variable is guessed based on the input, not on the type in the var declaration. If I enter my file name as 1 the variable is an int:

I suggest the following for the executor:
- if the type of the var is a string: add
+ ""to get the implicit string conversion - for all other types: use the wrapper classes like
var = Float.parseFloat(content), catch theNumberFormatExceptionand return an error message
Actually I've just tried to fix this and add a merge request, but the debugging ended in the Executor using setVarRaw which checks the type of the rawInput after finding/adding the name from/to the list of variables/constants.
Therefore it would "just" mean to get the type of the variable/constant from these lists and only derive it from input if it isn't set - but I found no type stored in the variable/constant list. Did I miss something?
The (partial) type analysis and declaration support has come much later than the raw input evaluation. Therefore this temporary inconsistence. Thanks for the issue. I will consider it.
I would like to add that on assignments the data type isn't actually checked, either. Traditionally, the Executor has always allowed "re-typing" like in an untyped language: An instruction sequence like
a <- 17
a <- "nonsense"
a <- {23, "heterogenous", false}
is not illegal in Structorizer. B.t.w. this makes type retrieval so difficult and vague. It's always possible to find contradicting type associations, and on input instructions, nearly anything could be obtained (such that type prediction gets impossible). So it should possibly be an option to enforce type control (as already mentioned in the vague proposal #259 I postponed.) I would postpone this to a later milestone.
For the time being: If you know what value type is expected on input, you could simply type it in with an unambiguous literal syntax, e.g. "1" instead of 1 - and the rawInput value parsing will honour it. :wink:
This will not be addressed before #800.