,---------------. | Contributions | `---------------´ ,------------------------------------------ | 2018-09-21 06:49:42 PeterKnaggs wrote: | proposal - Revised Proposal Process | see: https://forth-standard.org/proposals/revised-proposal-process#contribution-71 `------------------------------------------ # Authors - Andrew Haley - Peter Knaggs - Leon Wagner - Gerald Wodni # Change Log - 14/09/2018 Text worked out in workshop at the 2018 Forth Standards Meeting # Problem Now that the proposal process has been moved onto [forth-standard.org](http://forth-standard.org) the **Proposal Process** no longer describes the process. # Solution Replace the **Proposal Process** in the front-matter of the document with a new process that correctly describes the revised process of proposing change via [this site](http://forth-standard.org). # Proposal Replace the text of the **Proposal Process** in the front-matter with the following: > ## Proposals Process > > This section documents the official process for submission of proposals > for changes to the standard. > > 1. A proponent of an extension to the standard writes a proposal > (*previously known as a request for discussion or RfD*). > > If the proposal only proposes the rewording of the document, > without requiring implementation changes, the proposal should be > published as a wording change (*previously known as a request > for comment or RfC*). > > 1. The proponent publishes the proposal on > [forth-standard.org](http://forth-standard.org) by contributing to > a word definition or chapter if applicable, or directly to the > [proposals](http://forth-standard.org/proposals) section. > > Be warned, this will generate a lot of heated discussion. > > In order for the results to be available in time for a standards > meeting, an proposal should be published at least twelve weeks > before the next meeting. > > 1. Proponents can submit updated proposals, taking any comments into > consideration, by replying to their own proposals and marking them > as new versions. > > 1. Once a proposal has settled down, the proponent submits it to the > committee for review by selecting the "Submit for review" button on > the proposal's web page. > > The committee reviews the proposal and either requests changes or > takes it to the next stage. For a simple change of wording the > proposal is frozen and considered at the next committee meeting. > For an extension proposal a poll is conducted (*previously known > as a Call for Votes or CfV*). > > The poll allows system implementors to state whether their systems > implement the proposal or if it ever will. The poll also allows > programmers to state whether they have used something similar to > the proposed extension and if they would use it once it is > standardized. > > The results of the poll are used by the standards committee when > deciding whether to accept the proposal into the standards document. > In order for the results to be available in time for a standards > meeting, the poll should be started at least six weeks prior to > that meeting. > > 1. A proposal is only accepted into the new document by consensus of > those members present at a standards meeting. If the proponent > cannot attend the meeting, they should ask somebody who is attending > to champion the proposal on their behalf. > > There are three possible outcomes from the committees consideration: > - If the committee feels the proposal has merit and wants to > encourage experimentation the committee can promote it to an > experimental proposal. > > - If the proposal is accepted, it is incorporated into the document. > The editor may request clarification from the proponent. > Any further discussion requires a new proposal. > > - If the proposal is not accepted, the committee may refer it back > to its proponents. > > Should a contributor consider their comments to have been dismissed > without due consideration, they are encouraged to submit a counter > proposal. > > ### The Proposal > > In the initial proposal, some issues could be left undecided, leaving > them open for discussion. These issues should be mentioned in the > Problem or Solution section as well as in the Proposal section. > > If you want to leave something open to the system implementor, make > that explicit, e.g., by making it implementation dependent. > > A proposal should include the following sections. > > **Author:** >> The name of the author(s) of the proposal. > > **Change Log:** >> A list of changes to the last published edition on the proposal. > > **Problem:** >> This states what problem the proposal addresses. > > **Solution:** >> A short informal description of the proposed solution to the problem >> identified by the proposal. >> >> This gives the rationale for specific decisions you have taken in >> the proposal (often in response to comments), or discusses specific >> issues that have not been decided yet. > > **Typical use:** (Optional) >> Shows a typical use of the word or feature proposed; this should >> make the formal wording easier to understand. > > **Proposal:** >> This should enumerate the changes to the document. >> >> For the wording of word definitions, use existing word definitions >> as a template. Where possible, include the rationale for the >> definition. > > **Reference implementation:** >> This makes it easier for system implementors to adopt the proposal. >> Where possible, the reference implementation should be provided in >> standard Forth. Where this is not possible because system specific >> knowledge is required or non-standard words are used, this should >> be documented. > > **Testing:** (Optional) >> This should test the words or features introduced by the proposal, >> in particular, it should test boundary conditions. Test cases >> should work with the test harness in Appendix >> [F](http://forth-standard.org/standard/testsuite). ,---------. | Replies | `---------´ ,------------------------------------------ | 2018-09-19 08:22:17 AntonErtl replies: | requestClarification - ALSO without VOCABULARY | see: https://forth-standard.org/standard/search/ALSO#reply-189 `------------------------------------------ ALSO works with FORTH EDITOR ASSEMBLER. I guess they wanted to provide ALSO even if they could not define VOCABULARY because of diverging practice. Do we have common practice for VOCABULARY now? If so, it could be standardized. ,------------------------------------------ | 2018-09-19 13:50:16 JennyBrien replies: | requestClarification - ALSO without VOCABULARY | see: https://forth-standard.org/standard/search/ALSO#reply-190 `------------------------------------------ I don't think vocabularies give anything wordlists don't, and wordlists are more flexible. Why have two stes of words to do the same thing? The most common name I've seen for the wordlist equivalent of ALSO is +ORDER ( wid -- add to search order) with -ORDER as a synonym of PREVIOUS. If you really need VOCABULARY you can define it: : VOCABULARY CREATE WORDLIST , DOES> -ORDER @ +ORDER ; ,------------------------------------------ | 2018-09-21 06:44:13 AtH replies: | requestClarification - ALSO without VOCABULARY | see: https://forth-standard.org/standard/search/ALSO#reply-191 `------------------------------------------ Vocabularies provide laconism. Wordlists clarify one implementation level under vocabularies. FORTH is still in the standard. ASSEMBLER and EDITOR are common practice and also vocabularies. It’s a good manner to provide portable and established way to create such words, as FORTH . If not, we can remove the word ALSO as well. Your reference implementation for VOCABULARY is a good start. I tweaked it to use only standard words: : VOCABULARY CREATE WORDLIST , DOES> @ >R GET-ORDER SWAP DROP R> SWAP SET-ORDER ;