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

In all seriousness ... I totally concur with everything Doug wrote below.
Seriously.

Peace,

-- Don Schenck

-----Original Message-----
From: dhandy@isgroup.net [mailto:dhandy@isgroup.net]
Sent: Tuesday, May 11, 1999 6:49 PM
To: MIDRANGE-L@midrange.com
Subject: Re: X-Spec (was: "RPG isn't cool")


Hans,

I'll have to reiterate the earlier posting about you being brave,
Hans!

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

Isn't that what we've been trying to tell you all along? :)

A few initial reactions:

>There are no control level indicators or conditioning indicators 

It's already promising to be an improvement over the old syntax...

>There are no resulting indicators 

Provided there are enough new BIFs, this may be workable.  But, I'm
not sure you want to do this.  I suspect it would also be easy to code
the compiler to accept keyworded resulting indicators after the
operands, and this would address many of the other issues below by
default.

This is what Paul Conte did with RPG/free, and in my experience it
worked out rather well.   Just do something like HI(xx), LO(xx),
EQ(xx), and synonyms like NR(xx), ERR(xx), or EOF(xx), where xx could
be an indicator, *INxx reference, or a variable defined as an
indicator type.

This is still readable insomuch as they are not column dependent, and
has the advantage of allowing you to support most if not all of the
opcodes without corresponding BIFs.  It also would simplify a code
conversion utility (or option to CVTRPGSRC) since it could just set
the existing indicator rather than trying to analyze conditioning
indicator references and swap to the appropriate BIFs.

This is what I see as one of the major advantages to supporting
keyworded resulting indicators.  In order to get wide, fast acceptance
of the CF specs, we need to be able to transition existing code to it
efficiently and reliably when we go to perform maintenance on legacy
source.  (In fact, legacy work is what may win people over).  Since
indicators are global outside of subprocedures, it seems to me
difficult to guarantee compatibility if you attempt to change
conditioning indicators to BIF references, unless a given resulting
indicator is only used for one operation (or compatible operations),
or all conditioning indicator references are between the opcode and a
logical breaking point (like an ENDSR) with no intervening code (like
a EXSR) which could potentially change the indicator status.

For example, if you have someone who primes a DOW loop with a CHAIN
then does a READE within the loop using the same indicator, it becomes
much more messy to switch to BIFs.  But even that is more straight
forward then when conditioning indicator references are scattered all
throughout the code, and the same indicator is used as a resulting
indicator for diverse operations also scattered all over.  If a
subroutine references a conditioning indicator prior to using it as a
resulting indicator, but numerous operations use that resulting
indicator, what BIF do you pick?  If inside a loop are conditional
calls to multiple subroutines which set the same resulting indicator
but for different operations, how do you substitue a BIF?

Wouldn't it be much simpler to just add keyworded resulting
indicators?  I'm not saying I'm a fan of resulting indicators -- I'm
not -- but it seems like you will make life alot harder for the
conversion utility folks if you try to convert to BIFs.

>No definition of fields on calcs - use D-Specs for that.

No argument there.

>CF specs may be intermixed with normal C specs, but we would
>expect that programmers would likely keep the two styles separate.

I would certainly hope so.  The only exception I could see justified
is if there are unsupported opcodes or syntax variants, and there is
no easy automatic conversion.  Then I suppose you could justify
leaving some statements in fixed format (not that I would write new
code using them, but for the sake of legacy conversion compatability.)
However, with keyworded resulting indicators I think you could support
most if not all of the existing opcodes.

>1) IFxx, DOWxx, etc.  There are currently expression alternatives

I would prefer forcing the expression syntax.  It is more readable,
and easily converted by a utility with no compatability concerns.

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

Not if a BIF exists which is an exact equivalent.

>3) Move ops:  MOVE, MOVEL.  

I'd say support them.  But in those cases where the MOVEx variant
could easily be replaced with a compatible EVAL, even when it needed
%subst, I'd like it to do so.  Have it keep MOVE only when doing dumb
things like incompatible data types, etc.

>4) Arithmetic ops:  ADD, SUB, etc.  

Again, I think you need to support them for compatibility sake if
nothing else.  I don't want isolated statements left in fixed format
interspersed with free format unless necessary, and it certainly
doesn't seem necessary here.  

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

Since the fixed format will still be supported, you won't be able to
leave behind support in the compiler for any existing functionality
anyway.  So, I'd say do something like this:

 - Have conversion utililty ignore total-time calcs
   (we can always move them to a subroutine anway)
 - Translate all field definitions to D-specs
 - Translate all conditioning indicators to IF blocks
 - Translate IFxx, DOWxx, DOUxx to expression syntax
 - Where equivalent BIFs exist, convert opcodes to BIFs
 - Where compatible, convert MOVEx variants to EVAL
 - Make the opcode EVAL optional (like SET in basic)
 - Just reformat everything else; use keywords when necessary
   to retain compatibility with legacy code (eg resulting indicators)
 - Ident and align reformatted code appropriately

At least, that is my initial knee-jerk reaction.  I see having a
robust legacy conversion absolutely paramount, and I just don't see
how you will do that in all cases without supporting resulting
indicators instead of trying to substitute BIFs for conditioning
indicators. 

But I've been wrong before (once or twice :), so the more it can
switch to expressions and BIFs without losing compatibility the
better.  It's just that with RPG ILE starting factor 1 in column 12, I
want most everything switched to free format since unnested operations
would begin in column 9.  Otherwise fixed format operations would
interfere with otherwise correctly indented code.  Allowing keyworded
resulting indicators would (I believe) avoid that scenario, even when
compatible BIFs did not exist.

Thanks for asking. :)
+---
| 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
+---