The reason for semicolon on /Free specs?
|
Q: Why didn't you listen to the many lone voices about that stupid semicolon on /Free
specs?
A: You really want me to dredge up the logic behind that decision yet again? OK, here
goes. But first some history:
Back prior to V5R1, we had an enhancement survey where one of the items to be voted on
was free-form calcs. We thought at the time that it would be a big effort, and so a price tag
of $100 was given to it. In spite of the high cost, some voters actually blew their whole wad
on it! After thinking a bit more about the issue, I realised that the cost didn't have to be
that much, especially considering we really didn't have to worry anymore about some things
like conditioning indicators, resulting indicators, and definition of variables on the calc spec.
By V4R4, these things were generally considered to be bad style anyways. The issue of
multi-part factors remained, but that issue disappeared when we decided that the opcodes
that used multi-part factors could be replaced by existing or new built-in functions.
At this point, the implementation became much easier. The arguments are parsed and the
information about them placed into the same variables used to process them as if they were
coded on fixed-form calcs.
The biggest work in fact was implementing a new set of built-in functions to handle certain
opcodes that would not be allowed in free-form calcs, like LOOKUP, SCAN, and XLATE, as well
as the date/time/timestamp operations. But voters indicated that they wanted many of these
anyways, even without free-form calcs.
Then came the matter of syntax. At first, the design indicated free-form calcs with characters
CX in positions 6-7, with C+ indicating continuation. Later the CX was changed to CF, but the
principle remained the same. This was almost universally panned by RPG programmers, and
eventually we decided this had to be changed. At that time, I was working on another project,
but I was dragged back early to the RPG development team to change the design before it was
too late for V5R1.
So first, we decided that positions 6-7 of the free-form calc spec had to be blank. Then we had
to deal with the issue of continued statements.
But before we go further, here's one general principle in RPG language design: Since RPG runs
primarily on EBCDIC machines, and since various EBCDIC codepages have different code points
for different characters, the RPG character set is necessarily limited. That is, if for instance
we decided on the backslash as having a particular meaning in RPG, there may well be problems
in moving to different code pages.
So the question is: continuation character or end of statement delimiter?
The RPG language already had umpteen different styles of continuation. For instance, character
literals had two different styles of continuation, and numeric literals had their own different
style. We didn't want to use either '+' or '-' to indicate continuation since those would be too
easily confused with character literal continuation, as well as the binary addition, subtraction,
and catenation operators. Beyond those, there weren't really many good alternatives in the
available invariant EBCDIC characters. And besides, we didn't really want to introduce yet
another style of continuation.
Consider how continuation was already expressed in the Keywords entries and the
Extended-Factor-2 entry. No special continuation character was needed in those entries, since
continuation was indicated by blanks at the beginning of the continued spec. We felt that the
precedent of no continuation character was reasonable for the free-form calcs as well. Then,
the decision to select the semi-colon as the end of statement delimiter was a no-brainer, since
it was already very commonly used for that purpose.
The next decision was this: Was the end of statement delimiter needed for all calcs? That is,
in some languages, a semi-colon is not needed after some keywords, like ELSE. We decided
that the simplest rule to remember was that the semi-colon was needed after each and every
opcode. Thus, no exceptions to remember.
In conclusion, we certainly do appreciate that not everyone likes the choice of statement
delimiter style of free-form coding. (Practically all new things in the language have both fans
and detracters!) But hopefully, you now have some understanding of the process that led to
this particular design decision.
Thanks to Hans Boldt
|