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.

LEP Types

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.

  1. Creating a branch or fork of the repository and creating a copy of the template and put it in the corresponding language’s folder. Rename the prefix of the file to corresponding folder, but keep the xxxx numbering for the moment.

  2. Fill out the preamble. Stick with the Draft status at first.

  3. Describe your ideas in the remaining sections.

  4. Create a merge request to the master branch as soon as your draft is complete.

  5. 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.

  6. 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 Accepted or Final if no code changes are required.

    • If a LEP requires more triaging or research first, it may be set to Deferred.

    • Discussions can result in a LEP being Rejected or Withdrawn.

  7. Now the LEP is merged to master for future reference if it’s either Accepted, Rejected, or Final and thus are publicly visible. Withdrawn LEPs are not merged.

    • For Accepted LEPs, create an issue that outlines the work that needs to be done before its status can be set to Final.

  8. Implementation in all essential code repositories can lead to status Final if not already.

  9. Implementation of another LEP may result in status Obsolete if the LEP is superseded or no longer relevant.

So the life cycle becomes:

Schematic life of a LEP.

Figure 13 Schematic life of a LEP.

ESL0008 - Documentation comment tags LEP template