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

No, i disagree, 

bring all the opcodes over into the CF-spec, so each
programmer/site/company can decide how far they want to go with
indenting. Its more flexible that way, and puts the choice with the
user. If we have to mix CF and C, ie free format and fixed format, then
it will just be confusing.

You need to be able to choose yourself whether you want to be all
fixed-format, all free format, or somewhere in the middle, and not be
restricted by the compiler, otherwise why bother at all?

-----Original Message-----
From: david.kahn@gb.abb.com [mailto:david.kahn@gb.abb.com]
Sent: Wednesday, May 12, 1999 2:09 PM
To: MIDRANGE-L@midrange.com
Subject: Re: X-Spec (was: "RPG isn't cool")




boldt@ca.ibm.com wrote:

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

Let's leave these behind in the fixed format specs.

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

These can be hard enough to decipher in columnar format. BIFs please.

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

In common with many others I'd like to have MOVE and MOVEL available in
the CF
spec.

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

"CF  add 1 counter"  looks innocent enough, but
"CF  add Net Tax TotalInvoice" is not so clear. Again, let's leave these
behind
if possible.

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

Hans, no-one in this forum has said they're not interested. So it seems
that the
programmers at least can't wait our hands on it. Roll it on. Let's not
include
outdated opcodes except where they provide extra value; they will still
be
supported in the C spec, after all. One thing I would ask is that you
allow C
and CF specs to be mixed at will. Although it'll look ghastly and ruin
the
indenting we all want, it will make the switch-over easier and allow its
gradual
adoption. Good programmers won't mix the specs ad lib, of course, but
they
should always have the option to slide a block of C or CF specs in
anywhere.

Dave Kahn, ABB Steward Ltd.


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