Problem
=======

The basis document, as published, is too heavily based on the original
ANS document. The first two parts of the proposal update appendix B to
include reference to the ANS and ISO standards. Much of appendix B need
to be updated, but I will leave that to the interested parties.

The front matter refers too directly to the ANS procedure. Parts 4 and 5
replace the front matter with material more appropriate to the aim of
the document. Part 5 is a description of the RfD/CfV procedure for
including proposals into the basis document / revised standard.

Finally part 6 is a copy of the minutes from the first standards
meeting. Whether this should be included in the basis document, let
alone in the front matter is a topic of debate. Can we simply leave this
on the web site, or do we need a printed record. Is there any ware else
we can publish the minutes? JFAR or the ACM are both possibilities.

Proposal
========

1) Remove the last line of the second paragraph in Appendix B.

"Several members of the Forth Standards Team have also
been members of the X3J14 Technical Committee."

2) Add the following to the end of the "Industry standards" section
of Appendix B.

The following standards where developed under the control
of the ANSI. The committee drawing up the ANSI standard
included several members of the Forth Standards Team.

ANSI X3.215-1994 Information Systems -
Programming Language FORTH

ISO/IEC 15145:1997 Information technology.
Programming languages. FORTH

3) Remove the "X3 Membership" and "X3J14 Membership" sections, as ISO
did, when they adopted the ANSI document.

4) Replace the "Forward" with the following:

Forth is a language for direct communication between human beings and
machines. Using natural-language diction and machine-oriented syntax,
Forth provides an economical, productive environment for interactive
compilation and execution of programs. Forth also provides low-level
access to computer-controlled hardware, and the ability to extend the
language itself. This extensibility allows the language to be quickly
expanded and adapted to special needs and different hardware systems.

Forth was invented by Mr. Charles Moore to increase programmer
productivity without sacrificing machine efficiency. Forth is a layered
environment containing the elements of a computer language as well as
those of an operating system and a machine monitor. This extensible,
layered environment provides for highly interactive program development
and testing.

In the interests of transportability of application software written in
Forth, standardization efforts began in the mid-1970s by an
international group of users and implementors who adopted the name
``Forth Standards Team''. This effort resulted in the Forth-77 Standard.
As the language continued to evolve, an interim Forth-78 Standard was
published by the Forth Standards Team. Following Forth Standards Team
meetings in 1979, the Forth-79 Standard was published in 1980. Major
changes were made by the Forth Standards Team in the Forth-83 Standard,
which was published in 1983.

In 1987, the ANSI (American National Standards Institute) and the IEEE
(Institute of Electrical and Electronics Engineers) convened the X3J14
committee on Forth Programming Systems. The committee included many
members of the Forth Standards Team. After some twenty-three meetings
(88 days) the committee published ANS X3.215-1994 Information Systems -
Programming Languages FORTH in 1994. This document was adopted as an
international standard, by the ISO, in 1997 and published as ISO/IEC
15145:1997 Information technology, Programming languages, FORTH.

In 2004, the current project to update the ANS Forth standard was
launched at the 2004 EuroForth conference. Proposals to be posted and
discussed via the comp.lang.forth usenet news group and an email list.
With an open meetings to discuss proposals, held immediately before
the annual EuroForth conference.

5) Add a new "Proposals Process" section after the "Forward":

In developing a standard it is necessary for the standards committee
to 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 that end we have introduced a system of consultation with the Forth
community:

a) A proponent of an extension or change to the standard write a
proposal

b) This proposal is published on comp.lang.forth usenet news group and
on the forth 200x email list as an RfD (Request for Discussion)
where the Forth community can comment on the proposal.

c) The proponent can modify the proposal, taking the comments into
consideration. Where they dismiss comments, the reasons for this
dismissal must be given. The revised proposal is republished as
a new RfD.

d) Once a proposal has settled down, it is republished as a CfV
(Call for Votes). System implementors state, whether their system
implements the proposal, or what the chances are that it ever will.
Similarly, programmers can state whether they have used something
similar to the proposed extension and whether they would used the
proposed extension once it is standardized.

e) 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).

Note that should a contributor consider their comments to have been
dismissed without due consideration, they are encouraged to submit
a counter proposal.

Proposals which have passed the poll will be integrated into the basis
document in preparation for the approaching Standards Committee meeting.
No proposal with a CfV deadline of less than three months prior to the
next standards meeting will be integrated into the basis document.

A proposal should contain the following

* Normative parts

This is the formal part of the proposal.

* Proposal
The actual proposal should be as well-specified as possible.

Some issues could be left undecided, left for the discussion
of the proposal. These issues should be mentioned in the
Remarks section in addition to the proposal.

If you want to leave something open to the system implementor,
make that explicit, indicating it as implementation specific,
or possibly by making it an ambiguous condition.

For word definitions, take you example from the basis document.
The definition should include validation and rationale sections,
as appropriate.

* Informative parts

The rest of the proposal is informative, giving a rationale for the
proposal, so that system implementors and programmers will see what
it is good for and why they should adopt it (and vote for it). This
includes:

* Problem
This states what problem the proposal addresses. It usually comes
before the (normative) proposal.

* Typical use
Shows a typical use of the word/feature you propose; this should
make the formal wording easier to understand.

* Remarks
This gives the rationale for specific decisions you have taken in
the proposal, or discusses specific issues that have not been
decided yet.

* Reference implementation
This makes it easier for system implementors to adopt your proposal.
Where possible a reference implementation should be provided in
ANS Forth. Where this is not possible, system specific knowledge is
required or non standard words are used, this should be documented.

* Test cases
This should test the feature/words you propose, in particular, it
should test boundary conditions. Where possible test cases should
be written to the ANS Forth validation suite, as developed by
John Hayes, and documented in appendix F of this document.

* Experience
Indicate where the proposal has already been implemented and/or
used.

* Comments
Initially this is blank. As comments are made on the proposal, they
should be incorporated into the proposal. Comment which can not be
incorporated should be included in this section. A response to the
comment may be included after the comment itself.

* Instructions for voting
Once the proposal enters the Call for Votes stage, the vote-taker
will add the voting instructions to the proposal. The vote-taker
will normally be a member of the standards committee not directly
involved in the drafting of the proposal.

6) Add a new "Minutes of Meetings" section after the new "Proposals
Process" section.

Note that as this is front-matter it will appear before the table
of contents and thus the page numbering of the main document will
not be effected.

The first meeting of the Forth 200x Standards Committee took place
at the Hotel Santemar in Santander, Spain, during October 21-23. The
participants were:

* Willem Botha, CCS, South Africa
* Federico de Ceballos, University of Cantabria, Spain
* M. Anton Ertl, TU Wien, Austria
* N. J. Nelson, Micross, England (Observer)
* Dr. Peter Knaggs, University of Bournemouth, England
* Stephen Pelc, MPE, England
* Dr. Bill Stoddart, University of Teesside, England (Observer)

Action on proposals:

Proposal Comments Votes Y/N/A Action

X:deferred DEFER, DEFER@, DEFER!, IS, Passed 5/0/0
ACTION-OF
X:defined [DEFINED], [UNDEFINED] Passed 5/0/0
X:parse-name PARSE-NAME Passed 5/0/0
X:extension-query
Modification to ENVIRONMENT? Passed 5/0/0
Revised to remove auto-loading
of requested extensions

Other Business:

1) Integration into the standards document

Should new words be put into the established wordsets, or
into new ones?

The eventual goal is to usually integrate the new words into
existing wordsets with related functionality; in some cases
it may be more appropriate to create a new word set. However,
as an intermediate step the new proposals will at first be
kept separate, to make it easier for readers of the document
to see what is changing.

2) How are the extension-query names reflected in the standard?

The glossary header for new words includes the extension-query
string for the extension that proposed it. In addition, there
will be a chapter or normative appendix that lists all the
extensions, their extension-query strings and the components
(word definitions etc.) that it consists of.

3) Should the tests of a proposal or the reference implementation become
normative?

No. This could lead to conflicting normative sections; also,
making the reference implementation normative would lead to
over specification.

4) Review of the RfD/CfV process

How well is the RfD/CfV process working at generating high-
quality proposals for standardisation and getting information
about their popularity? What could be improved? Or should we
do something completely different?

Many of the participants were not very familiar with how well
the process worked in practice, and had no suggestions for
improvements.

The (normative part of the) proposals required adoption before
integrating them into the document, but there was a widespread
feeling among the participants that proposals in the form of
unambiguous instructions to the document editor (which is the
form that would be voted on by the standards committee) would
be harder to understand for the CfV audience.

The resulting idea was to have two forms of the proposal,
with the same content: First the not-so-formal form used in
the CfV, and later a form for integrating it into the document.

5) Official standards body

Should we run the standard through a standards body like ANSI,
ISO, IEEE, etc.? If so, which one?

Some participants consider the blessing of the future standards
document by an official standards body very important, and we
agreed to work towards this goal by writing the document in the
appropriate style, and by keeping documentation about all our
steps. However, the general idea was to first develop the
document without involving a standards body, and deal with them
at the end.

Various candidate standards bodies were discussed; none was
decided on, but it might be that going through ANSI again might
be the easiest route.

6) Chairman and Editor
M. Anton Ertl was appointed as the chair of the committee
unopposed.

Dr. Peter Knaggs was appointed editor unopposed.

7) Which standard documents should we start from?

Peter Knaggs has a version of dpANS99a in LaTeX form,
convertible into a fully hyperlinked PDF file. However, it
is yet unclear how this document differs from the ANS/ISO
Forth documents and dpANS6.

8) Integration of CfV into the Standard

How do we get from the CfV proposal to the form for integration
into the document? One opinion was that the original proponent
should do it.

9) Proposal Champions

There was the opinion that a proposal (de-facto) needs a
champion in the committee to get approval by the standards
committee. So, if the proponent finds a champion in the
committee, they could produce the for-the-document version
of the proposal together.

10) Improvements for future standard meetings

* The participants should familiarise themselves with the
proposals beforehand.
* Paper printouts of the proposals should be available at
the meeting.
* Proposals should be available in the form needed for
integration into the standards document in addition to
the CfV form.
* There should be a champion for the proposal in the meeting.

Action Items:

1) Federico de Ceballos was asked to look into providing a proposal to
cover the following topics:

* number prefixes
* 0 for NIL
* ! and @ for 16-bit and 32-bit signed and unsigned integers,
bytes, octets

2) M. Anton Ertl was asked to look into the implications of the
following and develop proposals for them:

* separate FP stack
* required
* directory stuff in general
* directory handling for included and required
* key names for EKEY results

3) Stephen Pelc was asked to look into the implication of the
following topics, and develop proposals for:

* { (locals), fp locals, buffer locals
* S\" .\"
* iors can be THROWn
* SYNONYM
* structures

4) Bill Stoddart was asked to investigate the implications of
allowing the parser to ignore white space (TAB, CR, LF, and FF)
in source code, and develop a proposal.

5) Peter Knaggs to contact John Hayes to obtain permission to include
the validation suite into the document.

6) Peter Knaggs to produce a basis document of the ANS Forth standard
with the four accepted proposals and validation suite included.

Next meeting:

After some discussion about possibly having two meetings per year,
we decided to just have one meeting per year for now. The next
meeting will again be on the day before the next EuroForth conference
(in Cambridge, September 15-17, 2006).

Remarks
=======

Do we need a printed copy of the minutes from the standards meetings? My
personal view is that we do, so we can have independent documentation of
the procedures we have undertaken in the development of the standard.

As the most significant word in the previous paragraph is "independent",
the question come as to where the minutes should be published. I could
published them in JFAR, but as the editor of both Forth200x and JFAR, I
would hardly call that "independent". Any other suggestions.

I have reformatted the minutes published on forth200x.org, in the same
style as those of the X3J14 minutes published in JFAR.