Re: What the compiler does, or not? -- RPG400-L

Joe,

>I'll respond, but this is it.  

Likewise, I'll bow out here, but not until I get the last word in. <g>

>>%editc() is just a valid in fixed format code as with free format,

>This isn't about being an RPG programmer, Doug.  According to Hans, it's
>about clarity, 

You're the one saying %editc() "is not clear to anyone who doesn't understand
... the syntax of RPG BIF calls".   I'm saying if they *don't* clearly
understand the syntax of BIFs, they may be a RPG III programmer but they sure
aren't a RPG IV programer yet.

>and especially clarity to non-RPG programmers.  THAT'S WHY
>THEY TOOK AWAY THE MOVE.  

They took away Move, in my opinion, because it is ambigous -- not to the
compiler but to the maintenance programmer.  MOVE is not like an overloaded
procedure performing the end result but with varying data types (eg, being able
to pass a date as either a date type field or a numeric field with a valid date
then doing some date related operation).

Instead MOVE performs fundatmentally different things depending on the data
types and lengths of the operands and result field.  You CANNOT know how the
result field will change without knowing that.  Looking at the statement itself
will not tell you what it does.  Using BIFs do, whether %subst() or %editc() or
whatever.  The types and sizes of the operand and result do not affect what
operation is performed.

Thus you only have to know the language syntax and you can accurately assess
what a statement does in a program you've never seen before (or in a long time)
even if it uses fields you are not intmately familiar with.

>> you still look at a reference manual to see
>> what various edit codes mean ???
>
>Absolutely.  I don't have space in my head for trivia, 

Those aren't trivia.  They are a fundamental part of very commonly used output
whether printed or displayed.  I can't believe you could have used them this
long and NOT have them memorized by now.  Not necessarily because you set out to
commit them to memory, but by virtue of having looked them up so often.

>My guess is very few programmers know all the edit codes.

Yikes!  I sure hope not, except for programmers new to RPG (or DDS).

>What is self-evident about it?  Without KNOWING what %editc does, you have
>no idea.  

Every RPG programmer should KNOW what every BIF does.  There aren't that many of
them!  And I have a hard time believing it is harder to recognize %editc stands
for edit code then to know the nuances of the move operation.

>And if you do know what %editc does, you have no idea whether the
>field is binary, zoned, packed, or what.  No idea on size, no idea on
>decimal precision, nothing.  The only thing you know is that it is numeric,

But that is all you need to know.  It doesn't matter if the field is binary or
packed or what not -- it has no effect on what %editc() does.  And while you
don't know the length or decimal precision, you do know the result encompasses
the entire field regardless of size, and when assigned to a variable that the
other variable is character and you will affect the entire result field
regardless of its size (as if P was used as an operation extender with Move).

With move, unless P is used you don't know if only part of the field is
overlaid.  You don't know if one, both, or neither fields are numeric.  And how
the Move behaves is very much depedent upon those answers.  BIFs aren't.

Change a field size and BIFs still act the same but can alter the effect of a
Move operation.

>and boy, if you can't figure out whether a variable is numeric in a program,
>you have other problems.

I can look it up, but as a maintenance programmer, why should I have to?  You
should be able to look at a section of code and "read" what it does.  When you
can, the code has more clarity, IMHO. 

And I don't buy the argument a programmer has to resort to the RPG manual every
time a BIF is used just to see what the BIF means.  Or edit codes.

>I'm done.

Me too.

Doug