Forth extension proposal RfDs and CfVs
[ About Forth 200x
| Forth 200x draft documents
| Other proposals
| How to write an RfD ]
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.
document is now available. You can also look at HTML versions:
(will become Web 2.0-capable in the future) and
HTML version. Gerry Jackso has written/collected
suite for testing the compliance of systems with Forth-2012
(beyond our own tests).
We continue working after reaching this milestone.
There is a public archive of previous drafts.
These documents are available as PDF and in some cases the
LaTeX source is also available.
See below for older RfDs without CfVs.
Current CfV Standings
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
- Multi-tasking Block Buffers (included in the "ed11" changes in the document)
Accepted at the 2010 Forth200x meeting
Accepted at the 2009 Forth200x meeting
Accepted at the 2008 Forth200x meeting
Accepted at the 2007 Forth200x meeting
Accepted at the 2006 Forth200x meeting
Accepted at the 2005 Forth200x meeting
Tests or reference implementations are missing from some proposals
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.
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:
- news servers - Forth systems
- news admins - Forth system implementors
- Usenet posters and lurkers - Forth programmers
A similar process, and closer in subject matter, is the SRFI (Scheme request for
implementation) process for proposing extensions for the programming
Finally, Python has a similar mechanism: PEPs (Python extension