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

Roger wrote:
>I gotta travel so I'll miss the fun, but you guys need to hammer on Hans to
>tell you about the completely free-format x-spec IBM has on the table. I saw
>an IBMer debut the x-spec publically last week at the 400 Group's V4R4
>conference. Although it's ten years too late, it's an interesting RPG
>enhancement to ponder. It's also curious that if IBM truly thinks we're
>gonna be hamburger flippers if we don't learn Java, how the old horse could
>possibly be worth the work and budget such an enhancement would surely cost.
>
>Best bet: IBM's x-spec will never see the light of day. The spec is
>currently being evaluated by Toronto, but if the Atlanta crowd was any
>measure, the spec is DOA. After showing the spec, the IBMer asked how many
>wanted it, and a smattering of hands (less than 15 out of 200), went up.
>When he asked how many didn't want it, only two or three went up. When he
>asked how many didn't care, many hands went up. Let's face it: old fashioned
>RPG isn't cool and and most RPG programmers don't care!

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.

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.

This doesn't mean we're not still futzing about with certain
design issues, though, so I don't want to show any substantial
example of what the RPG code looks 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?  It is possible to support
all except 9 or 10 opcodes. (Most of these require resulting
indicators, which are not allowed in the CF-Spec).  But other
opcodes fall into a number of general groups:

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 "?

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?

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

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 "?

(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?

Cheers!  Hans

Hans Boldt, ILE RPG Development, IBM Toronto Lab, boldt@ca.ibm.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
+---