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

Hans,

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

I don't think I made myself clear.  I have no problems with an
explicit EVAL or CALLP when extenders are required.

My point was that, since somer extenders would still (presumably) be
coded with the opcode, the idea of moving the error extender on IO
opcodes like READ to a positional argument as in 

>cf   dow %read(fileformat,E)

Oops!  Just went back to the original message to find what to quote,
and had forgotten it was a BIF for the READ instead of the opcode
being READ.  My original comment was based on thinking the E was being
suggested as an optional positional argument on the READ opcode, not
the BIF.  I didn't want the extender as an operand in some cases and a
suffix on the opcode in others.

Please redact my earlier message, with apologies. :(

Having a %read() BIF would be very nice indeed!

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

OK.  I hadn't come up with any cases I thought would still be
ambiguous, but I'll take your word for it since it evidently would
complicate the parsing process more than I anticipated.
 
I don't think any of us want to signficantly complicate the issue for
you since we all have other items on the wish list too. <g>

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

That's fine.  Actually, I thought it may be just the opposite, and
reduce ambiguites if you *required* whitespace between the opcode and
() extender.  I figured that could signal the parser in the first pass
that it couldn't be an array reference or arguments to an implicit
CALLP but was an optional extender before the first operand.

But hey, I don't work on the compiler, so I'll let you decide what is
easiest.

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

I agree, assuming we don't use ().

>Our current implementation
>of total calcs is not the greatest since each line conditioned
>by Lx tests that indicator. 

Which is one reason that, since the S/34, I've typically liked to just
code the Lx calcs as one call per level to a subroutine, e.g.:

     CL1                    EXSR L1TIME
     CL2                    EXSR L2TIME
     CLR                    EXSR LRTIME

It was (slightly) faster, reduced the object size (a concern w/ 64K
limits), and made the code easier to follow besides (IMHO).

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

Which is why I added the <gd&r> to my question.  I'm really not
concerned if CF does not support total-time calcs.  One could always
code subroutine calls like above, then put the CF in the routines.

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