At the time of writing, the Mellifera language is implemented by two separate interpreters, the Go implementation in mellifera.go + cmd/mf/mf.go, and the Python implementation in mf.py. The behavior of the language is informally specified and validated for both interpreter implementations using the collection of golden tests under the tests directory. However, these golden tests are non-exhaustive, and do not contain any formalization of the language behavior apart from examples.
The goal with this ticket is to begin drafting a language specification that will formally describe the syntax and semantics of Mellifera. I am interested in the idea of an executable specification, specifically a language specification that we can feed an interpreter into and get a 👍 or 👎 on whether the interpreter satisfies the behavior described by that specification document. Ideally this would be the most juiced up version of the golden testing we already do, but with additional ways of expressing must and should requirements. I am thinking that each section could have runnable code examples that will individually test (and more importantly demonstrate to someone reading the spec) the behavior being described.
This specification doesn't need to be some fancy LaTeX document. In fact it would be better if we could jam the entire thing is a single SPECIFICATION.md or similar so that it is accessible to contributors and easy to transform into an online webpage. Ideally, if we can get the Go implementation running in the browser with #2, then we could make the whole specification runnable in a browser.
The specification should document both the behavior of the core language, as well as the behavior of all built-in standard library functions. The specification can certainly be a living document, but it might be better to (1) get #2 implemented so we can build the executable specification right from the start, and (2) wait until the language and standard library is a bit more stable just so there isn't a bunch of work that gets ripped out in the future.
At the time of writing, the Mellifera language is implemented by two separate interpreters, the Go implementation in mellifera.go + cmd/mf/mf.go, and the Python implementation in mf.py. The behavior of the language is informally specified and validated for both interpreter implementations using the collection of golden tests under the tests directory. However, these golden tests are non-exhaustive, and do not contain any formalization of the language behavior apart from examples.
The goal with this ticket is to begin drafting a language specification that will formally describe the syntax and semantics of Mellifera. I am interested in the idea of an executable specification, specifically a language specification that we can feed an interpreter into and get a 👍 or 👎 on whether the interpreter satisfies the behavior described by that specification document. Ideally this would be the most juiced up version of the golden testing we already do, but with additional ways of expressing must and should requirements. I am thinking that each section could have runnable code examples that will individually test (and more importantly demonstrate to someone reading the spec) the behavior being described.
This specification doesn't need to be some fancy LaTeX document. In fact it would be better if we could jam the entire thing is a single
SPECIFICATION.mdor similar so that it is accessible to contributors and easy to transform into an online webpage. Ideally, if we can get the Go implementation running in the browser with #2, then we could make the whole specification runnable in a browser.The specification should document both the behavior of the core language, as well as the behavior of all built-in standard library functions. The specification can certainly be a living document, but it might be better to (1) get #2 implemented so we can build the executable specification right from the start, and (2) wait until the language and standard library is a bit more stable just so there isn't a bunch of work that gets ripped out in the future.