[Note: This is work-in-progress for a proposal heavily inspired by similar mechanisms from other communities (see Related) and adapted to the needs of the Prolog language community.]
A PIP (Prolog Improvement Proposal) is a design document providing information to the Prolog community about the design and implementation of new developments related to the Prolog language, such as new features or libraries.
The purpose of this PIPs collection is to act as a indexed repository of language and system-specific proposals that may be of interests for the Prolog community, and to document interesting information regarding their benefits, inconveniences, support status, etc. PIPs also can serve as a link between systems, papers, implementors, researchers, and advanced users.
The purpose of a PIP and the responsabilities of its authors are:
Provide concise information about the rationale of the proposal and guidelines (including pointers to papers, documentation, discussions, reference implementations, or other documents, etc.).
Collect community input (both positive and negative) on particular issues.
Help distill, compare, evaluate, and share proposals. Encourage both new ideas as well as literature research.
When possible, ollaborate with formal standarization processes like ISO Prolog. This may cover changes to the ISO Prolog standard (for which there may not be consensus for standardization yet), implementation-specific details for some particular system, helping identify and commenting non-conformant proposals, or marking proposals as candidates for future extensions.
We consider the following types of PIPs:
meta: A PIP about the PIP repository, workflow, and governance (like this document).
feature: Describes a new language feature (which is typically implemented in the compiler or engine, and cannot be implemented by the majority of systems as a library).
library: Features that can be implemented as libraries.
A PIP is a text document (formatted in markdown) that must include a header with metadata about the proposal followed by the body of the proposal.
---
PIP: <PIP id>
Title: <Title>
Author: <authors>
Promoter: <authors or system promoting this PIP>
Discussions-To: <URL for discussion thread>
Status: <draft | abandoned | rejected | withdrawn | accepted | supported | superseded | replaced>
Supported: <system-ids that support it>
Type: <meta | feature | library>
Content-Type: text/markdown
Requires: <PIP numbers>
Conflicts: <PIP numbers>
Created: <date>
Replaces: <PIP number>
Superseded-By: <PIP number>
---This is a suggestion of PIP body:
# Abstract
# Motivation and Rationale
# Main section(s)
Describe the proposal, design impact, alternatives, related work. If needed clearly specify out-of-scope ideas.
# Implementation
Details for implementation. This may point to external documents or reference implementations.The copyright of the PIP is expected to be public domain. We encourage including an Acknowledgements section.
The process to include a PIP in this repository is the following:
Fork the PIPs repository.
Create a new markdown file with a descriptive name (e.g.,
0000-new-feature.md). Keep 0000 as PIP id
for now. PIP may contain additional files under the
0000-new-feature/ directory.
Submit your PIP via pull request (PR in GitHub) or merge request (MR in GitLab).
A lightweight review will check that the proposal satisfies
the requirements (like some evidence for support from a few Prolog
systems), and assign you a PIP number. Rename your file(s) and
update the PR/MR (e.g., 1234-new-feature.md,
1234-new-feature/).
The PIP will start with a draft status and
evolve as follows:
draft -> accepted: a majority of
systems agree on the idea or consider that the inconveniences have
been properly identified. Supporting the proposal does not
commit systems to implement them.
accepted -> supported: the
proposal has been implemented in at least one system different than
the original (use the supported header to document
it)
draft -> reject: after
discussions the author decides to reject the proposal (objective
rationale for it should be documented)
draft -> abandoned: the proposal
did not caused enough discussions for a decision.
accepted/supported ->
superseded/replaced: used to annotate that
some accepted or supported PIP has been superseded or replaced by
other (fill the appropriate header field too)
(TBD) People responsible for reviewing changes and moderate updates in the repository.