Structorizer.Desktop icon indicating copy to clipboard operation
Structorizer.Desktop copied to clipboard

executor ignores variable types

Open GitMensch opened this issue 8 years ago • 4 comments

I've just executed techtonics from worldcities2 COBOL import:

grafik

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

grafik

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:

grafik

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 the NumberFormatException and 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?

GitMensch avatar May 18 '17 08:05 GitMensch

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.

codemanyak avatar May 18 '17 10:05 codemanyak

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.

codemanyak avatar May 18 '17 10:05 codemanyak

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:

codemanyak avatar May 18 '17 19:05 codemanyak

This will not be addressed before #800.

codemanyak avatar Apr 24 '20 18:04 codemanyak