We need parse expression like here:

x = 12 + 9 * ( 2 + otherFunc(1 + 7 * 3, 4 + 5) )

correctly ( we need remember about braces and operators importance ex ( '*' > '+' ) ), for that case we should generate assembler like here:

pushi    3
pushi    7
mul      
pushi    1
add      
pushi    5
pushi    4
add      
call     otherFunc
pushi    2
add      
pushi    9
mul      
pushi    12
add      

I added tests for that task. You should look for tests named CorrectlyPassBasicExpression and CorrectlyPassComplexExpression. After implementing that feature tests should pass without problems

As discussed on Discord we'd like to add support for a built-in type 'bool' which can only be inhabited by true/false.

Improvements:

• We would like programmers to increase their compile-time expressiveness by asserting that a certain variable can only be inhabited by true or false.
• Expressions using boolean operators such as ==, && or ! will produce a boolean value.

Problems:

• The values 'true' and 'false' are already defined as constants in Daedalus (with the value 1 and 0 respectively). We can probably just ignore their definition.
• Just like in C, statements of the form if (intVar) are used quite frequently. We need to accept passing integers into places where a boolean expression is expected, otherwise we break too much code.
• Conversely, booleans will need to be implicitly converted to integers as well, to support code that is currently using integers as a replacement for booleans, e.g. if (intVar == true), where converting intVar to boolean would be incorrect.
• If we want to enforce some stricter typechecking, we need an explicit way to convert a boolean into an integer. For now we can provide a built-in function to do so, which becomes a NOP during bytecode creation. For compatibility reasons a daedalus equivalent can be introduced when working with other compilers.

Open Questions:

• Do we allow implicit conversion from int to bool when providing parameters for a function? I'd like not to, but this will make refactoring a whole lot more annoying, having to change foo(intVar) to foo(intVar != 0) everywhere. On the other hand, this will make refactoring a lot easier because the compiler will yell at places you have forgot to change/refactor.

Here are some examples, including my thoughts on what should happen internally/at the type level.
Examples:

• if (intVar == True) True is promoted to an integer, using True = 1 and False = 0.
• if (intVar) Because if-statements expect a boolean value, the integer has to be conceptually converted to a boolean with C-like semantics, i.e. 0 => False, everything else => True. We don't have to change anything, though, because that is what Gothic already does anyway.
• intVar = True; This should maybe throw a warning or error only in strict mode and convert implicitly in non-strict/compatibility mode.
• boolVar = 0; this should always throw an error, because the bool datatype is already opt-in, i.e. we have no legacy code to consider.

Please post any additional thoughts you have and I will try to keep the OP updated.

complex* prefix add not needed complication in gramma rules and in our code, we should remove that prefix

Inside of execBlock we can have scope, during resolving of variables we should use scope field of execblock

soon more info, needs discussion if we want evaluate const expressions or generate for them assembly instructions

Using class DatFile from src/DaedalusCompiler/Dat/ to load and save .dat files produces binary that differs from the original. In addition to that, it doesn't seem to work properly - the game complains about missing startup script (presumambly STARTUP.D).

Hello. Could you add the path to the file or the name of the function where the compiler finds the error? It would be very convenient. Using the example of GothicSourcer. I tried using Russian scripts and looking for where he found the error or something else.

I first thank you for your work, I really appreciate the effort you put into this.
I use it in VSCode as built for my Gothic 2 Sources and it works great.
I encounterd a minor issue. ControlCharacters may lead to Token recognition errors.
I got into this when I freshly setup my PC. So the compiler should run without error against the "original" Gothic 2 sources. But I got an error. In DIA_VLK_439_Vatras.d line 566 unrecognized token. Well it turns out for whatever reason in the sources there is a FF (FormFeed) at position 1, after deleting the compiler ran without errors. I changed my VSCode settings to make CC visible. Anyway maybe you want to ignore these CCs.

Best regards

Ikarus (for example) introduces functions like _^, _@, _@s. Without adjustment, the compiler will fail to recognize them.

Daedalus.G4 fragment piece (newly added SpecialCharacters)

fragment IdStart : GermanCharacter | SpecialCharacters | [a-zA-Z_];
fragment IdContinue : IdStart | Digit;
fragment GermanCharacter : [\u00DF\u00E4\u00F6\u00FC];
fragment SpecialCharacters : [@^];

nameNode, referenceNode, assigmentOperator can be lexer elements ( maybe more elements can be lexer rules, need checking )

Now addOperator can be '-' or '+'. We should leave addOperator as a '+' and add new extra parser rule, subtractionOperator = '-'

Is it possible for you to allow Comments to be rendered out into the Tree?
I have some problems with Array-Constants and with the AI_output function.

I need to do some workaround, to work with that currently.