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
- IS
- Multi-tasking Block Buffers (included in the "ed11" changes in the document)
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
Shelved RfDs
Code
Tests or reference implementations are missing from some proposals
(yet).
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:
- 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
language Scheme.
Finally, Python has a similar mechanism: PEPs (Python extension
proposal).
Anton Ertl