Forth extension proposal RfDs and CfVs

[ About Forth 200x | Forth 200x draft documents | Other proposals | How to write an RfD ]

About Forth200x

There is a new Forth standardization effort underway. This page is about the proposals for extensions/changes, you can read more about other aspects of the standards effort on the Forth 200x page.

Forth-2012

The Forth-2012 document is now available. You can also look at it in HTML form at forth-standard.org. Gerry Jackson has written/collected a test suite for testing the compliance of systems with Forth-2012 (beyond our own tests).

We continue working after reaching this milestone.

Document Archive

There is a public archive of previous drafts. These documents are available as PDF and in some cases the LaTeX source is also available.

Recent RfDs

See below for older RfDs without CfVs. The above are the proposals on forth-standard.org since the 2017 meeting (when we decided that new proposals should be put there). Below you find RfDs that were started before that meeting.

Current CfV Standings

No current CfVs.

CfV results

Accepted at the 2017 Forth200x meeting

Accepted at the 2016 Forth200x meeting

Accepted at the 2015 Forth200x meeting

Proposals included in Forth-2012

Accepted at the 2014 Forth200x meeting

Accepted at the 2013 Forth200x meeting

Accepted at the 2012 Forth200x meeting

Accepted at the 2011 Forth200x meeting

Wording Changes

Accepted at the 2010 Forth200x meeting

Wording changes

Accepted at the 2009 Forth200x meeting

Wording changes

Accepted at the 2008 Forth200x meeting

Accepted at the 2007 Forth200x meeting

Accepted at the 2006 Forth200x meeting

Accepted at the 2005 Forth200x meeting

RfDs without CfVs

Shelved RfDs

Code

Tests or reference implementations are missing from some proposals (yet).

About the RfD/CfV process

There have been some thoughts about revising the standard. In order to do that, those in the standards committee should know what the system implementors and the programmers are already doing in that area, and what they would be willing to do, or wish for.

To do that, I am trying a system here that is somewhat like the RfD/CfV system for deciding about newsgroups: A proponent of an extension or change to the standard writes up a proposal; this proposal is then published here as an RfD (request for discussion), and others can then comment on the proposal; the proponent can modify the proposal, taking the comments into consideration, or he can ignore some of the comments (if that's a problem for the commenters, they can make a competing proposal, or somesuch).

Anyway, once a proposal has settled down, it enters the CfV (call for votes) stage, where system implementors state, whether their system implements this proposal, or what the chances are that it ever will. Similarly, programmers can state whether they have used stuff like that proposed, and whether they would use the proposed extension once it is standardized. After a deadline, a preliminary poll result will be published, but the poll will remain open for adding to the Web page (especially system implementors are invited to do that).

Proposals in the CfV stage are eligible for inclusion in the Forth200x standard, and many have been included already.

Related Processes

As mentioned above, this process was inspired by the RfD/CfV system that helps news admins decide which newsgroups they should provide on their Usenet news servers; the corresponding roles are:

A similar process, and closer in subject matter, is the SRFI (Scheme request for implementation) process for proposing extensions for the programming language Scheme.

Finally, Python has a similar mechanism: PEPs (Python extension proposal).


Anton Ertl