Syntax strings versus literal strings

There are a number of very important differences between syntax strings and literal strings, which I will attempt to highlight for you here.

Firstly, the Uniface definition of a syntax string...

Uniface enables you to determine if the data in a string value matches a desired pattern using syntax strings.  A syntax string is a group of characters and syntax codes enclosed in single quotation marks (').

So that's the first big difference right there, literal strings are in double quotes (") and syntax strings are in single quotes (')...

  literalString = "Literal string"

  syntaxString = 'Syntax string'

A syntax string is used for pattern matching, but they are much more simplistic than the regular expressions that you might be used to in other languages.  The syntax codes are quite straight forward...

• # - one digit (0-9)
• & - one letter (A-Z, a-z)
• @ - one letter, digit or underscore (A-Z, a-z, 0-9, _)
• ~& - one extended letter
• ~@ - one extended letter, digit or underscore
• ? - one ASCII character
• A-Z - that letter, in uppercase
• a-z - that letter, in uppercase or lowercase

On top of these are a few other syntax codes of note...

• If you want to search for the literal version of a syntax code, eg. you want to search for the hash character (#) not a digit (0-9), then you can escape the syntax code using % before it.  Therefore, to search for a hash character it would be '%#' and to search for a percentage character it would be '%%'.
• If you want to search for a unknown number of syntax code, eg. you want to search for 2 or more digits, then you can use * after it.  Therefore, to search for 2 or more digits it would be '###*' - in this case the first two hash characters represent one digit each, and the third hash character is part of the the syntax code '#*', which means zero or more (0-n) digits.
• If you want part of the pattern to be optional (to match the pattern or blank) then you can put rounded brackets around it, using ( and ).  For example, '##(#)' would match with 2 or 3 digits (but not more than 3).
• Any other character is treated literally as that character.  

Uniface also gives a handy function that can be used to convert a literal string into a syntax string, sensibly named $syntax...

  syntaxString = $syntax("Literal string")

This can be especially useful if you're storing the pattern in the database, or some other configuration.

Here are a few examples from the Uniface manuals...

Proc with Syntax String	Result
if ('#' = "123") if ('#*' = "123")	FALSE TRUE
if ('#*' = vValue) if ('#*' = "%%vValue")	TRUE TRUE
if ('&###' = "1234") if ('@###' = "1234")	FALSE TRUE
if ('?' = "A") if ('??' = "A") if ('??*' = "A") if ('?' = "ABC") if ('??*' = "ABC")	TRUE FALSE TRUE FALSE TRUE
if ('(#(-))&&&' = "ABC") if ('(#(-))&&&' = "1ABC") if ('(#(-))&&&' = "1-ABC") if ('(#(-))&&&' = "12ABC")	TRUE TRUE TRUE FALSE

I've had (occasionally heated!) discussions with developers before, when they have said that...

  if ( myVar = "Y" )

...and...

  if ( myVar = 'Y' )

...are interchangable.  

Yes, I can see that the pattern 'Y' only matches with the string "Y" and nothing else, but they are entirely different ideas, and should not be used interchangeably.  If you want to only match with "Y", then use the literal string "Y", because that's what you mean.  

In my experience, developers who say that these are interchangable are developers who don't understand what the differences are.

Summary: Syntax strings are very useful for pattern matching, but very different than literal strings.  Know the difference, and know when to use which.

Boolean values in an if statement

Last week I wrote a post about casting in if statements, focusing on the difference between equality and identity.  Well that post started out in my mind as being about boolean values, but then I found I needed to cover that ground first.

Boolean is a rather interesting datatype in Uniface.  The description in the manuals goes like this....

The Boolean data type is interpreted as either TRUE or FALSE. An empty value, and the values 0, F, f, N, and n are interpreted as FALSE. All other values are interpreted as TRUE. 

The Uniface default packing code for boolean stores the value as "T" or "F", but a number of different packing codes can be used...

• B - Optimum DBMS Boolean default
• B1 - ASCII Boolean (0 or 1)
• B2 - ASCII Boolean (F or T) *Uniface default
• B3 - ASCII Boolean (N or Y)
• B4 - Binary Boolean (0 or 1)
• B5 - Binary Boolean (0 or -1)

This means that it is always safest to reference a boolean in an if statement without a relational operator, like this...

  variables

    boolean b

  endvariables

  if ( b )

    putmess "b is True"

  endif

  if ( !b )

    putmess "b is False"

  endif

As empty values are interpreted as false, this example would output "b is False".

This is fine, as long as you know that you've got a boolean datatype.  However, I've seen developers get into trouble when they use this type of if statement (without a relational operator) but with other datatypes.

For example, to check a blank string in javascript, you could easily do something like this...

  var s = "";

  if(!s) {

    alert "s is blank";

  }

If you translate this directly into Uniface, then you get something like this...

  variables

    string s

  endvariables

  s = ""

  if ( !s )

    putmess "s is blank"

  endif

And this works, no problem here.  Empty string is interpreted as false and you get the same result.

Consider this though; what if s is set to "0"?  

In javascript, we would not get the alert - this is because the string is not blank, so quite right!  However, in Uniface we do get the message saying that s is blank, even though it's not.  This is because "0" is interpreted as false.

Summary: In an if statement, if you've got a boolean datatype then don't use a relational operator, but if you've got any other datatype then do use one.

Are "if" statements breaking or non-breaking?

An interesting feature in Javascript is the ability to improve the performance of your "if" statements using a technique known as breaking, or sometimes shortcutting.  This is where you have multiple parts to the condition, which are specifically ordered.  You can use the "&" and "|" (bitwise) operators which do not shortcut, or "&&" and "||" (logical) operators which do shortcut.  For example...


    a = 1;
    b = 2;
    c = 3;
    d = 4;
    if ( a==b & c==d ) alert("true"); //bitwise
    if ( a==b && c==d ) alert("true"); //logical


The first "if" statement is working out that a does not equal b and thinking of this as 0, then working out that c does not equal d and thinking of this as 0, then working out that 0 and 0 is 0, therefore false and no alert appears.  


The second "if" statement is working out that a does not equal b and thinking of this as false, then stopping.  I knows that if the first part of the condition is false then anything after that is always going to result in false, so it breaks (or "shortcuts") and no alert appears.


I won't go into the difference between bitwise and logical, because this is a Uniface blog and not a Javascript one.  Suffice to say, in this situation they almost always behave the same, because 0 equates to false and 1 equates to true.  The important thing to note is the difference in whether they shortcut or not. 


A question I've wanted to know for a long time but never stopped to work out... Does Uniface shortcut when processing "if" statements?  Time to find out!


First I tested to see if there was a difference between "&" and "&&" in Uniface.  I'd noticed that both worked the way I expected logically, but never determined the difference.  The way I did this was with the following two blocks of code...

• &

      count = 0

      total = 10000

      while ( count < total )

        count = count + 1

        if ( 1 = 0 & $itemnr(-1,list_field.dummy) = "" )    

          ;testing the condition itself

        endif

      endwhile

• &&

      count = 0

      total = 10000

      while ( count < total )

        count = count + 1

        if ( 1 = 0 && $itemnr(-1,list_field.dummy) = "" )    

          ;testing the condition itself

        endif

      endwhile

I then populated the non-database "list.dummy" field with a list of 20,000 items.  As you may have read in one of my earlier posts, accessing the last item in a large string held in a non-database field is a relatively costly thing to do, certainly compared with referencing a numeric value.  This means that I expect the first part of the condition to process much quicker than the second part of the condition.

I won't give you the timings, it was quite boring, they both behaved exactly the same.  There was no difference between the timings, even when I upped the number of iterations from 10,000 to 1,000,000.  

I then moved on to trying to determine whether or not the second part of the condition was being processed or not, by also testing the following blocks of code...

• False

      count = 0

      total = 10000

      while ( count < total )

        count = count + 1

        if ( 1 = 0 & $itemnr(-1,list.dummy) = "" )    

          ;testing the condition itself

        endif

      endwhile

• True

      count = 0

      total = 10000

      while ( count < total )

        count = count + 1

        if ( 1 = 1 & $itemnr(-1,list.dummy) = "" )    

          ;testing the condition itself

        endif

      endwhile

Now these results I did find interesting...

• False = 01:07.31, 01:08.92, 01:07.30 (just over a minute)
• True = 01:49.12, 01:50.31, 01:49.52 (almost 2 minutes)

This means that Uniface is definitely shortcutting, which is great!  This means that performance can be gained by ordering the parts of the condition carefully.  Of course you could argue that you could split this up to achieve the same affect, like this...

      if ( 1 = 0 )    

        if ( $itemnr(-1,list.dummy) = "" ) 

          ;testing the condition itself

        endif    

      endif

I wouldn't have a leg to stand on, you'd be right.  However, what about "or" instead of "and"?  In this case, if the first part is true then there's no need to process the second part, because you already know that the final result will be true also.  Again, you could split it up like this...

      if ( 1 = 0 )    

        ;testing the condition itself

      elseif ( $itemnr(-1,list.dummy) = "" ) 

        ;testing the condition itself

      endif

...but this would mean duplicating whatever code was inside the "if" statement, and it's not nearly as readable as a single "if" statement.  So I tried again, but this time with "|" instead of "&"...

• False = 01:49.51, 01:49.08, 01:49.84 (almost 2 minutes)
• True = 01:07.02, 01:08.22, 01:07.19 (just over a minute)

Again, this means that Uniface is definitely shortcutting, which is great!  I expected the results to be opposite (true to be faster than false) because the logic of "and" and "or" are opposite (well, sort of, technically "and" and "exclusive-or" are, but we won't go into that!). 

Of course, if you had three or four or five parts, this could mean even greater performance gains could be achieved by thinking carefully about which part you put first.  Any function which you might use in a condition, like $length or $scan should always be used in later parts if possible.

Summary: There is no difference between "&" and "&&" or "|" and "||" as far as I can tell, but Uniface does shortcut when there are multiple parts to the condition in an "if" statement, therefore you should think careful about the order of the parts.