Why I hate the Concatenate operator...

[David H.]

If you run the following program:-

Code (genero) Select Expand

MAIN

   DEFINE my_int INTEGER
   DEFINE my_str STRING

   LET my_int = 100
   LET my_str = NULL

   --With USING
   DISPLAY "1=TESTA" || my_int USING "<<<<<<<&"
   DISPLAY "2=TESTB", my_int USING "<<<<<<<&"

   --With NULL
   DISPLAY "3=TESTA-" || my_str || "-"
   DISPLAY "4=TESTB-", my_str , "-"

END MAIN

The output is:-

0
2=TESTB100

4=TESTB--

Ideally I'd like "||" to behave like ",", but I guess you'll say that is not going to be an option... Alternatively, could we have an alternative character for ",", so that I can write:-

Code (genero) Select Expand

FUNCTION my_func()

     DEFINE a,b,c STRING
   
     RETURN a+b+c

END FUNCTION

For me, "," was a bad choice of operator as RETURN a,b,c has two meanings!

Cheers,

David

[Sebastien F.]

David,

Actually the || concatenation operator was introduced by Informix 4gl, and comes from Informix SQL:

> select '1' || '2' + 3 from systables where tabid=1;
(constant)         
15.0000000000000000
1 row(s) retrieved.

In 4gl it has the same behavior (order of precedence / effect of NULL):

main
    define x int
    let x = '1' || '2' + 3
    display x
end main

displays 15....

Seb

[Reuben B.]

I gave up trying to remember the semantics of || and , and used SFMT https://4js.com/techdocs/genero/fgl/devel/DocRoot/User/Operators.html#OP_SFMT when that came out.  Was it 1.20?

Code (genero) Select Expand

FUNCTION my_func()

     DEFINE a,b,c STRING

         
     RETURN SFMT("%1%2%3",a,b,c)

END FUNCTION
and

Code (genero) Select Expand

--With USING
   DISPLAY "1=TESTA" || my_int USING "<<<<<<<&"
   DISPLAY "2=TESTB", my_int USING "<<<<<<<&"
   DISPLAY SFMT("?=TESTC%1", my_int USING "<<<<<<<&")

   --With NULL
   DISPLAY "3=TESTA-" || my_str || "-"
   DISPLAY "4=TESTB-", my_str , "-"
   DISPLAY SFMT("?=TESTC-%1-", my_str)



I found the strings were much easier to read rather being a mess of quotes and commas i.e.

SFMT("SELECT %1 FROM %2 WHERE %3", select_clause, from_clause, where_clause)

[David H.]

Hi Seb,

Thats just about what I expected you'd say! Lets forget about || for a second (although the behaviour with USING is still weird for me..). What do you think about the feasibility of an alternate character for the comma operator, so it can be used in RETURN statements.

Whilst we are on the subject of SQL functionality making it into 4GL. I'd like to see NVL() and some kind of inline IF statement, i.e. IFF(expression,truevalue,falsevalue) added at some point too...

Cheers,

David

[Sebastien F.]

The nice thing with the comma concat operator is that elements are formatted, compared to ||.

We have in mind to do something like CONCAT(a,b,c).

I will add a request for NVL(expr,default) and IF(expr,trueval,falseval).

Seb

[David H.]

Hi Reuben.

Yes like you we do use SFMT() a lot, and its been a great addition to the language. The only downsides being it can get confusing which argument is which when you have more than a few (i.e. which one is %8?).

Also if you want to spread the quoted text of multiple lines to improve readability then you still end up using || or "," . Which brings me to something else I noticed:-

Code (genero) Select Expand

MAIN

  DEFINE my_int INTEGER
  DEFINE my_str STRING

  LET my_int = 100
  LET my_str = NULL


  DISPLAY SFMT("a=this is a test",
               " of a multiline string: %1",my_int USING "<<<<<<<&")

  DISPLAY SFMT("b=this is a test",
               " of a multiline string: [%1]",my_str)

  DISPLAY SFMT("c=this is a test" ||
               " of a multiline string: %1",my_int USING "<<<<<<<&")

  DISPLAY SFMT("d=this is a test" ||
               " of a multiline string: [%1]",my_str)


END MAIN

gives:-

a=this is a test
b=this is a test
c=this is a test of a multiline string: 100
d=this is a test of a multiline string: []

:-)

David

[Rene S.]

Hello,
about the NVL operator: I would like to suggest another option: the runtime could easily treat any NULL value in expressions as zero (if numeric) or empty (if String) . This could be controlled by an FGLPROFILE entry (system wide) or by a pseudo statement (like WHENEVER). This idea comes from a 4gl language being used in Germany. This language has the same problem with NULL values in expression. This language has solved this problem (as I remember well) with two configuration parameters: NULLEXPRESSIONS - treat a NULL value as zero or empty in expressions - and NULLVALUES - don't use NULL values at all in the program.

This still allows to assign NULL to any variable, On the other hand, any expression would behave more intuitive.
Rene

[David H.]

Hi Rene,

That would be great for us, as we never want a NULL somewhere in an expression to make the entire expression NULL and have to continually code around this...

Cheers,

David

[Sebastien F.]

Maybe we need both a NVL() operator and what Rene suggested.

My instinct is that we'll have customers not willing to use the global configuration flag, to keep legacy code working as today.
I could bet that there are some lines of code relying on the current || expression evaluation resolving to NULL if one item in the expression is NULL, and then insert the result in the database...

Seb

[David H.]

Hi Seb,

Yes, I'd agree that both options would probably be best to cover all the bases.

Regards,

David

[Neil M.]

If you run the following program:-

Code (genero) Select Expand

MAIN

   DEFINE my_int INTEGER
   DEFINE my_str STRING

   LET my_int = 100
   LET my_str = NULL

   --With USING
   DISPLAY "1=TESTA" || my_int USING "<<<<<<<&"
   DISPLAY "2=TESTB", my_int USING "<<<<<<<&"

   --With NULL
   DISPLAY "3=TESTA-" || my_str || "-"
   DISPLAY "4=TESTB-", my_str , "-"

END MAIN

Brackets help ( not sure why exactly ):

Code (genero) Select Expand


   DISPLAY "1=TESTA" || (my_int USING "<<<<<<<&")

Result:
1=TESTA100

I like the idea of additional fglprofile parameters to control the 'NULL problems'

Regards,
Neil

[David H.]

Brackets help ( not sure why exactly ):

Code (genero) Select Expand


   DISPLAY "1=TESTA" || (my_int USING "<<<<<<<&")

Result:
1=TESTA100

Thats an interesting discovery! Presumably because they alter the evaluation order...

[Sebastien F.]

Sorry I should have mentioned this before in this thread:

The order of precedence of the || operator is higher as USING:

https://4js.com/techdocs/genero/fgl/devel/DocRoot/User/Operators.html#PRECEDENCE_LIST

So when you write:

Code (genero) Select Expand

  LET x = a || b USING "<<<"

It is equivalent to:

Code (genero) Select Expand

  LET x = (a || b) USING "<<<"

Seb

Brackets help ( not sure why exactly ):

Code (genero) Select Expand


   DISPLAY "1=TESTA" || (my_int USING "<<<<<<<&")

Result:
1=TESTA100

Thats an interesting discovery! Presumably because they alter the evaluation order...

[Reuben B.]

The nice thing with the comma concat operator is that elements are formatted, compared to ||.

We have in mind to do something like CONCAT(a,b,c).

I will add a request for NVL(expr,default) and IF(expr,trueval,falseval).

Seb

I used to have a nvl() and if() in our libraries in my previous job.


The 1996 version of our nvl is available in the IIUG software repository

FUNCTION nvl(l_original, l_if_null)
DEFINE  l_original                     CHAR(80),
        l_if_null                      CHAR(80)

    IF LENGTH(l_original) = 0 THEN
        RETURN l_if_null
    ELSE
        IF l_original[1]="$" THEN   # Cope with money fields
           LET l_original[1]=" "
        END IF
        RETURN l_original
    END IF

END FUNCTION

... I am sure when we generoised we would've switched to STRINGs  (ScottN can share the 2009 version if he wishes).

The if would've been something like

FUNCTION if(a,b,c)
DEFINE a SMALLINT -- colud use BOOLEAN Genero 2.2 on
DEFINE b,c STRING
   IF a THEN
      RETURN b
   ELSE
      RETURN c
   END IF
END FUNCTION

and used in things like

LET increment = if(x.sort_order = "Asc",1, -1).

The downside is that both sides of the expression are evaluated.  So it is suitable for the above example where b,c are constants but not so suitable for

CALL if(x.mode = "insert", insert_record(), update_record())

The thing with these simple library functions like this is if that a number of existing customers have them then there is an argument then we should include them in the language so that any new developers do not need to recreate them from scratch and have that functionality from day one, the negative is that existing customers may already have those functions as different names, or similar functions with the same name. 

[Reuben B.]

Hello,
about the NVL operator: I would like to suggest another option: the runtime could easily treat any NULL value in expressions as zero (if numeric) or empty (if String) . This could be controlled by an FGLPROFILE entry (system wide) or by a pseudo statement (like WHENEVER). This idea comes from a 4gl language being used in Germany. This language has the same problem with NULL values in expression. This language has solved this problem (as I remember well) with two configuration parameters: NULLEXPRESSIONS - treat a NULL value as zero or empty in expressions - and NULLVALUES - don't use NULL values at all in the program.

This still allows to assign NULL to any variable, On the other hand, any expression would behave more intuitive.
Rene

to play devils advocate again, what would DATE, DATETIME evaluate to?