Subscribe for automatic updates: RSS icon RSS

Login icon Sign in for full access | Help icon Help
Advanced search

Pages: [1]
  Reply  |  Print  
Author Topic: Language Modernization ideas for discussion - Idea 4 - Richer operators  (Read 10354 times)
Eric B.
Posts: 10


« on: January 25, 2021, 11:42:21 pm »

Next idea:  Richer set of operators.  Adds support for the following operators: +=, -=, *=, /=, and IN.

For instance:
Code
  1. LET x = x + 1
is the same as
Code
  1. LET x += 1
This could be used with any of the normal math operators (+=, -=, *=, etc.).

IN is a shortened form of OR:
Code
  1. IF x IN ('Y','y') THEN...
is the same as
Code
  1. IF (x = 'Y' OR x = 'y') THEN...
Reuben B.
Four Js
Posts: 1119


« Reply #1 on: January 26, 2021, 04:01:28 am »

IN has also been discussed previously, https://4js.com/support/issue/?id=FGL-4238

I have never really understood why we have not implemented an IN(), after all it is SQL syntax that most 4gl developers are familiar with.  I would place BETWEEN, MIN, MAX in the same category as being available in SQL but not 4gl.  Over time we have added syntax from SQL such as nvl() and iif(), and who used to code sin(x) as SELECT SIN(x) FROM systables WHERE tabid = 1 before util.Math was added.  I am sure there are 4gl developers that have coded something they would code in SQL statement into a 4gl statement and been caught out.

A number of customers will have their own library functions that implement a list (many possible implementations such as delimited string, XML, JSON, DICTIONARY, ARRAY) and then have functions to create a list and to search within it.  For example

Code
  1. IF cust_state = "NY" OR cust_state = "CA" OR cust_state = "WA"
  2.  
I would have coded as
Code
  1. IF in(cust_state, list3("NY","CA","WA"))
  2.  
... the only downside being I was limited to however many listN functions I coded to construct a list with N elements unless I built my list one element at a time.


What is missing is a compelling argument to get IN over the line.

Your example is probably not the best ...

Code
  1. IF x IN ('Y','y')
  2.  
could be written as
Code
  1. IF x.toUpperCase() = "Y" THEN
  2.  
or
Code
  1. IF x MATCHES "[Yy]" THEN
  2.  


A better example is to say

Code
  1. IF expr() IN (val1(), val2(), val3(), ...)
  2.  

as to code it like ...
Code
  1. IF expr() = val1() OR expr() = val2() OR expr() = val3()
  2.  
... sees expr() evaluated multiple times and val1(), val2() and val3() always evaluated (unless OPTIONS SHORT CIRCUIT is turned on)

To code it so each expression is only evaluated once is something like ...

Code
  1. CASE expr()
  2.   WHEN val1() LET l_in = TRUE
  3.   WHEN val2() LET l_in = TRUE
  4.   WHEN val3() LET l_in = TRUE
  5.   OTHERWISE LET l_in = FALSE
  6. END CASE
  7. IF l_in ...

and being able to code

Code
  1. IF expr() IN (val1(), val2(), val3(), ...)
  2.  
and
Code
  1. CASE expr()
  2.   WHEN IN(val1(), val2(), val3()) ...
  3.  
is preferable

So if you have a better example, that will help the cause.

Reuben







Product Consultant (Asia Pacific)
Developer Relations Manager (Worldwide)
Author of https://4js.com/ask-reuben
Contributor to https://github.com/FourjsGenero
Rene S.
Four Js
Posts: 112


« Reply #2 on: January 28, 2021, 03:26:24 pm »

Implementing operators like += should not be a big deal. Those operators are very common.

The operator IN is another story.
Yes, this operator could be helpful, the operator exists in SQL for good reasons.

But. See Reuben's example using the operator IN in a CASE statement:

Code
  1. CASE expr()
  2.    WHEN IN(val1(), val2(), val3()
  3.  

This this the simplified grammar of the CASE statement:
Code
  1. CASE expr { WHEN expr [statement ...] } ... [OTHERWISE [statement ...]] END CASE
  2.  

When parsing
Code
  1. WHEN IN(val1(), val2(), val3()
  2.  
Then the compiler would not see the operator IN, the compiler would seen the function name IN.

Compare this with
Code
  1. CASE some_value
  2.    WHEN "foo" -- acts as some_value == "foo"
  3.    WHEN "bar1" OR "BAR2" -- acts as some_value = ("bar1" OR "BAR2"), this is legal nonsense
  4.    WHEN func1() -- acts as some_value = func1()
  5.    WHEN IN(val1, val2) -- acts as some_value = IN(val1, val2) -- IN is a function name
  6.    WHEN MATCHES "pattern" -- syntax error
  7.    WHEN < "zzzz" -- syntax error
  8.  

All I want to say is: the operator IN does not solve the request for enhancing the CASE statement to support more than one value per WHEN.

(Edited to transpose CASE and WHEN which had been typed the wrong way around)








 
« Last Edit: February 02, 2021, 10:18:26 pm »
Pages: [1]
  Reply  |  Print  
 
Jump to:  

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines