Re: Thanks! (was: CF-Spec - another call for opinions)

Doug,

I like consistency also.  Originally I was undecided about whether eval or 
callp were truly required.  After reading all of the explanation of how context 
can imply meaning, I would rather go with the more explicit.  In other words, 
the more convincing it takes, the more skeptical I become.

Full line free format statements shouldn't require a whole new dialect. I am 
not against keying a little so that things can be more consistent whether 
its a set of parens or an eval (besides, you have a full line so what's a 
callp or eval going to hurt.)  I also want Hans and crew to get this done 
as quickly as possible so that they can get back to enhancing RPG's 
capabilities.

David Morris


>>> Douglas Handy <dhandy@isgroup.net> 08/13/99 02:54PM >>>
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
+---