× 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: Joel Fritz <JFritz@xxxxxxxxxxxxxxxx>
  • Date: Thu, 12 Aug 1999 09:40:49 -0700

I like option 2.  It's certainly the closest to the spirit of free form
syntax.

As far as new reserved words, I would like to see "opcodes" implemented as
bifs and nouns with a leading asterisk (as they are now.)  I can't see how
it would be possible to defend completely against any overlap between new
reserved words and tokens used in existing programs.  Price of progress? <g>
> -----Original Message-----
> From: boldt@ca.ibm.com [mailto:boldt@ca.ibm.com]
> Sent: Wednesday, August 11, 1999 10:25 AM
> 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



As an Amazon Associate we earn from qualifying purchases.

This thread ...


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.