FWD » Core Development » Base Language

Conversion for ATTR_POLY used in complex expressions fails, as the ExpressionConversionWorker can't determine the type. i.e:

def var h as handle.
message "something" + h:buffer-field("field"):buffer-value.

Need to test with all type of expressions (logical, int, dec, date, etc), not just char concatenation.

More, the runtime needs to be fixed as in 4GL, following is valid (entire discussion at #1992, comments 18 to 23):
CA:

> def var i as int.
> function func0 returns char.
>    return "1000".
> end.

> /* i = func0(). this is compile-time error */
> i = dynamic-function("func0"). /* this executes and sets i to 1000 */
> message i.
> 

Idea is, if we have the ATTR/METH_POLY in an expression or as a rvalue, then 4GL does some automatic conversion of the "poly" rvalue to the lvalue's expected type. I know that for DYNAMIC-FUNCTION we disambiguate the return type based on the function's real return type, but this case that the lvalue can be assigned a not-compatible type.

GES:

It seems like we will have to do the following:

1. Test the limits/capabilities of the 4GL polymorhpic return transformations, especially in regard to assignments. I suspect there are real limits in what silent conversions are allowed.
2. Determine our exposure and plan for a resolution. My hope is that the 4GL has a standard set of conversions and we can implement those in each wrapper's constructor that takes a BaseDataType (which you recently added for dynamic-function return values). Then we can wrapper any assignment of a *_POLY rvalue with the proper constructor.

The problem I was working (in #1655) is the same problem. I "fixed" it by eliminating the use of expressionType() in 2 places in where_clause.rules. But that "fix" won't work everywhere. It did get me further in code but then I hit this ATTR_POLY issue again, deeper in the directory.

Here are the details:

.../supp/ocoreex0.p
EXPRESSION EXECUTION ERROR:
---------------------------
cls = expressionType(this)
      ^  { Unknown ATTR_POLY with oldtype of KW_BUF_VAL }
---------------------------
ERROR:
java.lang.RuntimeException: ERROR!  Active Rule:
-----------------------
      RULE REPORT      
-----------------------
Rule Type :   WALK
Source AST:  [ IF ] BLOCK/PROCEDURE/BLOCK/INNER_BLOCK/BLOCK/STATEMENT/KW_IF/KW_ELSE/INNER_BLOCK/BLOCK/STATEMENT/KW_ASSIGN/ASSIGN/EXPRESSION/LPARENS/FUNC_POLY/ @2216:51 {97117800506153}
Copy AST  :  [ IF ] BLOCK/PROCEDURE/BLOCK/INNER_BLOCK/BLOCK/STATEMENT/KW_IF/KW_ELSE/INNER_BLOCK/BLOCK/STATEMENT/KW_ASSIGN/ASSIGN/EXPRESSION/LPARENS/FUNC_POLY/ @2216:51 {97117800506153}
Condition :  cls = expressionType(this)
Loop      :  false
--- END RULE REPORT ---

        at com.goldencode.p2j.pattern.PatternEngine.run(PatternEngine.java:732)
        at com.goldencode.p2j.convert.ConversionDriver.processTrees(ConversionDriver.java:948)
        at com.goldencode.p2j.convert.ConversionDriver.back(ConversionDriver.java:852)
        at com.goldencode.p2j.convert.ConversionDriver.main(ConversionDriver.java:1729)
Caused by: com.goldencode.expr.ExpressionException: Expression execution error @1:7 [FUNC_POLY id=97117800506153]
        at com.goldencode.p2j.pattern.AstWalker.walk(AstWalker.java:226)
        at com.goldencode.p2j.pattern.AstWalker.walk(AstWalker.java:160)
        at com.goldencode.p2j.pattern.PatternEngine.apply(PatternEngine.java:1119)
        at com.goldencode.p2j.pattern.PatternEngine.processAst(PatternEngine.java:1017)
        at com.goldencode.p2j.pattern.PatternEngine.run(PatternEngine.java:704)
        ... 3 more
Caused by: com.goldencode.expr.ExpressionException: Expression execution error @1:7
        at com.goldencode.expr.Expression.execute(Expression.java:430)
        at com.goldencode.p2j.pattern.Rule.apply(Rule.java:401)
        at com.goldencode.p2j.pattern.Rule.executeActions(Rule.java:640)
        at com.goldencode.p2j.pattern.Rule.coreProcessing(Rule.java:609)
        at com.goldencode.p2j.pattern.Rule.apply(Rule.java:440)
        at com.goldencode.p2j.pattern.Rule.executeActions(Rule.java:640)
        at com.goldencode.p2j.pattern.Rule.coreProcessing(Rule.java:609)
        at com.goldencode.p2j.pattern.Rule.apply(Rule.java:440)
        at com.goldencode.p2j.pattern.RuleContainer.apply(RuleContainer.java:531)
        at com.goldencode.p2j.pattern.RuleSet.apply(RuleSet.java:50)
        at com.goldencode.p2j.pattern.RuleContainer.apply(RuleContainer.java:531)
        at com.goldencode.p2j.pattern.RuleSet.apply(RuleSet.java:50)
        at com.goldencode.p2j.pattern.AstWalker.walk(AstWalker.java:213)
        ... 7 more
Caused by: java.lang.UnsupportedOperationException: Unknown ATTR_POLY with oldtype of KW_BUF_VAL
        at com.goldencode.p2j.convert.ExpressionConversionWorker.expressionType(ExpressionConversionWorker.java:811)
        at com.goldencode.p2j.convert.ExpressionConversionWorker.expressionType(ExpressionConversionWorker.java:317)
        at com.goldencode.p2j.convert.ExpressionConversionWorker.expressionType(ExpressionConversionWorker.java:701)
        at com.goldencode.p2j.convert.ExpressionConversionWorker$ExpressionHelper.expressionType(ExpressionConversionWorker.java:1048)
        at com.goldencode.expr.CE10196.execute(Unknown Source)
        at com.goldencode.expr.Expression.execute(Expression.java:336)
        ... 19 more

I wonder if ExpressionConversionWorker should ignore these _POLY cases ? And determine the expression type based on the other operands in the expression ? Problems would be only if there are only _POLY in the entire expression.

Yes, it does seem to resolve the problem in raam/. Now we get a different error (see #1985).

I believe this is passing conversion testing.

The following diffs are present:

1580c1580
<          return concat("INVALID SO #.  PLEASE ENTER SO # >= ", valueOf(fInputsFrame.getSCoNum()));
---
>          return concat("INVALID SO #.  PLEASE ENTER SO # >= ", valueOf(fInputsFrame.getScreenValue(fInputsFrame.widgetSCoNum())));
1608c1608
<          return concat("INVALID EMPLOYEE #.  PLEASE ENTER EMPLOYEE # >= ", valueOf(fInputsFrame.getSEmpNum()));
---
>          return concat("INVALID EMPLOYEE #.  PLEASE ENTER EMPLOYEE # >= ", valueOf(fInputsFrame.getScreenValue(fInputsFrame.widgetSEmpNum())));
1636c1636
<          return concat("INVALID DATE.  PLEASE ENTER DATE >= ", valueOf(fInputsFrame.getSDate()));
---
>          return concat("INVALID DATE.  PLEASE ENTER DATE >= ", valueOf(fInputsFrame.getScreenValue(fInputsFrame.widgetSDate())));

Somehow, the improved expression typing changes the INPUT FUNC_POLY processing. As far as I know, these are equivalent statements, so I think it is OK.

Constantin: what do you think?

I have checked this code into bzr as revision 10206. If this is a regression, then I will fix it tomorrow and check in another update.

From #1985:

ra/ folder fails with:

.../ra/echrgad3.p
WARNING: no type calculated for BUFFER-VALUE in [127813931767083] BUFFER-VALUE [ATTR_POLY] @1441:99

EXPRESSION EXECUTION ERROR:
---------------------------
op1 = ecw.expressionType(copy)
          ^  { PLUS cannot have op1 (null). }
---------------------------
ERROR:
java.lang.RuntimeException: ERROR!  Active Rule:
-----------------------
      RULE REPORT
-----------------------
Rule Type :   WALK
Source AST:  [ + ] BLOCK/PROCEDURE/BLOCK/STATEMENT/KW_IF/KW_THEN/INNER_BLOCK/BLOCK/STATEMENT/KW_ASSIGN/ASSIGN/EXPRESSION/PLUS/PLUS/ @1443:28 {127813931767037}
Copy AST  :  [ + ] BLOCK/PROCEDURE/BLOCK/STATEMENT/KW_IF/KW_THEN/INNER_BLOCK/BLOCK/STATEMENT/KW_ASSIGN/ASSIGN/EXPRESSION/PLUS/PLUS/ @1443:28 {127813931767037}
Condition :  op1 = ecw.expressionType(copy)
Loop      :  false
--- END RULE REPORT ---

        at com.goldencode.p2j.pattern.PatternEngine.run(PatternEngine.java:732)
        at com.goldencode.p2j.convert.ConversionDriver.processTrees(ConversionDriver.java:948)
        at com.goldencode.p2j.convert.ConversionDriver.back(ConversionDriver.java:836)
        at com.goldencode.p2j.convert.ConversionDriver.main(ConversionDriver.java:1729)
Caused by: com.goldencode.expr.ExpressionException: Expression execution error @1:11 [PLUS id=127813931767037]
        at com.goldencode.p2j.pattern.AstWalker.walk(AstWalker.java:226)
        at com.goldencode.p2j.pattern.AstWalker.walk(AstWalker.java:160)
        at com.goldencode.p2j.pattern.PatternEngine.apply(PatternEngine.java:1119)
        at com.goldencode.p2j.pattern.PatternEngine.processAst(PatternEngine.java:1017)
        at com.goldencode.p2j.pattern.PatternEngine.run(PatternEngine.java:704)
        ... 3 more
Caused by: com.goldencode.expr.ExpressionException: Expression execution error @1:11
        at com.goldencode.expr.Expression.execute(Expression.java:430)
        at com.goldencode.p2j.pattern.Rule.apply(Rule.java:401)

      ASSIGN OcQUeryString = "WHERE rntpropchgs.pr-seq-no = " + STRING(prhst.pr-seq-no)
                           + " AND rntpropchgs.rnttrn-cde = " + QUOTER(IhInputTTBuf:BUFFER-FIELD("rnttrn-cde"):BUFFER-VALUE)
                           + " AND rntpropchgs.str-dte = " + IhInputTTBuf:BUFFER-FIELD("str-dte"):BUFFER-VALUE
                           + " AND rntpropchgs.crt-dte = " + IhInputTTBuf:BUFFER-FIELD("crt-dte"):BUFFER-VALUE
                           + " AND rntpropchgs.crt-tim = " + IhInputTTBuf:BUFFER-FIELD("crt-tim"):BUFFER-VALUE NO-ERROR.

Passed conversion testing and is checked in as bzr revision 10211. Runtime recursion testing is deferred.

A new context analysis problem has been found in #1985 (see note 63). The 2nd operand of the PLUS is a FIELD_DEC type. The ExpressionConversionWorker code for PLUS (in both expressionType() and contextAnalysis()) needs to be reviewed as the possible source of the issue.

Passed conversion testing and checked in as bzr revision 10230.

Passed conversion testing and checked in to bzr as revision 10239.

The ExpressionConversion worker needs to treat the cases when a _POLY is used in a logical test, as in:

def var h as handle.

if h:buffer-value then message "a".

if not h:buffer-value then message "a".

if h:buffer-value or not h:buffer-value then message "a".

if h:buffer-value and not h:buffer-value then message "a".

The strange thing is that I already put in support for all of these cases. I guess it is not working properly. I will look into it.

I'm not sure the problem is in the ECW. Actually, there is never any attempt to call the ECW for these cases. If I understand your concern, it is because the results in these cases are not cast to a logical type?

Hmm... on a second thought, this is similar to the DMO setter case... it should wrap the _POLY/DB_NON_REF in a logical instance, because this is what it expects.

Yes, I'm thinking about what is the right solution here. I wonder if I should make the previous solution (the extra boolean flag for expressionType() used in the DMO setter solution) more general purpose. The idea is that anything that will return a BaseDataType will be reported as BaseDataType instead of having the type inferred. I'm working on it now. Let me know if you have any concerns.

FUNCTION getDate RETURN DATE: RETURN 12/31/2050. END.
FUNCTION getDateTime RETURN DATETIME: RETURN 2050-12-31T10:30:21.555. END.
FUNCTION getDateTimeTz RETURN DATETIME-TZ: RETURN 2050-12-31T10:30:21.555-11:00. END.

DISPLAY DYNAMIC-FUNCTION("getDate") EQ 12/31/2050 /* prints yes, evidently */
        DYNAMIC-FUNCTION("getDateTime") EQ 12/31/2050 /* prints yes */
        DYNAMIC-FUNCTION("getDateTimeTz") EQ 12/31/2050 /* prints yes */.

DISPLAY 2050-12-31T10:30:21.555 GT DYNAMIC-FUNCTION("getDate")  /* prints yes */
        2050-12-31T10:30:21.555 EQ DYNAMIC-FUNCTION("getDateTime") /* prints yes, evidently */
        2050-12-31T10:30:21.555 LT DYNAMIC-FUNCTION("getDateTimeTz") /* prints yes */.

/* DISPLAY 2050-12-31T10:30:21.555 GT 12/31/2050. -- won't compile */

DISPLAY DYNAMIC-FUNCTION("getDate") EQ  DYNAMIC-FUNCTION("getDate") /* prints yes, evidently */
        DYNAMIC-FUNCTION("getDateTime") LT  DYNAMIC-FUNCTION("getDate") /* fails dynamically */ NO-ERROR.

• comparing statically a date and datetime literals is impossible without casting one of them. We can compare only compatible types.
• if one operator has a static value whose type is known at compile time and the other is a _POLY value than Progress silently inserts a casting function to the dynamic one so the runtime value will be converted to the known type (if possible/if the appropriate conversion is available). This is why 2nd and 3rd expression are first converted to DATE (dropping time information) prints "yes" and the 4th in which the 2nd operand will use 0 mtime after conversion to datetime.
• if both operands are obtained dynamically (_POLY values) then no conversion is performed at compile nor at runtime, if the values are static compatible they are processed as in 1st case, otherwise the "Incompatible data types in expression or assignment. (223)" error will break the execution.

As far as I know, only the issue in note 24 remains open for this task.

I believe that most of the problem in this case will be solved by implementing the _POLY constructors in #2287. However, the conversion may still need to be updated to properly detect and wrap the DYNAMIC-FUNCTION return value in the right constructor such that the _POLY code can be triggered. I believe we already mostly handle this (the ExpressionConversionWorker is heavily involved in this type/wrapping determination), but we may not handle all cases noted above.