× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: Re: CF-Spec - another call for opinions
  • From: James Greene <triplej@xxxxxxx>
  • Date: Wed, 11 Aug 1999 12:24:44 -0700

I vote for option 2.  With one thought.  In addition to the CALLP is the
likelyhood of a CALLx insignificant?

boldt@ca.ibm.com wrote:

> 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



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.