fesch / Structorizer.Desktop

Structorizer is a little tool which you can use to create Nassi-Schneiderman Diagrams (NSD).
https://structorizer.fisch.lu
GNU General Public License v3.0
65 stars 20 forks source link

IF ELSE IF chains can (and should) also be implemented for code export to other languages (like the C family) #1148

Closed codemanyak closed 8 months ago

codemanyak commented 8 months ago

OBERON export Bug was fixed: grafik

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.: grafik

codemanyak commented 8 months ago

Implemented for version 3.32-19 (most languages, i.e., C, C++, C#, Java, Javascript, modern BASIC, Perl, PHP).

codemanyak commented 7 months ago

Implementation of optimised code export for IF ELSE IF chains added to Pascal and Python generators (ready for version 3.32-20).

GitMensch commented 7 months ago

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

?

codemanyak commented 7 months ago

@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.

GitMensch commented 7 months ago

@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...

codemanyak commented 7 months ago

@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-IFs 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 IFs in a series might already be sufficient to switch to EVALUATE.

codemanyak commented 7 months ago

I prepared the implementation in the draft COBOL generator with an else-if threshold of 2 now: grafik

grafik

GitMensch commented 6 months ago

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.]

codemanyak commented 6 months ago

@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.