× 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: Thanks! (was: CF-Spec - another call for opinions)
  • From: dhandy@xxxxxxxxxxx (Douglas Handy)
  • Date: Fri, 13 Aug 1999 20:54:12 GMT

Hans,

>I like the idea.  I'll add it our list of proposed enhancements.

But what about extenders like (H) or (P), or things like Test (D)?
What if you wanted to do an Eval (R) or Eval (M)?  I'd want the
operation extenders to be consistent in usage in all CF specs.

Why is it not possible to use () for the extenders and still be
unambiguous?  

If someone coded a routine, Fred( ... ), which later became an opcode,
it still seems to me you can identify the usage from context:

  Fred( ... )         with no "=" or operands beyond closing )
      Treat as implicit CALLP, and Fred() as an array

 Fred( ... )  = expression    
      Treat as implicit EVAL

 Fred (e)  operand(s)
       Treat as new opcode Fred with operation extender E

There is only one scenario I can see where there could be an ambiguous
name collision.  And that would require:

 - The new opcode to not require any operands
 - The new opcode to accept operation extenders

While opcodes without operands are fairly rare, I don't know of any
which take an extender but no operands.  I suppose it *could* happen.
But if it did, if the opcode name were used as an array, you could
still identify an implicit EVAL by the presence of the "=" following
the Fred( ... ).  That leaves us with implicit CALLPs, which would
have a problem if the new opcode did not require operands but did
accept an extender.

What is the likelihood of this happening in the real world?  I'd say
it is so remote that, although in theory it could happen, I wouldn't
lose any sleep over it.  If a recompile failed, compile with *PRV
support or insert the leading CALLP in the source.

I also don't seriously object to the use of : as a separator.  

Question:  Can there be whitespace after the CF opcode like you can
with the C opcode?  It would help visually differentiate between Reade
and Read: E if you do go with a different separator.

Finallly, one last question for you:

If the CF is required in columns 6-7, where do I put the Lx indicator
for my total-time calcs?  (gd&r)

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


As an Amazon Associate we earn from qualifying purchases.

This thread ...

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.