LCGS syntax update proposal

[NicEastvillage]

Future work from 8th semester includes updates to the LCGS syntax in order to make it more consistent and less tedious. This issue is for discussing how that new syntax would look like. Let's first state the design goals:

• Remove inconsistent notation: Some declarations start with a keyword while others start with a variable name or other symbols. Our syntax should try to minimize the number of exceptions, e.g. by having all declarations start with a keyword.
• Tedious duplicate code: If label or update expressions depend on the same complex expression, then the only
  solution currently, is to copy the expression. This should be solved with a abstraction like functions or similar.
• (Extra) Only labels can be used in ATL: It would be nicer to express ATL queries if they could directly use the state variables in LCGS. This change to the ATL syntax would make the label declaration somewhat unnecessary unless we make it more versatile.

Initial proposal

I propose we update the syntax as follows:

• Replace labels with expr declarations.
  • These are values derived from the current state and do not have to be boolean.
  • They can be used in ATL queries like labels.
  • Can be used in other expressions reducing duplicate code (recursive definitions disallowed ofc).
  • They can have parameters, making them similar to functions.
• Add dynexpr declarations.
  • These are similar to expr declarations, but they are derived at transition-time, meaning they can use player actions in their definition.
• Add var keyword for variables, simply prepended to the current syntax
  • The var keyword plus space is conveniently 4 letters, which makes it align with an indented update expression.
• Add action keyword
  • Replaces the square brackets around actions names for more consistency
  • Action name and condition is instead separated by :
• Add explicit parameters to templates showing which identifiers must be relabeled
  • The characteristics of the parameters (e.g. whether it must be an identifier, or whether it must have certain fields) are infered for high versatility.
  • Whether relabeling is removed is TBD.

The Mexican Standoff would look like this with this proposed syntax:

const MAX_HEALTH = 2;

player billy = cowboy(clayton, jesse);
player clayton = cowboy(jesse, billy);
player jesse = cowboy(billy, clayton);

expr over = billy.dead + clayton.dead + jesse.dead >= 2;

template cowboy(target1, target2)
    
    var health : [0..MAX_HEALTH] init MAX_HEALTH;
        health' = max(health - target1.shoot_left - target2.shoot_right, 0);

    expr alive = health > 0;
    expr dead = !alive;
    expr something_with_params(a, b) = a * 2 > b;

    dynexpr hit = target1.shoot_left || target2.shoot_right;

    action wait : 1;
    action shoot_right : health > 0 && target1.health > 0;
    action shoot_left : health > 0 && target2.health > 0;

endtemplate

[NicEastvillage]

Another thing we should consider is the compatibility with future features. If we extend the tool it will probably be with weights and probability, so we should make sure the syntax can support these easily.

[NicEastvillage]

If you have suggestions for better names for the expr and dynexpr keyword I would like to hear, they are simply the best words I've found so far. dynexpr could also be tranexpr, actexpr, or expr' instead to emphasize that they are defined during transitions. PRISM-lang has a concept similar to expr called formula.

Another issue I have with my current suggestion is the use of : after the action name. In many modern languages and also in our variable declarations, : separates the name and the type of the name, but this is not the case for actions. Is there a better symbol? Or maybe we should just remove the : in variable declarations?

Relabeling is a very strong feature, but I don't know if we need it. Will it ever be used for anything that is not simply a parameter to the template?