Cadence Language Formal Specification

[j1010001]

Why (Objective)

Formal language specification serves as an authoritative guide for its implementation and usage which benefits the maintainers of the language and the developer community that uses it.

More specifically, the benefits are:

1. Consistency in Implementation builds trust - the spec makes it easier for maintainers to implement for new platforms/environments & for developers to rely o predictable behaviour.
2. Language Evolution -
3. Productivity of the language implementation - spec make it faster to optimize the implementation and fix bugs as the maintainers don't need to second-guess the original intention behind the existing implementation.
4. Foundation for Dev tools - develop tools like compilers, debuggers, interpretters and static analyzers is easier to do for maintainers. Similarly, spec makes it easier to build tools like IDEs, auto-complete, linting, error-checking tools etc, making the devs using the language more productive and their code less error-prone.

How will we measure success (Key Results) ?

• Cadence Formal Specification draft becomes the authoritative source for the Cadence language behaviour, that the Cadence engineering team can start adding to.
• Define & clarify future milestones
• 100% of the language is covered by the draft outline of the spec

Estimate

Scope:

• Complete outline for the spec.

• Review existing language reference and transfer to spec, so hat the spec can become the authoritative source for reviewing the implementation behaviour.

• Stretch ? Update existing EBNF grammar (derived from Antler grammar): https://github.com/onflow/cadence/blob/master/docs/cadence.ebnf

DACI

Role	Assigned
Driver	technical: @jsproz, EM: @j1010001
Approver	@dete
Consulted	@turbolent, @SupunS
Informed	@Kay-Zee, Flow Engineering team