grammarware / software-evolution

Software Evolution
MIT License
1 stars 0 forks source link

The usage of GIVING #11

Open LastAdequateCoder opened 7 months ago

LastAdequateCoder commented 7 months ago

In basic operations such as ADD, DIVIDE and etc. there is a way to store the result in the variable defined by GIVING clause. However, this clause does not contain the picture, therefore it is not really clear what to do when this variable appears. For example: ... ADD 1 TO 2 GIVING e. ADD 3 TO e. // This crashes, because picture for e is not defined ...

Is this a legal way of writing code in cobol?

grammarware commented 7 months ago

First of all, it is quite possible in both COBOL and BabyCobol to first define this e in the DATA DIVISION (with a detailed PICTURE clause), and only then use it somewhere in the PROCEDURE DIVISION in a GIVING clause. In compiler construction, the usual way to get that PICTURE (commonly referred to as "type") at the moment of usage of e is called a "symbol table".

Specifically in BabyCobol (and in REXX, and in some 4GLs), you do not have to declare a variable/field in the DATA DIVISION in order to use it, since all "undefined" ones are considered implicitly defined. The default value is the name of the field in uppercase (so "E" in this case), and the corresponding type is PICTURE IS X(N), where N is the length of the field name (in this case, one). So ADD 1 TO 2 GIVING e will define e (or E) with a default value that nobody cares about, and assigns 3 to it. However, ADD 9 TO 9 GIVING e will attempt to basically MOVE the result (18) into something of type PICTURE IS X, which means it will get only 1 (for decimals, the truncation/overflows happens on the left and the highest meaning digits are lost, and for strings on the right and only the leftmost characters are used).

LastAdequateCoder commented 7 months ago

For all the mathematic operations such as ADD and others the site defines such rules:

any of the three arguments can be an identifier defined with a numeric picture clause (free from A and X)

Will this not mean that if the E is defined by GIVING and the type as you said is PICTURE IS X(N) then this variable can not be used in any other mathematical operations, because its type is not defined by a numeric picture clause? So once I write ADD 1 TO 2 GIVING E and E is not defined in the Data division, E will have type PICTURE IS X and could not be further used for mathematic operations?

grammarware commented 7 months ago

Yes, that is correct. All numeric picture clauses should be explicit in the DATA DIVISION.

MrDurion commented 7 months ago

Hi, I would like to hook into this:

Specifically in BabyCobol (and in REXX, and in some 4GLs), you do not have to declare a variable/field in the DATA DIVISION in order to use it, since all "undefined" ones are considered implicitly defined. The default value is the name of the field in uppercase (so "E" in this case), and the corresponding type is PICTURE IS X(N), where N is the length of the field name (in this case, one).

When you define the E 'during' the procedure division like this, is it possible to use it again later, and if so, can it still be used as a numeric value?

The picture is now X(N), meaning it is a variable with a non-numeric content, and normal cobol does not allow you to use non-numeric variables in statements like ADD.

grammarware commented 7 months ago

Indeed! Once anything is an X, its use in arithmetic expressions is limited: you can still MOVE numeric values there (and do all things that are similar to it, like GIVING clauses), but as a source it would pretty much be regarded as a string.

FORTRAN is a language which has extensive rules for implicit variable declarations, up to having "explicit implicits" when in the beginning of your program you say IMPLICIT INTEGER (X-Z) and then all undefined variables starting with X, Y or Z will be implicitly declared as integers. There are also "implicit implicits", which are the same kinds of rules just not explicitly written out — one of them is IMPLICIT REAL (A-Z) which means that starting with any other letter will define the implicit variable as real. Goes without saying, this can get insanely complicated, which is one of the reasons that BabyCobol does not have that. If you want a fancy picture clause, define it in the data division; otherwise you're stuck with Xs.