Free Form

[R.Daugherty]

That's BASIC style, Tom. I think the languages we would want RPG to look similar to are Java and it's C family of predecessors. They have semicolons or braces after each statement, like /free. In my opinion that's a good thing to be similar. In addition, as I post every so often, the open brace should be allowed (actually, encouraged) after block statements like DOU and replaced by the compiler with a ; when parsing the line, and the closing brace encouraged and replaced with an END; by the compiler. There's no reason to have a different standard than the standard. By the same token, == and != for comparisons, and break and continue for loops should be handled as equivalents by the compiler. The multiple statements across a line is a nightmare. I can just see debugging that now. :) rd

[tdaly@sddsystems.com]

Gak! <blockquote><tt>the languages we would want RPG to look similar to are Java and it's C family of predecessors. </tt></blockquote> C style would be a disaster, IMHO! C has a lot of power, and <U>many</U> pitfalls. The aim is clarity, and in this C is lacking. Currently RPG allows only one statement per line, so why require the programmer to type a character indicating end of statement? Most statements are not multi-line statements. The common case should be the easiest to express. Tom D.

[tdaly@sddsystems.com]

Hey Ralph, Thanks for the reply... in fact you where the only one to reply! Didn't mean to jump on you, I let my dislike of C get ahead of me. I was kinda hoping others would chime in. Not that I really expect anything to change, but just to kick it around anyway. Tom D.

[R.Daugherty]

If I had liked C, my career would have taken a drastically different direction long ago, before I got on the /400. But I like Java. In any event, they share a heritage of semi-colons ending statements, and line terminations being mere white space to ignore. :) But speaking of C, an interesting thing I saw in some RPG example code recently was pointer math, one of the things taken away from C's heritage in Java. I doubt that those who don't think much of RPG knows RPG has pointers, much less capability to manipulate it. On the other hand, there was good reason it isn't in Java. :) rd

[Guest.Visitor]

Readability comes from good naming conventions for procedures, variables, and formatting. Multiple statements on the same line can be a good thing. If not %found; sendmessage('Not Found'); End If; Continuation characters eliminate the 'Free' in Free-Format. Continuation characters are for line based programming languages. Free-Format means formatting doesn't affect program execution. In Free-Format RPG when working with text, I often find I have a single assignment fill 5 lines. Putting continuation characters at the end of each would be a pain.

[Guest.Visitor]

Another suggestion is to have the possibility to have source lines greater than 80 chars. Splitted code lines because of the 80 chars limit are harder to read and a pain to code. This way, continuation char would be almost obsolete. <hr width=50 align=left>Code ('http://www.mcpressonline.com/mc/showcode@@.6b3ce3e5/5')

[rharman@knotts.com]

I don't mind the semi-colon after a statement, but after an if, else, endif, etc. drives me nuts. I'd like to see more C-like constructs available - like... multiple assignments.... a = b = c = d = f = somevalue; assign and compare.... if (( x = somefunction( arg1 : arg 2 )) == somevalue ); Multiple statements on a single line would be helpful in some cases too. and... a ternary operator. x = (( a < b ) ? c : d );

[scatterload]

reminds me of my cobol days in college...the second program i wrote in that class, was written in basic. it read each line and "interpeted" (somewhat reliably) where the end of the statement was and placed a period at the end. -bret

[H.Boldt]

Roger wrote: "I'd like to see more C-like constructs available" Then write your programs in C.

[SoftwareTrend]

We have C#, C++, and Java all based on a pre-80s structure that is so-o-o easy to make very complicated (braces everywhere) and so lacking in programmer support (case sensitive - they are joking!). And this is the model for RPG????!! Hell throw in the MVC model and lets see the development times for a simple app blow out to weeks - and then be offshored to make them cheaper again. Tony (OP) was right - VB was the best language syntax to go with although a simple SQL type variation with statement terminators would have been good as well. And don't come the rubbish offered by IBM about the compiler complexity - MS and the SQL vendors seem to have worked it out easy enough - in fact MS's compilers are so fast that on the fly compilation is not a big issue within ASP.NET. Ron

[SoftwareTrend]

[Guest.Visitor]

You gave this advice to me once, and I took it. Faced the disgusted I/O. Took you second advice and embedded SQL. Still felt disgusted. Back to RPG now!

[R.Cozzi]

How about you stop using those unreadable ############# all over your code. Then it would fit easily into the old fixed-format columns, let alone 72-bytes for /FREE style.

[R.Cozzi]

Granted I'd rather code this: <pre> If (A > B) C = 1; or if (A > B); C = 1; endif; </pre> Than only the later. But what still gets me is: <pre> for (i = 1 to 10); // do something endfor; </pre> The above code will not compile because parens are not allowed on the FOR opcode. It doesn't matter technically or design wise why it isn't supported, it should be. The silly one is the "DO" opcode. It isn't supported in /free so an old trick in RPG IV to get out of a nested IF bock doesn't work: <pre> DO; if (a=1); x=1; leave; elseif (a=2); x=2; leave; endif; enddo; </pre> The crazy thing is, while this code is not supported (DO is not allowed in /FREE). the compiler issues a message that the LEAVE opcode is invalid because its not inside a DO, DOW, DOU, or FOR loop. And yet it is inside of one. No mention of the "DO" opcode not being support--no error, no warning. Insert this: <pre> /end-free C DO /free </pre> In place of the free format do, and it works just fine. Like I said a silly point, but silly nonetheless.

[R.Daugherty]

I use "dou flag" or equivalent in all languages for two reasons. One is that it establishes a DO loop to leave or iter. Second is that it provides a general flag variable for ending the loop for any number of conditions. I don't use DO, and didn't miss it. I will go with Hans on his point. For people that want to code with C constructs, just code in C. rd

[Guest.Visitor]

Did I get all my brackets right? I don't know. I don't have the time to figure out which bracket applies to which structure. Please, please, please, don't let RPG fall into "bracket creep". Let's keep Enddo, Endif, Endsl & Endcs. That makes RPG much more legible.

[Guest.Visitor]

### prefixes program defined non-database vars. It may be somehow unreadable to you Bob but very easy to work with and search in source. Database fields are prefixed by 3 chars ex.: A02XxxXxx, so for a work var, you just override A02 by ### and voilà! No matter the prefix Bob, IBM should let go the 80 column punch card format once and for all

[scatterload]

the big issue i have with C is the fact that the bracketing can be lost in the code. RPG Free has its quirks, but at least with only one semi-colon (usually) per line, it is a little easier to find the culprit in a statement. what i dont like is what mr. cozzi pointed out and that the next statement after a missed semi-colon is reported as being in error. never used a DO statement. I always figured if a function needed to be executed once, just condition it with an IF statement or a </GAG!> INDICATOR <GAG!>. -bret

[tdaly@sddsystems.com]

Francois L. said: <blockquote><tt>IBM should let go the 80 column punch card format once and for all </tt></blockquote> Maybe that's answer. If source records were long enough then no continuation character would be needed. The end of the line is the end of the statement. This helps make the case for moving source out of QSYS and into the IFS. I'm not sure I understand Bob Cozzi's comments about parens on the FOR opcode though. My beef with FOR is "to/down to" to indicate an incrementing or decrementing loop when the sign of the BY value really should dictate that. Tom D.

[OzzieH]

Free is one of those minor things on my list to delve into (if only for a day). I'm glad I haven't. It looks like a bloody mess. You all have bantered on about the benefits of using /free, but given these headaches, surely any benefits would be wiped out no? I mean if you can't even do a simple DO statement, why would anyone want to mess with it? At least at this point.

[tdaly@sddsystems.com]

Well I don't know that I'd call them headaches. Maybe more like nitpicking ;) Tom D.

[Guest.Visitor]

Look at the code below and tell me if you think it's hard to read with the brackets. Tom. <hr width=50 align=left>Code ('http://www.mcpressonline.com/mc/showcode@@.6b3ce3e5/21')

[DougCMH]

In reply to Bob Cozzi's post... <pre> for (i = 1 to 10); // do something endfor; </pre> OK. First, RPGIV is consistent in that you can surround expressions in parentheses. Since i = 1 to 10 is not an expression, it makes sense that you can't put parentheses around it. It is statement syntax, not an expression. You can't put parens around statement syntax (as far as I know). That is also consistent. If you want to be able to put parens around statement syntax, it should be available for all statements, to keep it consistent. For example: <pre> for (i = 1 to 10); chain (%kds(MyKeyds) MyFile); update (MyRec %fields(F1:F2:f3)); eval (A = B + C); (A = B + C); (MyProc(P1:P2); sorta (MyArray); clear (*all MyRec); in (*lock MyDtaAra); exsr (MySubRtn); </pre> and so on and so forth. Second, why would you want to put parentheses around i = 1 to 10 ? The FOR statement is pretty straightforward to me. Parens around expressions. No parens around statement syntax. That is RPG, and it seems consistent to me.

[Guest.Visitor]

Believe me Os, for anyone who has ever coded in anything but fixed format RPG, free format as it stands is a blessing. And if you ever did learn free format to the same comfort level you have of fixed format so that you could make a fair comparison, then I'd think you would find free format more productive.

[Guest.Visitor]

I'm with Modulator: I can write the same program in /free in half the time it takes to write it in fixed format and -- of course I indent very nicely -- anyone can READ it with one glance. Bob wants to use extra parens; someone else wants to use brackets. What's the matter with KISS?

[scatterload]

agree with using /free. although it has some quirks, having grown from a s/34/36/38 and rpg on the /400 since '89, i have come to accept that there are quirks and there are QUIRKS.&#32; ibm does something that i really appreciate. they use backward compatability when designing their OS. this gives the folks who started on the s/3 and are used to the punch cards, the ability to write code in a fixed format that corresponds to their knowledge. at some point, these venerable programmers and the OS designers at ibm who have been around for a while will not be. like our korean war vets, they seem to be a largely forgotten element of society. as for /free. i love it. i can write that (nearly) self documenting code. i enjoy finding it on the system and if i can get my checking account balanced, i am going to buy the RPG /FREE book from midrange so i can see what other things i could be doing better! -bret

[R.Daugherty]

Bob wants to use extra parens; someone else wants to use brackets. What's the matter with KISS? I was attempting to keep it simple, by keeping it consistent. A semi-colon after block open statements like DOxx and IF is different from other languages and is compiler oriented thinking, not programming oriented. It blurs the beginning and end of a block with the statements within it. That's why other languages open and close with braces and end statements within the block with semi-colons. (although I'm not a compiler writer, and not particularly well versed in the history of language syntax, this is just obvious.) I do agree with previous poster who says ENDxx makes te code much more readable. I follow closing braces with a short comment that matches comment following open brace when code is complex, as well aa aligning them of course. All I am saying is that the ending character of block open and close lines should be allowed to be different and standard, an opening and closing brace that is just substituted by the compiler to a semi-colon for compilation. The ENDxx should be allowed to be optional in front of closing brace, so it would be ENDxx} or ENDxx; or just } (and ignoring any whitespace of course). Along with allowing substitution of ==, !=, break, and continue, and any other obvious equivalencies, not as much of a syntax change has to be made switching between other languages like Java. With the Rube Goldberg crap that constitutes IT these days, I would think that would be considered desirable. rd

[scatterload]

even COBOL (shudder) allows for intuitive continuation of lines as long as you end one with the period. see code example: -bret <hr width=50 align=left>Code ('http://www.mcpressonline.com/mc/showcode@@.6b3ce3e5/27')

[Terry Winchester]

Since the OPEN statement is surrounded by an If/End-If, the period is not required because of the scope delimiter :) A standard OPEN statement no longer requires a trailing period, nor does any other COBOL statement/verb. When the free-format RPG came out I was kinda' hyped that it moved away from the rigid column requirements (which I despised) but then I discovered that it required semi-colons to terminate each line. Sheesh.... As a COBOL'er, I have not used periods for the past few years - except where they are required (primarily before paragraph names). I still don't understand why the free-form RPG compiler cannot be a little smarter - just like the Cobol compiler. Until RPG changes, I will stick with my favorite "dead" language...lol Terry

[scatterload]

Guess it shows that I am not a COBOL programmer. Just remember the reference to some programs on our system. -bret

[roryhewitt]

How about this (which is allowed in many other languages) in addition to the current SELECT - It wouldn't be too difficult...would it? "expression" could evaluate to a boolean value (true/false) or simply be compared with the WHEN value Rory <hr width=50 align=left>Code ('http://www.mcpressonline.com/mc/showcode@@.6b3ce3e5/30')

[Guest.Visitor]

I love free RPG and I think it is fun to code with as well. Having been an RPG programmer since the late 80's I feel free (sorry about that). On of its strengths I like about it is you can indent your loops etc which makes it easier to read. OK I know you can do the same with older RPG in the Code editor but I prefer to have it straight in front of me without having to change my view. As to the problem with semi colon's, its not an issue, as the more you use the syntax the more it will become an automatic action to add it at the end of every line. I also have spent the last five years programming notes applications as well as our RPG ones and with Free and RPGIV. I find it a lot easier to switch between laguages than I do if I hav to amend an older RPG400 or God forbid an RPG II source code one. So long live Free RPG and may it and RPGIV have a long supported future with IBM.

[Coda]

All I can say is, with all due respect, Wickedwoman and Modulator are nuts. I've been programming about as long as Mr. Robinson above. -Since the late 80's and although I don't quite fit in with the pocket protector set, I can crank out code faster with rpg4 than many of my counterparts can with free. I don't like the pseudo-free format of rpg free at all. Renegade? Nesting is severely limited with only 72 characters to work with. When SQL rpg came out, it was a welcome addition. Free is probably a step in the right direction, but not yet. I might be persuaded to change my mind if the really dumb things (see most of this thread for examples...) were corrected. Right now? Nah. Getting a program into the hands of the users under deadline and knowing it is easily maintainable and works as intended is far more important than using free. Of course, your mileage may vary and an opinion only matters to its owner. Just had to put in my two cents. Cheers,

[JonFParis]

<blockquote><tt>>> "I still don't understand why the free-form RPG compiler cannot be a little smarter - just like the Cobol compiler." </tt></blockquote> There are reasons why RPG probably can't be made "smarter" as easily as we'd like. Unlike COBOL RPG has no (or almost no) reserved words! It has never historically needed them. A field could have the same name as a operation code with no problem since the op-code went into its own "box". Dumb as it sounds there are large numbers of programs out there that have field names "READ" "WRITE" "OPEN" etc. etc. Some major packages include such fields. So - without some form of statement terminator how does the compiler determine when a new op-code (as opposed to field name) is encountered? When /free was introduced

[JonFParis]

<blockquote><tt>>> "I still don't understand why the free-form RPG compiler cannot be a little smarter - just like the Cobol compiler." </tt></blockquote> The COBOL compiler isn't any "smarter" - it requires either a scope delimiter (END-xxx) or a period _and_ has a large number of reserved words. If a field name can never be the same as a an op-code then it is pretty simple to be "smart". RPG has no (or almost no) reserved words. It has never historically needed them. A field could have the same name as an operation code with no problem since the op-code went into its own "box" and couldn't be confused. Dumb as it sounds there are large numbers of programs out there that have field names "READ" "WRITE" "OPEN" etc. etc. Some major packages include such fields. So - without some form of statement delimiter (semicolon in RPG) how would the compiler determine when a new op-code (as opposed to field name) was encountered?

[Terry Winchester]

Thanks for the explanation Jon :) I never realized that RPG had such a small list of reserved words! Terry

[R.Daugherty]

It is only reasonable when going to a free form compiler to mark off all keywords as reserved for obvious purposes of parsing. It was different when they were in reserved positions for opcodes and variables. So the free form compiler has reserved words and the fixed doesn't, good grief, to not do that because "RPG" didn't historically declare opcodes as reserved is not valid. Not when on the other hand things like move can be dropped because somebody didn't like it. It's not like anyone is forced to convert code with a variable named read into free form. So basically, IBM, just reserve the words and if they're out of place it's a compile error. People can't convert and compile code as is anyway so it shouldn't even be an issue. rd

[Guest.Visitor]

So basically, IBM, just reserve the words and if they're out of place it's a compile error. This will break backward compatibility of existing RPG programs, that were coded and already use some of these "keywords" you propose. Maybe you're talking about a compile time option? Chris

[R.Daugherty]

Chris, dropping move and add and sub broke backward compatability. And no, I wasn't suggesting a compile time option. Existing code is not backwards compatible in /free. rd

[Guest.Visitor]

Hi Ralph, No it didn't. IBM didn't deprecate or remove MOVE, ADD, SUB from /Free - those opcodes were never ever allowed in /Free from day 1. You can still compile an existing RPG program's source containing MOVE and ADD and SUB successfully without changing <u>anything</u> in the source code. Just a straight compile. IE: Programer added a new field to a record layout and the Change Management System has to recompile programs using that PF. What you are suggesting would break such programs. Imagine if a company has a PF named MOVEL in dozens of programs and suddenly MOVEL becomes are reserved word. Yikes! A straight recompile would fail under your proposal. Actually, our little debate doesn't matter - IBM won't do this. If they do someday, you can point me back to this thread and say "I told you so". I have no problem typing a ; at then end of an opcode expression, it's not a big deal. ;-) Chris

[R.Daugherty]

Chris, dropping move and add and sub broke backward compatability. Not sure how you could have read that as dropped "from /free" instead of as I wrote it, but you did. Also, I understand about inserting an /end free - /free around dropped code as apparently what you refer to as "you can still compile without changing anything". And no, I'm not going to imagine a company with a variable named movel in dozens of programs that decides to convert to /free, but can't figure out how to rename reserved words being used. So what if a reserved word is being used somewhere. So what if you do a rename for a compile error. Good grief, I hope IBM has more sense than that. rd

[R.Daugherty]

Just to clarify, reserved words in /free parsing obviously wouldn't apply to /end free, that is, existing code format, not that it would be any bigger deal if it did, but I'm not suggesting modifying fixed format compile logic, just /free parsing. rd

[tdaly@sddsystems.com]

Currently in free-form RPGLE each statement must end with a semicolon. This led me to believe that more than one statement could appear on a line, but this is not the case. The line end is an implied continuation. These rules are a tad annoying. It is easy to miss a semicolon. The forest of semicolons is just visual clutter. And it's extra typing. Following the adage of making the common cases easy and the hard or uncommon things possible, I'd like to see the following changes: *Multiple statements may appear on a line, provided that they are separated by a semicolon *A line end indicates a statement end, unless the statement is continued via a continuation character. The continuation character must unambiguously be a continuation character and not be mistaken for a concatenation or arithmetic character, as '+' or '-' would be. I think the comma would do the job nicely. Granted that in the examples shown in the code box the semicolons may not seem that bad, but when looking at many lines of code the semicolons become junk that I must consciously blot out. In my opinion these changes would lead to clearer, cleaner, less error prone code that is easier for the eyes to comprehend because it is more naturally read. And it eliminates typing all these 'noise' characters. Maybe IBM will solicit our opinions as they did in the past... give us "$100" to buy (vote for) various enhancements they were considering. I think that survey worked out well. Stepping down from soap box... Tom D. <hr width=50 align=left>Code ('http://www.mcpressonline.com/mc/showcode@@.6b3ce3e5')

[R.Daugherty]

I have no problem typing a ; at then end of an opcode expression, it's not a big deal. ;-) Oh, Chris, I just realized what you meant by that. Yes, I agree, I had nothing in mind about the COBOL without a period stuff, although there was the suggestion that statements be VB style without terminators. Java has reserved words and a ; statement terminator. I never considered reserved words as a reason for doing away with a terminator. I agree, no big deal, and actually, the standard. rd