Now, when last we left our intrepid /Free heroes, they had just completed creating a simple but honest /Free program. Before we go on, let’s take a moment to review some of the things we have learned.

Editor's Note: This article is excerpted from chapter 5 of 21st Century RPG: /Free, ILE, and MVC, by David Shirey.

There are no C-specs in /Free. /Free code has logic statements, not C-specs.

Nothing ever goes into position 6.

Position 7 is reserved for the start of the /Free and /end-Free tags, which enclose /Free code and tell the compiler to look for it.

Unless you are on 7.1 TR7 or higher, in which case the tags are not required. At that level, the compiler is smart enough to recognize /Free on its own. More on that in a subsequent chapter.

/Free code statements start anywhere from position 8–80 and end with a semicolon ( ; ).

If you are on 7.3, then the 80-column limit is lifted, and you can go out as far as the 132-character restriction of the source file. This is nice and in line with Web languages, but I am not sure if it is really helpful. Do you enjoy reading text that goes beyond the bounds of the page you can see? If yes, you will like this; if not, maybe not.

The SETON opcode did not make it into /Free, so we must use *INLR = 1 to end a program.

Comments are delineated by // starting anywhere in columns 8–80, including after a valid logic statement.

MOVE was not brought over into /Free, and so EVAL is used to set values. This includes the use of EVAL-CORR and EVALR plus the h/m/r opcode extenders.

We also talked about how /Free makes it possible to indent code and how important that is in terms of being able to see the structure of the program at a glance. But we will see that more in this section.

And, most importantly, we all set up a model /Free program and used that to create a /Free program with a couple of EVALs in it. That was the funnest part.

Of course, if you have been programming for even a little while, you know that you can’t do too much with just EVAL statements. So this chapter will look at the control statements that /Free uses: things like the IF, SELECT, and DOU/DOW opcodes that allow you to control the flow through your program. Should be pretty interesting.

IF Statement Stuff

In its simplest format, an IF statement in /Free looks like this:

Obviously, if there were no ELSE clause, then you wouldn’t need to code it. Duh. The ENDIF, however, is required. No big surprise there. That’s the way we roll in the /Free world.

The semicolon after each statement: have I mentioned that yet? If you are into PHP programming, you will notice that this is different from PHP, where only the operational statements (for example, the 'CITY =' statements) would be ended by ';'.

And, as usual, capitalization or not of the IF, ELSE, ENDIF is up to you. The semicolon should never be capitalized, of course.

The indentation of the EVAL statements? That is something you don’t have to do. You could just line up every statement above as such:

But if you did, we would be forced to have the Style Police come and hit you with their tiaras. Indenting is the single biggest reason that I love /Free. It makes the code so much easier to read, and it’s just wonderful. Take full advantage of it, especially for nested IF statements.

ELSEIF Construct

You also have access to the ELSEIF clause. It basically allows you to combine an ELSE and a follow-on IF into a single level and so reduce the amount of indenting required.

The nice thing about using the ELSEIF construct is that you don’t need to figure out how many ENDIFs you have to key in. One will do it. Please note that this is not the way it is for normal nested IFs and ELSEs. There you need an ENDIF for each and every pair. Since I always miscount, using the ELSEIF saves me compile errors.

You Can’t Do This

Unfortunately, there is one thing you can’t do, and I always want to do this when I am coding in /Free. You cannot have multiple values for a single IF statement variable. That is, you can’t do this:

I repeat, you CAN’T do that. It would be nice if you could, but it doesn’t work. Instead, the correct way to do it is as such:

Please note also exactly where the semicolons are placed on the IF clause for this type of example.

More Complex IF Statements

But what if you want a little more complexity? What if one variable is not enough, if you follow my meaning (wink, wink, nudge, nudge)?

The parentheses are not required. The IF would work fine without them, processing ANDs first and ORs second. I like to use them, though. Makes it easier for me to see what goes together, and makes it harder for you to make a mistake with the syntax. Please use them as well—just in case I ever have to look at your code.

Columns or Not

I have a tendency to line up the conditions in columns. You could write it all out on one line, but I like the ability to put them vertically so they are easier to read. If you have condition lengths that are different, then you can insert blanks or whatever to line things up neatly. For example:

Or, if you like things strung out, you can do it like this; it’s up to you:

Either way, you should be sure to indent. That is where /Free really shines, in helping make those big nested IFs look a little more logical.

Comparison Operators

Not everything always breaks down to an “equals” situation, of course. There is “less than,” “greater than,” “almost not quite less than although if seen from some angles it might be greater than,” and lots of other things. And /Free makes a little change here from positional RPG.

Gone are the *LT, *EQ, *GE, and others.

Instead we go with a more mathematical syntax: >, <, =, >=, and so on. Using these, our example might look like this:

It is the final triumph of Intermediate Algebra.

Negative IF Statement

It’s generally always a good idea to be positive with IF statements. I mean, seriously, how many of us would say, “I don’t not want to not stop speaking to you” in casual conversation. And yet, that seems to happen with distressing frequency when you read other people’s code.

Good design principles encourage you to state your conditions from a positive rather than a negative point of view. Sometimes, however, it is more convenient to look at things from the negative side of the road (as in cases where you do something if the answer is negative, and do nothing if it is positive. So, how do you do that in /Free?

Well, one way is with the “not equal to” operator: <>.

Or, if you want to use a more alphabetically oriented syntax, you could use a NOT operator on a condition set up as an equality. The thing to remember using this option that it is best to put the thing(s) that you are NOT-ing in parenthesis. It is not a requirement, but it certainly makes it much easier to understand what is being negated. For example:

SELECT/WHEN

/Free also supports the use of a case structure, just as positional RPG does, but I think it looks more natural in /Free. I recommend using it (SELECT/WHEN) instead of nested IFs whenever you get a chance.

I like the SELECT statement; it reminds me of the Case structure command on the old IBM 8100. Anyone remember that machine? It was a kind of mainframe AS/400: simpler than CICS but with an integrated development environment and very programmer friendly. For some reason, after a fast start, it just sort of petered out. I think the release of the 4300 series might have had something to do with that. Plus, IBM was doing the marketing, so maybe it never had a chance.

Great machine, though.

Anyway, the SELECT statement is great when you have a number of options for your IF, and you want something that isn’t going to confuse you to death. I use it if I have more than two clauses for my IF. But I’m exceptionally easy to confuse. The format is quite simple:

The logical statements in the WHEN clause do not have to have anything in common. They don’t need to reference the same variable (although often they do). In addition, they can be as complex as you want them to be with logical operators and parentheses and even BIFs. For example:

The OTHER keyword is used alone (no conditional statement), and it is a catchall for things that don’t fit into one of the previous WHENs.

And—do I even need to say it at this point?—a semicolon at the end of every statement. Please, please try to keep up.

Want to learn more?  You can pick up Dave Shirey's book, 21st Century RPG: /Free, ILE, and MVC, at the MC Press Bookstore Today!