× 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: "Scott Klement" <infosys@xxxxxxxxxxxx>
  • Date: 11 Aug 1999 14:36:42 -0500

boldt@ca.ibm.com wrote:
<< SNIP >>

> 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

I like this better than the other options that you're giving us :)
See the test of the comments below...

>
> 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

It'd create a real nightmare to have to upgrade versions if I had
to worry about compatibility.   This would even be more true in
enviornments where there are more programmers and more outside
help doing programming.

It would, very possibly, discourage people from upgrading.  So
although it'd be nice to be able to omit the eval and callp op-codes,
I think I'll vote against this option.

>
> 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.

I'm afraid that this might make op-codes "ugly".  This also means
that I can't have a procedure named "select" for example.  Seeing
as how I use the select() procedure from the sockets API frequently,
that would annoy me :)   Granted, I could call it something else,
such as "socksel"  but... I prefer to stick to the same names that
I also use in C. :)

>
> 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?

Yuck.  Yecchhhh.  Blech.  UGLY!

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

You could also try having a "shortcut" for eval or callp.
Something like:

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

I dont know if they'd have to be seperate characters for eval and
callp, or if one shortcut would be adequate...  but at any rate,
thats a possibility that you didn't list ;)


>
>
> 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
>

Scott Klement
Information Systems Manager
Klement's Sausage Co, Inc.
+---
| 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.