Re: Adoption of new RPG techniques -- RPG400-L

Joe Pluta wrote:

To use such a field you need free format code (unless you use the "loose fixed format" of eval+extended factor 2).


This implied that you considered extended factor two somehow "above and
beyond" standard fixed format RPG IV.  My point was that most of the
things you included as benefits of /free are indeed available in fixed
format RPG IV.  The extended factor two is what makes /free so
superfluous.

Ah. Yes, I can see where you are coming from. Like almost every argument, a lot of confusion comes about because of a lack of defining terms. People tend to make strong statements without really agreeing on what the terms mean that they are talking about. So let me define what I'm talking about (in case anyone is even reading this thread anymore):

In an earlier post I said:

If we stuck to what I'm going to call "true fixed format" then we would have:

<indicators> <factor 1> <operator> <factor 2> <result> <indicators>

The above is how I define fixed format. It is the syntax that RPG/36, RPG II, and RPG III use. With RPG IV we got a new syntax, something I called "loose fixed format" that consists of indicators, factor 1, opcode, and a new extended factor 2. This new extended factor 2 is really just a free format section of code within an otherwise fixed format syntax. In order to emphasize the fact that the extended factor 2 provides us with a free form style syntax I'm going to refer to this mixed syntax of RPG IV as "fixed-free". Fixed-free syntax looks like:

<indicators> <factor 1> <operator> <free format area>

This is the extended factor 2 syntax that we are familiar with as part of RPG IV. "True free format" syntax I'm going to define as syntax that has none of the fixed elements, i.e:

<free format area>

It seems a little pedantic to include that definition - but let's be complete. The interesting part to notice from this whole discussion is that we all primarily code in the free format area of fixed-free syntax. So much so that it seems wasteful to have to the fixed areas of fixed-free syntax. Following the suggestions of coding *EXTFACT2 in factor 1 would completely obviate the need for any code at all in the fixed area. So why have any fixed format at all?

With some definitions in place we can look at that question. One argument in favor of fixed format is that it is legible to RPG programmers. That argument is silly, since because true free format is just that, free format, you can format the code to look anyway you want, including making it looked like fixed-free code looks. If you think that the current fixed-free syntax of RPG IV is easy to read, then just keep indenting things that way.

Another argument against true free format code is the required uses of the /free precompiler directive. I agree that this kind of sucks. If a precompiler directive is necessary, I personally would have chosed to use /fixed to indicate areas the follow RPG IV's fixed-free syntax and defaulted to true free form syntax otherwise. But perhaps the best solution is to do what someone else mentioned a while ago and use the C in column 6 to indicate fixed-free vs. true free format code. Put a C in column 6 when you want fixed-free and leave it blank when you want true free format.

Another argument against true free format syntax is that the syntax checker doesn't work with it. This isn't really a problem with true free syntax or the compiler, but with the editor. Emacs, vi, and other editors can check true free format code, RPG editors should do the same. Perhaps SEU is not the editor to do that with, however.

Yet another argument against true free format syntax (YAAATFFS) is that following programmers will have a hard time with the indenting style chosen by the previous programmer. This is simply solved by code beautifiers such as those available for C. A standard beautifier such as the unix utility 'indent' could handle this without issue (indent also checks syntax - a nice bonus).

Now for the hairy stuff - addressing the MOVE issue. I'm afraid that this will never be resolved in a way that Joe likes because so many (myself included) don't like the MOVE opcode. The biggest uproar over this issue has been because some view MOVE as being removed from the language and others see it as simply not being moved forward into true free form syntax. Possibly the solution involving the C in column spec would pacify both camps, but I'm not counting on it.

I think those are the main arguments that have come up so far. But there has been an underlying argument that I don't think has been directly addressed: backward compatibility. I am interested by the statement "RPG is too backwards compatible". While argueing neither for nor against, I wonder what good or bad would come if RPG forked and a new, non-backwards compatible branch developed that contained many of the enhancements that have been asked for. RPG IV as it stands now would still be supported, but no longer evolve. Maybe call this new version something else, like FIR (FIR Isn't RPG - clever recursive acronym). It would have record level access, chain, external files, true free form, proper pointers, good SQL syntax, etc. but wouldn't support fixed-free or true fixed format at all.

Hopefully I've clearly stated the definitions and arguments. If there is anyone left reading this thread perhaps we'll understand each other better.

Yes, all day long.  But assuming I said something that was true, would
my background somehow make it false?

No, but the errors in your assumptions undermine the credibility of your
statements.

True. Happily I learned something new today about RPG.

James Rich