Re: X-Spec (was: "RPG isn't cool")

boldt@ca.ibm.com wrote:
 
> Well, a month ago, I would have given the "X-Spec" 50-50 odds of
> making it into our next release.  Here's an update:  It's now
> called the "CF-Spec" or "Free-form Calculation Specification"
> and it's currently working in the lab!  Most of the code is
> already in place in the compiler.  Believe it or not, this
> enhancement turned out to be rather easy to code.

I want this.  And I want it _badly_.

Since it is:  1) "rather easy to code" (your words), and 2) "Most of the
code is
 already in place in the compiler" (your words), and 3) no one would be
_forced_ to 
use it if made available, then I can't imagine a good reason why IBM
would withhold it.
 
> The general idea is to code F in position 7, blank in position 8,
> and the free-form statement in positions 9-80.  Start with the
> opcode and extenders, followed either by the free-form expression
> (for the current expression calcs) or by the Factor 1, Factor 2.
> and Result Field operands (for the current fixed-form opcodes).
> Everything is free-form within pos 9-80.  There are no control
> level indicators or conditioning indicators - use IF instead.
> There are no resulting indicators - use BIFs %FOUND, %ERROR, etc.
> instead.  No definition of fields on calcs - use D-Specs for that.
> CF specs may be intermixed with normal C specs, but we would
> expect that programmers would likely keep the two styles separate.

All of that makes sense to me.  I still use level breaks on report
programs and all I'd have to do is code:
CL1                Exsr        BlahBlah   (spacing not correct)
and then put all the actual calcs in a subroutine.  BTW, what would a
free form "begin subroutine" look like?
 
> I would like to ask those interested to offer opinions on the
> following design question:  To what extent should the fixed-form
> opcodes participate in the new scheme?
> 
> 1) IFxx, DOWxx, etc.  There are currently expression alternatives
>    for these, so why bother carrying these forward in the new
>    scheme.  Do we support these in the CF-Spec?  ie. Do we allow
>    code like:  " CF   ifeq counter 17 "?

No, don't support in free form.
 
> 2) String ops:  SCAN, SUBST, XLATE, etc.  There are expression
>    or BIF alternatives (or will be) for most (possibly all) of
>    these.  Do we support these opcodes in the CF-Spec?

Don't support if there is a BIF alternative.
 
> 3) Move ops:  MOVE, MOVEL.  You could code EVAL/EVALR for many
>    moves, but not all MOVEs are easily convertible to the EVAL
>    statement.  Do we support MOVEs in the CF-Spec?  (If not, we
>    would have to add additional new BIFs, which still wouldn't
>    cover all of MOVE semantics.)

Don't support if there is a BIF alternative (or will be).  You're right
that there are some MOVEs stuff that won't work correctly with EVAL, but
I'll be darned if I can think if the examples right now.  But, since we
can intermingle fixed and free format, if there is one of those weird
places where one needs a MOVE, just code a fixed format MOVE until the
BIF is available.
 
> 4) Arithmetic ops:  ADD, SUB, etc.  As many have already
>    discovered, arithmetic in expressions is not totally
>    compatible with arithmetic in the fixed opcodes.  Do we
>    support these in the CF-Spec?  ie.  Do we allow code
>    like:  " CF  add 1 counter "?

Don't support if there is a BIF alternative (or will be).  There are
some places where I use ADD, SUB, etc. because I am expecting a
truncation.  I'm still on V3R2 (for probably 10-12 mos yet), but I know
there are some V4 BIFs that help with this situation.

> (This list isn't complete, but is representative enough for the
> purpose of helping us decide the issue.)
> 
> So, the general issue is how much of the "old" stuff do we carry
> forward in the CF-Spec and how much can we leave behind?

Leave it all behind.  As I said, if there is something weird, and we can
mix in fixed format C specs, I'll just stick one in in the rare case I
need one.
 
Please tell me this will see the light of day!

-- 
-Jeff

jlcrosby@fwi.com
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---