RE: Hyphenated Op-Codes

I'm with Bob on this one.
 
In fact I'd go further, and abandon all new opcodes. I'd prefer it to be
implemented as a BIF:
 
%evalCorr(myFirstDS:mySecondDS);
 
I know people see it as a side issue, but we advocate consistency in our
applications. We expect consistency in our IDE. So why not expect
consistency in the language we use?
 
I mean, imagine writing this (pseudo code) :
 
P myProc                   b
D myProc                   pr          5i 0
D myFirstVar                       256a      options(*nopass)
 
D myStandalone          s       256a
 /free
 
  stringA = stringB + stringC;  // adding two strings without the need for
an opcode.
 
  evalR stringD = stringE + stringF; // adding two strings, but needing an
opcode now because we're right-adjusting.
 
  stringG = %trim(stringH) + %trim(stringI); // adding two trimmed strings -
now we need a BIF.
 
  evalR stringJ = %trim(stringK) + %trim(stringL); // Now we need an opcode
AND a BIF.
 
 /end-free
C/exec-sql
C+ some sql stuff
C/end-exec
 /free
 
  return 0;  
 
 /end-free
P myProc                    e
 
OK, so we've got:
 
1) Fixed format P-specs to start the procedure.
2) Fixed format D-specs to define parameters and local variables.
3) A /free to start the "implied" free format C-specs.
4) Four ways to concatenate two strings, with the use of opcodes, BIFs,
neither, and both.
5) An /end-free followed by an /exec-sql to start some embedded SQL.
6) An /end-exec followed by a /free to end the embedded SQL.
7) Another /end-free to complete the C-spec code.
8) Another fixed format P-spec to end the procedure.   
 
Personally, I'd rather all new operational enhancements to the language were
introduced as BIFs. I don't even mind the "%" at the beginning. At least it
marks that function out as a part of the language - better than causing us
grief by introducing a new reserved word that may conflict with existing
application procedure names.
 
It just makes sense to me that your code should read the same whether you're
using system functions (like open, close, read, write, send, recv), or C
library functions (like bsearch, qsort), or user-defined functions (like
myProc), or RPG language-specific BIFs (like %trim, %subst). Why not do away
with opcodes and only use BIFs? If all functions and operations behaved in
this way then programmers would find it a lot easier to use system APIs -
because the programming interface is consistent with the way they program
everything else.  
 
If java has it's "everything is an object" why can't we have our own
"everything is a function"???
 
I know using eval is not the best choice to make my point as most languages
support overloading the + operator for strings, but my point is really to
highlight the fact that we're already using a mish-mash of opcodes and BIFs.
Bob's point about IBM not even having consistent naming conventions for
these opcodes is valid to me.
 
Just my 0.02 euro-dollar. [or should it be euroDollar(0.02F) :-) ]
 
Cheers
 
Larry Ducie