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

Doug wrote:
>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.

Under the current design, if you want to code an opcode extender
on EVAL of CALLP, the opcode would have to be explicitly coded.

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

Good question.  In many cases, it would certainly be possible to
determine the meaning of a statement after reading the entire
statement.  But compiler writers don't like having to back up
significantly and reparse a statement just because an assumption
is shown to be invalid during the parse.  It makes the process
much more difficult and error-prone.  And for us, there would
still be ambiguous cases.

Generally, languages are very often designed to make compiling
easier.  One classic example was Pascal, which was originally
designed to be compilable in one pass.

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

Our current design has the opcode and extenders together with no
embedded spaces.  Otherwise, there are ambiguities.  Sorry.

We thought about using some other character, like /,  to separate
opcode and extenders.  But we thought the colon looked better and
was also consistent with the use of colon as operand 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)

Good question.  (No need for gd&r.)  Our current implementation
of total calcs is not the greatest since each line conditioned
by Lx tests that indicator.  (Although I'm sure OPTIMIZE(*FULL)
improves the situation.)

The design for total calcs on the CF-Spec uses a new opcode to
indicate the start of total calcs.  Then you use the IF statement
to mark the statements conditioned by particular Lx indicators.

Note that in some cases, traditional fixed format code may not
always easily convert to the CF-Spec syntax if the code is not
properly structured.  But then, as I've stated before, the
CF-Spec is primarily intended for new code.

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