Make _ an anonymous value

[MeAmAnUsername]

Summary
Make _ an anonymous value

Todo

• Add tests
  • Update tests / create new tests for new requirements on _ as parameter name
  • SPT tests
    • Grammar
    • Static semantics
  • e2e tests
• Implement
  • Grammar
  • Static semantics
  • Notes & warnings
  • Code generation
• Document

Reason
Useful when destructuring a tuple and you don't need every value: val (_, result) = analyze(parse(file))

Description
Make it so _ is always a fresh variable, i.e. it cannot be referred to, but multiple variables named _ can be used.
If _ is used in a reference, it should give an error: "Cannot refer to anonymous value _. Use a named value instead."
If _ is used as parameter name in a foreign function (including methods and foreign tasks) for a qualified type (e.g. _: mb:common:result:Result), it is simply allowed. This is required because that is the only way to refer to a qualified value.
If _ is used as parameter name in a foreign function (including methods and foreign tasks) for an unqualified type (e.g. _: int or _: Result), it should emit a warning: "Anonymous parameter name can be omitted. Alternatively, the parameter can have a proper name."
If _ is used as parameter name for a PIE function, it should give a note for now, at least until #16 is implemented.
Note: "Anonymous parameter _ cannot be referred to but will be included in the generated task signature. If this is not required, this parameter can be removed. If this is intended, it is recommended to add a comment explaining why this is necessary. To refer to this parameter, use a different name."

Implementation

• Need to update Exp.ValDec to have a special case for anonymous values (no longer just TYPEID but either TYPEID or another value
• TYPEID = "_" {reject}
• Add Ref.AnonRef = [_] which gives an error.

Code generation: just generate a fresh variable for every declaration of an anonymous value. Use unused or anonymous for base name. Even better: do not assign to variable at all if not required (only case where it is required is for paramaters I guess)

Search terms
Underscore

Related issues
None

[MeAmAnUsername]

Increase priority because this is a breaking change, so it should be done before people actually use the PIE DSL.

[MeAmAnUsername]

Notes for implementation:

• Can just not make a declaration when the name is "_"
• TBD: is it better to distinguish this during parsing or still parse as TYPEID and catch it in Statix? (typeOfBind(.., Bind("_")) = ..)

[MeAmAnUsername]

Distinguish during parsing:
pros:

• Visible in AST
• Places where a TYPEID is allowed no longer accept _, so forgetting about it does not introduce bugs, just inferior errors.

cons:

• Makes grammar more complicated
• Statix spec will still have to be updated anyway

[MeAmAnUsername]

Turns out it should be VALID instead of TYPEID