Boolean default value in optional AST properties

[JanikNex]

Hey everyone,
I have encountered a problem with a current project and wanted to ask if this is intentional behavior.
In that case, maybe you know how I can deal with it.

For demonstration purposes I have greatly simplified my grammar to the following:

grammar MML

entry Model:
    (elements+=Attribute)*;

Attribute:
    'attribute' name=ID ('=' (defaultValue=(STRING | NUM | DOUBLE | BOOL)))?';';

hidden terminal WS: /\s+/;
terminal BOOL returns boolean: /true|false/;
terminal DOUBLE returns number: NUM '.' NUM;
terminal NUM returns number: /[0-9]+/;
terminal STRING returns string: /"[^"]*"/;
terminal ID returns string: /[a-zA-Z_][\w_]*/;


hidden terminal ML_COMMENT: /\/\*[\s\S]*?\*\//;
hidden terminal SL_COMMENT: /[^:]\/\/[^\n\r]*/;

Possible attribute definitions would therefore be, for example:

attribute u;
attribute s = "Test";
attribute i = 4;
attribute d = 4.2;
attribute t = true;
attribute f = false;

In the generated TypeScript, defaultValue is declared as defaultValue?: boolean | number | string.
I would expect defaultValue to be set to undefined in TypeScript if the optional AST property is NOT set.
However, instead the variable is set to false by default.
This causes the following two cases to be indistinguishable.

attribute u;
attribute f = false;

Is this the desired behavior, and if so, how can I distinguish whether a defaultValue has been set or not?

[msujew]

Yes, that feature is working as intended, although it might make sense to revise it for terminals. The issue is that language features using the boolean flag assignment feature (i.e. isExtern?="extern") require this auto assignment to false.

We usually wrap the terminals inside of Expression objects (that can be undefined) for this kind of language feature. See the langium-lox example language.

[JanikNex]

Yes, that feature is working as intended, although it might make sense to revise it for terminals. The issue ist that language features using the boolean flag assignment feature (i.e. isExtern?="extern") require this auto assignment to false.

Thanks for the quick reply, yes in my search I first found the pull request where you discussed the issue for the ?= operator. For my case I didn't expect that behavior though.

We usually wrap the terminals inside of Expression objects (that can be undefined) for this kind of language feature. See the langium-lox example language.

Through your tip with langium-lox I was able to adjust the grammar analogously, so that it now works as expected.
The whole approach has now even the advantage that I can determine the value type by the generated isStringExpr(), etc. easier than by typeof.

grammar MML

entry Model:
    (elements+=Attribute)*;

ValueExpr: NumberExpr | StringExpr | BoolExpr;
NumberExpr: value=(NUM | DOUBLE);
StringExpr: value=STRING;
BoolExpr: value?='true' | 'false';

Attribute:
    'attribute' name=ID ('=' defaultValue=ValueExpr)?';';

hidden terminal WS: /\s+/;
terminal DOUBLE returns number: NUM '.' NUM;
terminal NUM returns number: /[0-9]+/;
terminal STRING returns string: /"[^"]*"/;
terminal ID returns string: /[a-zA-Z_][\w_]*/;


hidden terminal ML_COMMENT: /\/\*[\s\S]*?\*\//;
hidden terminal SL_COMMENT: /[^:]\/\/[^\n\r]*/;

[msujew]

For my case I didn't expect that behavior though.

Understandable, though it's not easy to differentiate between ?= and terminal X returns boolean in our type system, since we lose that information (as of now). It might make sense to track it to provide better optionality information about properties.