FWD » Core Development » Base Language

Statements like:

def var i as int.
i = 99-. /*this fails*/
message i.

will fail with error:

Rule Type :   WALK
Source AST:  [ 99- ] BLOCK/ASSIGNMENT/ASSIGN/EXPRESSION/NUM_LITERAL/ @2:5 {227633266708}
Copy AST  :  [ 99- ] BLOCK/ASSIGNMENT/ASSIGN/EXPRESSION/DEC_LITERAL/ @2:5 {227633266708}
Condition :  putNote("oldtypeStr", prog.num_literal)
Loop      :  false
--- END RULE REPORT ---

Strangely enough this works in 4GL and the variable will be assigned the negative number -99

Update looks good, this is going through conversion regression testing now.

Please test with these cases too:

def var i as int.
def var i64 as int64.
def var d as dec.

i = 9-.
i64 = 999999999999999-.
d = 1.99992-.

Greg: if we use the "1.2-" as a dec literal in a d = 1.2- assignment, the parser converts it as a date_literal. Should we fix this now too ?

We must be very careful here.

def var d1 as date init 1.2-.
def var d2 as date init 1.12-.
message d1 d2.

Both of these are valid date literals, at last when used in the init clause. BUT they are also BOTH valid decimal literals and Progress handles this based on context. Outside of the init clause, it seems that the 4GL may limit this syntax somewhat. We can reduce the potential problems by testing the months and only triggering this "conflict" when the "months" are 1 through 12. But we will still have issues.

We already do some "morphing" of initializer types. This may be a place where we have to do that again.

But I don't want to mix all this work together with the current problem. It is very sensitive. We will work it later.

The coding changes look OK. Moving the sign to the left was what I was going to propose. Make sure you remove the extra printfln() in cleanup.rules.

I'm OK with it. Put it through conversion testing.

Has passed conversion regression testing (no changes in generated sources), please check in and distribute.

Commited to bzr as revision number 10220.

We have a case where the 999.99- literal is converted to new date("999.99-") instead of decimal:

book.price = 999.99-.
d = 999.99-.

book.setPrice(new date("999.99-")); /* compile error */
d.assign(new date("999.99-"));

The lexer cannot easily change its behavior in response to feedback from the parser. This is a core limitation of ANTLR and is caused by the fact that the lexer has its own lookahead and is called in an unpredictable pattern which by its nature is often well ahead of what is being processed in the parser. By the time we know in the parser that the DEC_LITERAL is a top-level rvalue being assigned to a VAR_DATE, it is too late.

But there is a much simpler solution. We can implement bounds checking on the month and day fields, such that only a small number of overlapping cases are wrong.