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

Very interesting stuff. Here is my 2 cents.

Generally, the new spec should support one way of doing thing (Ex IF but no 
IFXX). If a bif exist that do the same thing as an opcode, do not suport the 
opcode on the new spec. The MOVE opcode is special because EVAL can not 
completely replace it. Maybe EVAL should be improved to completely replace 
MOVE. The free format open the door to both good and bad coding practice.By 
limiting the numbers of way to do the same thing, you can force a litle more 
concistency without any reel sacrifice. Thos who still want to code IFEQ A B 
can use the regular C spec.

Denis Robitaille
Cascades Inc
819 363 5187
fax 819 363 5177
DRobitaille@cascades.com

>>> <boldt@ca.ibm.com> 05/11 1:11 pm >>>

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

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