Closed codemanyak closed 8 months ago
Implemented for version 3.32-19 (most languages, i.e., C, C++, C#, Java, Javascript, modern BASIC, Perl, PHP).
Implementation of optimised code export for IF ELSE IF chains added to Pascal and Python generators (ready for version 3.32-20).
I do wonder if the code export for COBOL should use:
EVALUATE TRUE
WHEN number > 3
code
WHEN number > 2
code
WHEN number > 0
code
WHEN OTHER
code
END-EVALUATE
?
@GitMensch
I do wonder if the code export for COBOL should use:
Hi Simon! It looks plausible and optically close to IF cond1 ... ELSE IF cond2 ..,, albeit somewhat ugly (for a non-COBOL-afficionado). And it's not as straightforward to implement as for other languages where a simple loop can be used to insert as many ELSIF clauses as the nesting of Alternatives allows. Here we must do a fundamental decision between nested IF and EVALUATE in advance. It is of course feasible but not as elegant as for "usual" programming languages. Maybe, an export option should be introduced for COBOL to decide whether this translation is to be preferred where possible.
@codemanyak
An output setting makes this even more complicated (for not much benefit), no? So I'd suggest to not add the option. But I do see the point of "needs a decision up front". Maybe put that on the backlist then...
@GitMensch I am not quite sure whether we could simply provide a modified formatting of the IF ELSE IF chain in COBOL to reduce nesting and indentation level:
IF (number > 3)
THEN
code
ELSE IF (number > 2)
THEN
code
ELSE IF (number > 0)
THEN
code
ELSE
code
END-IF
END-IF
END-IF
But the sequence of END-IF
s here is of course awkward. So, for COBOL programmers, the EVALUATE
construct might really be preferrable. It is just that we might specify a minimum Alternative chain length for conversion to EVALUATE
rather than nested IF
. The example above suggests that 2 ELSE IF
s in a series might already be sufficient to switch to EVALUATE
.
I prepared the implementation in the draft COBOL generator with an else-if threshold of 2 now:
That looks good and can be un-drafted.
I just wonder what happened to the export, I've thought we had simple assignments (MOVE var/lit TO var
) and possibly user input/output data (ACCEPT var
, DISPLAY var
) implemented back then.
... but maybe that was just the import.
[Note: I guess the CODE SECTION.
is intended to be output directly before the first instruction, not after every one.]
@GitMensch
[...] I just wonder what happened to the export, I've thought we had simple assignments (
MOVE var/lit TO var
) and possibly user input/output data (ACCEPT var
,DISPLAY var
) implemented back then. ... but maybe that was just the import.
Yes, it was just the import. The export still has some substantial deficiencies I became aware of on this occasion. The decomposition of general (mixed-type) expressions in instructions still remains a problem. I have to push forward the #800 redesign because this appears to be the clue for a sensible analysis.
[Note: I guess the
CODE SECTION.
is intended to be output directly before the first instruction, not after every one.]
I will have a look at it.
OBERON export Bug was fixed:
Originally posted by @codemanyak in https://github.com/fesch/Structorizer.Desktop/issues/1146#issuecomment-2005219412
This improvement should also be applied to other languages which support it somehow (though not with a special keyword), e. g. C, C++, C#, Java, etc.: