MMCC's PL/B notes     Notes home     Intro     History     Article index v1.10

Mid-Michigan Computer Consultants, Inc. 509 Center Bay City, Michigan Sales (989) 892-9242             Support (989) 686-8860 ANSI Standard PL/B Language EXPRESSIONS NOTE TO OUR READERS This web resource is written for our own use. But we feel strongly that the PL/B language should be shared with the software community. So feel free to use this at will! BUT PLEASE... if you find errors or omissions or have a better way to do something. TELL US! Dialog helps us all. Send e-mail to: support@mmcctech.com

EXPRESSIONS

This is a PRELIMINARY discussion. Based on a discussion from the Sunbelt web board in April 2004

Steve White:

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.

Gerhard Weiss

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.

Stuart Elliott

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....

Paul Fuh

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))

Jim Kovalsky

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)

Gerhard Weiss

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) 

Stephen Kent

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