Re: /free vs Fixed (was: RPGIII to get a facelift?)

I use free format exclusively (except for those cases when I MUST use
a GOTO (<--rarely)).  I agree with you on some of these points.

On Thu, 28 Oct 2004 18:48:58 -0500, Bob Cozzi <cozzi@xxxxxxxxx> wrote:

> Where's the issue?  The semicolon on the IF and the ELSE statements.
> I can get used to entering /Free and /end-free once, but when you code 10
> million IF statements in your lifetime and for 9,999,995 of them you forget
> to enter the ; and have to recompile, it gets to be bothersome.

I agree.  And I don't think that the semicolon should be allowed after
the IF statement, but after the ENDIF.  the IF clause is by no means
ended at the first instruction that is to be executed for the positive
case--It's just the beginning.

> 
> Then there's the very extensions to the opcodes in free format that I'm
> beginning to dislike a lot. Take the CHAIN opcode. I love the ad hoc keylist
> idea. It is a wonderful feature, but then, instead of allowing us to simply
> use data structures as keylists or allow us to declare key lists on D specs,
> they added that "opcode parameter keyword" thing.  So now we have 3
> different free format syntaxes for the CHAIN opcode. That in addition to the
> fixed format CHAIN syntax.
> 
> Rules for CHAIN in Free Format:
>  If you use a KEYLIST, then just the keylist name is specified.
>  If you use an ad hoc keylist, enclose the fields in parentheses.
>  If you want to use data structure subfields are key fields, specify the
> data structure name and enclose it in a %KDS() parameter keyword.
> 
> If the free format syntax is so much better, why all the extra syntaxes "if
> this, then do this, else do that" I mean just try teaching this to
> students... They many get turned off to /FREE immediately even though they
> love the ad hoc keylist capability.
> 
> If data structures did not fit the ad hoc keylist model, that is allow them
> to simply be enclose in parens, then data structures should not have been
> allowed. In stead, keylists should have been allowed on the D spec and
> specified as usual (with no parens) then if you only want to use a partial
> keylist (a subset of the fields in the keylist) enclose the keylist in
> parens and specify the number of fields to use as the 2nd value, like thisL
>   Chain myKeyList  CustMast;
>   Chain (myKyelist: 2) custmast:
> In fact,
>   Chain (myKeyList) Custmast;
> Should also work today, but it does not (as far as I remember).
> 
> For those who say, "I already have a data structure created that has the
> keyfields I need, why not allow %KDS?" I say, why not this instead:
> 
> D  MyKeyList          KL             LIKEDS(MyKeyDS)

This would be very nice.  I actually use the ad-hoc keylist
everywhere, because it is crystal clear exactly what fields are being
used to key to the file, whereas a %KDS data structure leaves the
person editing the code later to do the 'scroll back to the D specs'
routine, and sometimes, if you specified the DS to be like the key
fields of the record format, even look at the DDS for the PF.

Additionally, sometimes the %KDS, during compile, does not compile correctly.  

Also, as far as free-format goes, what's wrong with MOVE?  I
understand the fundamental diffences between MOVE and EVAL, but why
extinct it?  One of the data extracts I do demands the creation of a
'unique identifier', which includes text versions of several numeric
fields.  Without MOVE, the leading zeroes go away, forcing you to
either /end-free, MOVE, /free (fugly), or EVAL, concatenating
'0000...', and substring (complex).


-- 
"Enter any 11-digit prime number to continue..."