EXPRESSIONS

When we added expressions to the language we stated they could be used nearly anywhere a numeric variable was allowed. There have been some exceptions, but they are allowed nearly anywhere. Putting the parenthesis around the value simply made it an expression that was evaluated at run time and the result placed in a temporary variable.

As Steve mentioned in his posting this is actually and expression. Sunbelt has done a great job on allowing expressions to be used on a number of verbs.

     CALC FORM5=((FORM1*FORM2)+10) 
     SETLPTR VAR1,(FORM1-FORM2)
     BUMP VAR1,(FORM1*2)
     CALL RTN USING (FORM1*3/FORM3)
     SETPROP EditTx,ANCHOR=(FORM1+3)

Pretty much any place a numeric number is used an expresion can also be used. So in this example

     WS_CHILD DEFINE 1073741824
              CALL RTN USING (WS_CHILD)

Really gets compiled to

              CALL RTN USING (1073741824)

And the expression returns 1073741824 which gets passed into the RTN value.

As Steve mentioned this is probably a little slow (Actually I have never noticed a difference but I would think it would be milliseconds) but it is far more readable.

That clears things up a lot (I do remember wondering about this way back when we were using DATABUS).

So, a numeric value can be in these formats...

     FORM variable     [ fmWrk02 form 2 ]
     INTEGER variable  [ inWrk01 integer 1 ]
     DIM variable      [ dmWrk02 dim 2 ]
     literal           [ "12" ]
     immediate         [ 12 ]
     expression        [ (12) ]

...to be used in various situations depending on the requirements. Maybe, to find all the places where I CAN use immediate numeric values (since it's faster than literal values), I'll change from using literal numeric values to immediate numeric values and see what won't compile.

I seem to remember messing with EQUate before and ran into problems/limitations so I stopped using it. But I can't remember the details now.

It sounds like CONST is more flexible than EQU because it can be used where a FORM value is needed and it can be used where an immediate value is needed. (Would it be better for the PlbEqu.inc to be changed from using EQU to CONST values?)

One good application of EQU or CONST is to define a single numeric value that would be used both in an array definition (in the UDA) and also during array processing (in the code section).

       fmNdx        FORM    2
       ArrayMax    CONST "10"
           --or--
       ArrayMax   EQU      10
       Array         DIM     10(ArrayMax)
       for fmNdx from 1 to ArrayMax
           move fmNdx to Array(fmNdx)
       repeat

Thanks again Steve. (This kind of stuff would be very handy in the help file.) Also to Gerhard for his input. (I think, to pass the EQUated $ON/$OFF values as parameters, I'll use the paranthetical method for now.)

Now I need to get another question ready about 'fundamental' PL/B issues....

I like to comment on the ( ) also.

I use ( ) in most of my logic tests because it's much clearer. For example:

       IF OVER and EQUAL or EOS

is not as clear as

       IF ((OVER) & (EQUAL | EOS))

After all these years, do I understand that I can do:

       if (not equal and not eos)
       endif

instead of

      if not equal
          if not eos
          endif
      endif

I never realized I could test multiple flags at once... variables, yes, but I never thought about it for flags.....

As for readability, I like "and" and "or", just enough whitespace, like I would write in a sentence.. (like I did above)

You can even use function keys

        KEYIN ANS
        GOTO LAB1 IF (F1 | ANS="N")

But we goofed up many years ago and actual have a variable named F1

        F1 FORM 1

So the compiler rightly uses the variable before the flag in the expression.
We have also started to use the OVER in expressions

        LOOP
           READKS FILE1;EASS
        UNTIL (OVER | EASS!=PHSS) 

I recently learned that you can test for a nul string using "":

SPACE    INIT    " "                ;convenient variable
         MATCH   SPACE,NAME         ;test the old way
         IF EOS                     ;you get EOS if second variable is nul
            do something on nul
         ENDIF

         IF (NAME = "")             ;better, more readable way
            do something on nul
         ENDIF