I4GL Modifications: Part 2 of 3

#!/bin/sh # this is part 2 of a multipart archive # do not concatenate these parts, unpack them in order with /bin/sh # file i4glmods continued # CurArch=2 if test ! -r s2_seq_.tmp then echo "Please unpack part 1 first!" exit 1; fi ( read Scheck if test "$Scheck" != $CurArch then echo "Please unpack part $Scheck next!" exit 1; else exit 0; fi ) < s2_seq_.tmp || exit 1 echo "x - Continuing file i4glmods" sed 's/^X//' << 'SHAR_EOF' >> i4glmods X containing problem records which are apparently out of sequence. The X program name has been placed on the second line, and so has the X function name where the error occurred. X XDate: 1993-01-21 15:57:41 GMT User: johnl TTY: /dev/console PID: 3129 XProgram: rrr.4go Error at "rrr.4gl", line number 7 in function "main". XFORMS statement error number -1110. XForm file not found X X I4GL-L23 was rated in class B because it is easy to fix. X XI4GL-L24: X It would be useful to have a bottom tested loop: X X REPEAT X <statements> X UNTIL <condition> X X Even C, a minimalist language, provides a bottom tested loop, because X there are times when the algorithm requires the loop body to be X executed once. X X I4GL-L24 was rated in class B because it should be easy to implement. X XI4GL-L25: X Because I4GL isn't like C, it is relatively difficult to write out a X FOREACH loop which needs a USING clause cleanly. I4GL-S01 fixes that, X but there are other places where a N-plus-a-half iteration loop would X be useful. The loop mght look like: X X DO X FETCH c_cursor INTO varlist.* X WHILE STATUS = 0 X OUTPUT TO REPORT r_report(varlist.*) X END DO X X If we adding loops to I4GL, then maybe an UNTIL/END UNTIL loop X and a DO/UNTIL/END DO loop are both appropriate too. X X I4GL-L25 was rated in class C because it is not provided by any other X language (though Ada and PL/I get close). X XI4GL-L26: X The underlying representation of DATE variables is an integer type, but X you cannot loop over the days between two dates unless you use a X circumlocution like the code below. I4GL should allow the use of a X DATE variable as the index of a FOR loop. X X MAIN X X DEFINE X d, d1, d2 DATE, X i, j, k INTEGER X X LET d1 = MDY(01, 01, 1993) X LET d2 = MDY(01, 31, 1993) X X LET i = d1 X LET j = d2 X FOR k = i TO j X LET d = DATE(k) X DISPLAY "Date: ", d USING "ddd dd mmm yyyy" AT 3, 1 X SLEEP 1 X END FOR X X END MAIN X X Incidentally, it would be useful if there was an explicit coercion X function called INTEGER to coerce a DATE into an INTEGER. The X statement: LET j = INTEGER(d2) is clearer documentation of the fact X that something slightly peculiar is going on. X X I4GL-L26 was rated in class A because it is should be easy to fix. X XI4GL-L27: X The mapping of function keys to purposes needs to be less direct. This X is so that when the customer decides that the help key should no longer X be the key labelled HELP but the key labelled F1, the mapping can be X done in software, preferably without either recompiling the software or X rewriting the termcap/terminfo entry so it is a bundle of fibs. If X recompilation is forced on us, at least using a bunch of macro names X such as KEY_HELP, KEY_ACCEPT, KEY_QUIT, etc. allows the mapping to be X altered by simply changing the central header file which defines these X mappings (I4GL-L16). Then, of course, the vastly upgraded programmers X environment (I4GL-T05) can be told to recompile all the software X affected by the change, and at least everything is consistent. If the X source would have to be edited instead, then it becomes simpler to lie X through your teeth by rewriting the termcap entry so that the key X defined as k0 (F1 in I4GL parlance, F10 anywhere else) is deemed to X produce the sequence associated the key labelled F6 because the help X key in the source code was assumed to be F1 (and the source is X unchanged) but the users now hit the key labelled F6 instead. X X I4GL-L27 was rated in class C because it is can be largely fixed by X other requests, such as I4GL-L28, I4GL-L16. X XI4GL-L28: X Cursors, windows, forms, colour attributes, key names, field names X should all be treated as proper variables. This would simplify many X operations. For example, one of the systems I was working on recently X had a requirement for a screen array where the entries in the screen X array needed to be of different lengths depending on the amount of X information to be shown for the entry. It is not sensible to try X upgrading INPUT ARRAY to handle that, but an ARRAY[8] OF WINDOW would X have simplified a lot of coding, as would the ability to use DISPLAY X Forty_odd_fields.* TO s_record.* ATTRIBUTE(attr_var) where attr_var was X a colour attribute variable holding either REVERSE or NORMAL. Maybe X the forms weren't designed correctly (and, once more, time was of the X essence), but using the 4.10 OPTIONS DISPLAY ATTRIBUTE (NORMAL) didn't X do what was required, which was to override the colours in the form. X X This change is fundamental to a number of the changes in the sections on X handling forms, windows, INPUT, DISPLAY ARRAY and INPUT ARRAY. X X I4GL-L28 was rated in class C because it is important but difficult to X do properly. X XI4GL-L29: X There should be a mechanism which allows a user to define symbolic X constants. This can either be provided by the preprocessor facility X (I4GL-L16) or by a constant declaration. Either way, it is crucial X that the constant value can be computed from other constants if need X be, so that two arrays can declared, one with size N and the other with X size 2*N, and when N changes, only that constant definition has to be X altered. Bear in mind that the constants may be defined in different X source files, using a common header file which contains the definition X of N. If computed constants cannot be handled in declarations, then X the preprocessor must provide a mechanism to evaluate an expression on X demand (as in the M4 macro processor). X X With the ability to pass arrays around (I4GL-L03), it would be helpful X if I4GL provided a function such as dimensionof() to determine the X number of elements in an array. If generic sorting routines (analogous X to qsort(3) are to be written, then it is necessary to have a function X analogous to sizeof(), and offsetof() might not go amiss while were at X it. These would be of little direct relevance to the I4GL programmer, X but would make the interface to C routines simpler in certain contexts. X X I4GL-L29 was rated in class A because the constant facility would simplify@@NL@