Re: /FREE RPG compiler errors

Comments in line.


> Pure free-format is not necessarily "better" than fixed-format.  There are
> some things better, some not.  And it *IS* an opinion.  Replacing:
> 
>    MOVE A    B
> 
> with
> 
>    eval %subst(b : 2 : 2) = %editc(a : 'X');
> 
> is NOT better, in my opinion.  I don't care how readable it is to a C
> programmer, I care how readable it is to an RPG programmer, and the former
> is more readable, and a lot easier to code.  This is where the opinion bit
> comes in.

First: Even if one accepts that the Move statement is better, there is
no correlation as to which I caof the two forms, in their entirety, is
better. It is completely possible for X to be better than Y, even if
subcomponent Y1 is better than the corresponding X1 subcomponent. And,
in this case, even if you accept that Move is preferrable, the other
benefits of free-format far outweigh the merits of Move, hence it is a
better language.

Second: Easier to read? Come on. Your own code here makes my point. Let
me look at both lines of code and tell you what I can determine.

For

    Move    A        B

All I can tell you is that some bytes of A are being copied into B.

Q: What is A?
A: I don't have a clue. Is it a field, numeric, character, indicator? Is
it an array? Is it a named data structure?

Q: What is B?
A: This question looks familiar.

And, if there are changes to the attributes of A or B (e.g., lengths,
number of elements in an array), it is quite likely that this line of
code will no longer function as intended.

Now, for

    %Subst( B : 2 : 2 ) = %EditC( A : 'X' ) ;

the intent is FAR more obvious. I can tell you that B is a string and I
am replacing bytes 2 and 3 of string B with 2 bytes from the resulkt of
applying the X edit code to numeric field A. If I always want the
information in bytes 2 and 3 of string B and the field length of A or B
changes, it is of no consequence. Not true for the Move.

Easier to code? So, the point is that fixed-format RPG is better because
Move is easier to code, even though it is far more likely to break given
changes and impossible to determine EXACTLY what it's doing without
looking at the lengths of the operands and remembering the various rules
of Move with respect to different items. Compound this with a series a
Moves to construct a final field value and the lunacy simply escalates.
But, I'll give you this - it's certainly easy to believe this is easier.

> 
> Now, most of my objections would go away if they'd just allow some
> transitionary syntax.
> 
>    eval %move(a : b)
>    eval %movel(a : b)
> 
> If those were acceptable, I'd be far more likely to embrace the language,
> and there's no reason not to support them.

Yes, there are reasons not to support them and I just went over them a
little. Move is simply non-intuitive, potentially difficult to maintain,
and easy to break. I suspect that the compiler writers might have been
thinking along those lines when the decision was made not to include
Move support.