BASH-Code-Generator - improvement

[reks99]

Hi,

When export the nsd I get the follwing code:

# !/bin/bash

COUNTER=0

while [[ ( ${COUNTER} < 10) ]]
do
 echo ${COUNTER}
 (( ${COUNTER}++ ))
done

This script will run, if the comparison operator is changed to "-lt" (because it is a number) instead of "<" and the variable COUNTER will be increased correct, if the dollar sign and the curly brackets before the "++"-operator are removed (in line 14),

Is it possible, to modify the code generator that way?

Fine regards Rolf

[codemanyak]

Hi Rolf, there are some circumstances making the requested changes rather difficult:

1. Comparison operator: The generator would have to analyse the operands for their type. In certain uncomplicated cases this might succeed (in the example, the occurrence of the integer literal 10 could trigger this) but with complex expressions or involved variables this is bound to be hopeless.
2. Increment operator: The occurrence of an increment operator might be a strong argument to assume that COUNTER is meant to be an integer. Unfortunately, Structorizer (Executor in particular) does not accept autoincrement and autodecrement operators. So why should the generator be aware of them?

The worlds of HLLs and shell languages are too different to find a "correct" way of translation while the syntactic restrictions for the Structorizer elements are kept as loose as possible, I am afraid. If the algorithm had used a (counting) FOR loop instead, then chances would be better to obtain a working result from the code generation.

[reks99]

Hi Kay,

thanks for your fast reply.

About the comparison: If one of the arguments is a number, the operators should be -gt or -lt or... If unsure, set the variable in quotes and the value as well, then the operators for textual comparison can be used; so: if [ "${COUNTER}" < "10"} ] will usually work also.

As you can see in the nsd I only used the HLL - as far as I understood it - and there is no autoincrement written by me. It was generated from structurizer. I usually do not use autoincrement outside of C programs. May be another expression for shell mathematics can be used - for example (COUNTER=$COUNTER+1) - so no autoincrement or autodecrement operators are needed.

Fine regards Rolf

[codemanyak]

Thanks for your proposals. I will consider them though this kind of heuristic guesswork will take more time for testing than I currently can spend. You are right, the Structorizer content was C++-like HLL (though not executable because of the ++ operator). If you had written COUNTER := COUNTER + 1 it would have produced a code more likely to be usable in bash. From my point of view, Structorizer is not responsible to translate any imaginable expression if it is (by design!) not supported e.g. by the Executor component. So I will hardly do anything about ++ or --. I won't have to tell you that the lexicographic comparison is of no help in arithmetic context: [ "${COUNTER}" < "10" ] will of course fail to control the loop since "2" > "10". If there are only two simple operands then of course one numerical literal may trigger a conversion to either [[ ${COUNTER} -lt 10 ]] or (( ${COUNTER} < 10 )) which would also work. But what to do in cases like COUNTER < abs(8) or SOMETHING < ("funny" + 7)? You and me see what these expressions mean but how to decide this by a simple algorithm? An analysis of expression structures, functions, function arguments etc. would be required. This is what I'm talking about when I say it's difficult, in particular as Structorizer has no exact grammar. The Executor is privileged as it knows the current values of variables on interpreting. The generators don't. They can only guess. This is about heuristics and probabilities and hence hardly feasible by a simple tool not using artificial intelligence. I hope you understand that I hesitate to spoil the coming release 3.25 with a quick hack, which is likely to cause more harm than it mends. The BASH generator already contains several quick hacks and vague rules. So I prefer to have more time to consider possible ways to improve the generator.

[codemanyak]

With the static variable type retrieval approach in 3.26-02, we get a little closer to a more intelligent support for shell script export. What's needed next is a full expression parser capable of deducing type information along the syntax tree. This will also help to overcome the many makeshift approaches using tokens or regular expressions to derive meaningful information from the element texts. This will be addressed by means of issue #800.