Language Enhancement Proposals Reference¶
Our languages’ concepts and changes each are set in stone in a Language Enhancement Proposal (LEP), inspired by the PEP system for Python. They describe the reasoning and functionality and form a reference for all the language’s implementations.
LEPs serve as the basis for our languages and therefore require technical specifications. LEPs are proposed and managed within a versioned repository, which also serves as the way of tracking their revision history. Each contains an abstract, rationale, technical functionality and concise examples section.
We adopt three types of LEPs:
- Standard (S)
LEPs that describe a new feature or implementation.
- Informational (I)
LEPs that don’t describe any new feature, but rather state how the language and tools should be used. Think code style and tool guides.
- Governance (G)
LEPs for governing the LEP system and language evolution. These are usually only applicable for this general category.
Each LEP is pre-fixed by the abbreviation or extension of the language name (e.g. ESL for Elephant Specification Language), and suffixed with a number (e.g. ESL0001 for the first). These numbers are assigned indefinitely. Anything regarding LEPs in general is prefixed with LEP (e.g. LEP0001 for the first).
Life of a LEP¶
Proposing a LEP slightly differs from Python PEP’s structure, as our organizational structure differs as well.
Creating a branch or fork of the repository and creating a copy of the
templateand put it in the corresponding language’s folder. Rename the prefix of the file to corresponding folder, but keep the
xxxxnumbering for the moment.
Fill out the preamble. Stick with the
Draftstatus at first.
Describe your ideas in the remaining sections.
Create a merge request to the
masterbranch as soon as your draft is complete.
If the basic checks succeed on formatting and style (including Gitlab-CI), the reviewer may assign a number to the LEP.
Early mistakes or objections up to this point may result in the deletion of the LEP without further administration.
This is the point where discussion on the contents of the LEP start and need to be resolved.
Resolving all discussions can lead to the status
Finalif no code changes are required.
If a LEP requires more triaging or research first, it may be set to
Discussions can result in a LEP being
Now the LEP is merged to
masterfor future reference if it’s either
Finaland thus are publicly visible.
WithdrawnLEPs are not merged.
AcceptedLEPs, create an issue that outlines the work that needs to be done before its status can be set to
Implementation in all essential code repositories can lead to status
Finalif not already.
Implementation of another LEP may result in status
Obsoleteif the LEP is superseded or no longer relevant.
So the life cycle becomes: