Re: CF-Spec - another call for opinions -- RPG400-L

Hi Hans,

I think option (2) of Omitting EVAL and CALLP is OK.
Moreover, it seems to me that any token after CF is first  checked for an valid
Op-Code and if it's not, then it's a variable. Right? If so, I think , there
should be some change in this logic. The token 'A' should never be an opcode if
exists in an expression like A = B. It's like assigning a value to a opcode.

Thanks,
Rajeev.





boldt@ca.ibm.com on 08/11/99 10:24:41 AM

Please respond to RPG400-L@midrange.com












Subject:  CF-Spec - another call for opinions




Greetings!  Asking the readers of this mailing list seems to work
well for us in deciding questions.  And again, we have an issue
which your opinions will help us decide on.  In examples that I've
posted already, you've seen statements like "CF var = value", where
the opcode EVAL is omitted.  Based on someones suggestion earlier
today, I investigated allowing "CF UpdateMasterFile()" instead of
"CF callp UpdateMasterFile()", and I found it remarkably easy for
us to implement.

However, allowing the opcode names EVAL and CALLP to be optional
raises the issue of future compatibility.  Say someone codes
"CF fred = flintstone" and in a later release we add new opcode
FRED.  This would result in a compile error!  Note that we're not
really making the opcode names reserved since we'd still allow
"CF eval read = x", and in fact, coding EVAL would be required if
the target variable name is the same as an opcode name.  As a
result, the problem is not as bad as the appearance of new
statements in other languages, especially COBOL.  But it would be
something new for RPG programmers.

So, please consider and choose one of the following options:

1) Make EVAL and CALLP always required:

      CF eval KeepLooping = *ON
      CF dow KeepLooping
      CF    read MasterFile
      CF    if %eof
      CF       callp HandleEndOfFile()
      CF    endif
      CF enddo

2) Allow EVAL and CALLP to be omitted:

      CF KeepLooping = *ON
      CF dow KeepLooping
      CF    read MasterFile
      CF    if %eof
      CF       HandleEndOfFile()
      CF    endif
      CF enddo

3) Option 2 with a commitment from us that no new opcodes will
   conflict with any possible variable or procedure name.  For
   example, opcode ON-ERROR could never be confused with a var or
   proc name.  This may mean some goofy looking opcodes in the
   future.  On the other hand, since most enhancements these days
   seem to be in BIF's, this may not be too big a deal.

4) Optional EVAL and CALLP, but use some special character to
   distinguish opcode names from var or proc names:

      CF KeepLooping = *ON
      CF /dow KeepLooping
      CF    /read MasterFile
      CF    /if %eof
      CF       HandleEndOfFile()
      CF    /endif
      CF /enddo

   If you don't like "/", what about some other character?

5) Is there some other alternative we've missed?


As usual with this kind of poll, comments on the issue are
welcome.

Cheers!  Hans

Hans Boldt, ILE RPG Development, IBM Toronto Lab, boldt@ca.ibm.com


+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---END







+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---END