ANSI Standard PL/B Language and Visual PL/B
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!
if you find errors or omissions or have a better way to do something. TELL US! Dialog helps us all. Send e-mail to: email@example.com
This is a PRELIMINARY
Based on a discussion from the Sunbelt web board in April 2004
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.
CALL RTN USING (FORM1*3/FORM3)
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"
ArrayMax EQU 10
Array DIM 10(ArrayMax)
for fmNdx from 1 to ArrayMax
move fmNdx to Array(fmNdx)
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)
if not equal
if not eos
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
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
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
IF (NAME = "") ;better, more readable way
do something on nul