FWD » Core Development » Base Language

Consider the following ABL program:

DEFINE VARIABLE d1 AS DATE NO-UNDO INITIAL 01/03-.
DEFINE VARIABLE d2 AS DATE NO-UNDO INITIAL 01022999.
DEFINE VARIABLE d3 AS DATE NO-UNDO INITIAL "01/02/03abc".
DEFINE VARIABLE d4 AS DATE NO-UNDO INITIAL "01/03-".
DEFINE VARIABLE d5 AS DATE NO-UNDO INITIAL "01022999".
DEFINE VARIABLE d6 AS DATE NO-UNDO INITIAL "abc".
DEFINE VARIABLE d7 AS DATE NO-UNDO INITIAL abc.
MESSAGE d1 d2 d3 d4 d5 d6 d7.

Compile this program in OE to r-code. Since compilation stops on the first error, comment out previous problematic lines (e.g., d6, d7) to test subsequent variables.

OE Behavior¶

1. d1: Correctly parsed as a date literal in MDY format, resulting in year=2025 (default), month=1, day=3.
2. d2: Correctly parsed as a date literal with a special MMDDYYYY format, resulting in year=2999, month=1, day=2.
3. d3: Correctly parsed as a date literal in MMDDYYYY format, resulting in year=2003, month=1, day=2.
4. d4: Equivalent to d1.
5. d5: Equivalent to d2.
6. d6: Compilation fails with errors 196, 342, and 85.
7. d7: Compilation fails with errors 198 and 247.

FWD Behavior¶

Convert the program with FWD (ensure the MESSAGE statement is included to avoid optimization):

1. d1: Recognized as a DATE_LITERAL by the lexer, correctly converted, cleaned to "01/03" by date.cleanFormattedDate (removing trailing "-"), generating TypeFactory.date(date.fromLiteral("01/03")).
2. d2: Recognized as a NUM_LITERAL by the lexer, incorrectly converted to TypeFactory.date(1022999), causing Java compilation failure.
3. d3: Recognized as a DATE_LITERAL, correctly converted, cleaned to "01/02/03" by date.cleanFormattedDate (removing "abc"), generating TypeFactory.date(date.fromLiteral("01/02/03")).
4. d4: Equivalent to d1, correctly handled.
5. d5: Equivalent to d2, incorrectly handled, causing Java compilation failure.
6. d6: Recognized as a STRING, incorrectly converted to TypeFactory.date("abc"), causing Java compilation failure.
7. d7: Conversion fails with "unexpected token: abc".

Note: FWD pre-processes date literals with date.cleanFormattedDate to remove extra characters, which may not be necessary if parsing is handled correctly during conversion.

Runtime Issue in FWD¶

After removing uncompilable variables (d2, d5, d6, d7) and re-converting, running the program in FWD prints ? for d1 and d4 instead of the expected year=2025, month=1, day=3. This occurs due to incorrect date parsing in FWD at runtime.

Proposed Fixes for FWD Conversion¶

The following issues must be addressed in FWD conversion:

1. Ensure correct recognition of date literals, or allow both number literals and strings to be treated as date literals in context.
2. Implement a date parsing procedure during conversion to validate and convert literals to date components (month, day, year).
3. Generate Java code using date creation based on components, e.g., date d1 = TypeFactory.date(new date(1, 3, 2025)), rather than relying on unparsed strings.
4. Avoid pre-processing literals with date.cleanFormattedDate, as this becomes redundant with proper parsing.
5. The code must use the updated date parsing procedure (this already solved in #9906).

Florin: Please add these cases to the lexer tests.

Florin added these tests to the ABLUnit lexer tests in the testcases revision 1750. For example, see tests/conversion/lexer/4gl_testcases/dates/valid/letters_in_date.p or tests/conversion/lexer/4gl_testcases/dates/valid/missing_year_date.p.

The failing cases are in ./4gl_testcases/dates/invalid/string_for_date.p and ./4gl_testcases/dates/invalid/invalid_date_letters.p.