Here's my report on the meeting. You can find this report in HTML form on
<http://www.complang.tuwien.ac.at/forth/ansforth/meetings/2005.html>

I also append the proposals that we approved for the standards
document. You can also find them in
<http://www.complang.tuwien.ac.at/forth/ansforth/document/>.

- anton

Forth standards meeting at EuroForth 2005

On 2005-10-20, 2005-10-21 and 2005-10-23 there was a Forth standards meeting,
right before and partly during EuroForth 2005. The participants were:

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

The following topics were discussed:


Accepting proposals into the standard document

Federico de Ceballos chaired this part of the meeting.

The four proposals which had gone to a CfV were discussed:

o deferred
o extension-query
o parse-name
o defined

<http://www.complang.tuwien.ac.at/forth/ansforth/rfds.html>

Various changes were suggested that were necessary for inclusion into the
standards document. These changes then resulted in adapted versions of the
normative parts of these proposals (performed by Anton Ertl). The resulting
proposals were then discussed, and various small clarifications and changes
were incorporated, resulting in the following normative parts.

o deferred
o extension-query
o parse-name
o defined

<http://www.complang.tuwien.ac.at/forth/ansforth/document/>

These proposals were all accepted with vote results 5Y:0N:0A.


Future proposals

A number of potential topics for future proposals were discussed, and
eventually some participants volunteered to write RfDs for the following
topics:

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

M. Anton Ertl
separate FP stack
required
directory stuff in general
directory handling for included and required
key names for EKEY results

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

Bill Stoddart
Using TAB, CR, LF, FF in source code


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.

How are the extension-query names reflected in the standard (if at all)?

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.

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 overspecification.


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 familar with how well the process
worked in practice, and had no suggestions for improvements.

The (normative part of the) proposals required adaption 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.


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.


Chairman and Editor

M. Anton Ertl was appointed as the chair of the committee unopposed.

Peter Knaggs was appointed editor unopposed.


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
(probably in Cambridge, maybe September 14/15, 2006).


Open questions

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.

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. On a
related topic, there was the opinion that a proposal 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.


Improvements for future standard meetings

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


---------------------------------------------------------------
deferred:

DEFER ( "<spaces>name" -- ) CORE-EXT X:deferred

Skip leading space delimiters. Parse name delimited by a space. Create a
definition for name with the execution semantics defined below.

name Execution: ( i*x -- j*x )

Execute xt associated with name. An ambiguous condition exists if name has not
been associated with an xt yet.


IS CORE-EXT X:deferred

Interpretation: ( xt "<spaces>name" -- )
Skip leading spaces and parse name delimited by a space. Set name to
execute xt. An ambiguous condition exists if name was not defined by
DEFER.
Compilation: ( "<spaces>name" -- )
Skip leading spaces and parse name delimited by a space. Append the
run-time semantics given below to the current definition. An ambiguous
condition exists if name was not defined by DEFER.
Run-time: ( xt -- )
Set name to execute xt.

An ambiguous condition exists if POSTPONE, [COMPILE], ['] or ' is applied to
IS.

DEFER@ ( xt1 -- xt2 ) CORE-EXT X:deferred

xt2 is the xt associated with the deferred word corresponding to xt1. An
ambiguous condition exists if xt1 is not for a word defined via DEFER, or if
the deferred word has not been associated with an xt yet.

DEFER! ( xt2 xt1 -- ) CORE-EXT X:deferred

Set the word xt1 to execute xt2. An ambiguous condition exists if xt1 is not
for a word defined via DEFER.


ACTION-OF CORE-EXT X:deferred

Interpretation: ( "<spaces>name" -- xt )
Skip leading spaces and parse name delimited by a space. xt is the
xt associated with name. An ambiguous condition exists if name was not
defined by DEFER, or if the name has not been associated with an xt yet.
Compilation: ( "<spaces>name" -- )
Skip leading spaces and parse name delimited by a space. Append the
run-time semantics given below to the current definition. An ambiguous
condition exists if name was not defined by DEFER.
Run-time: ( -- xt )
xt is the execution token associated with name when the run-time
semantics is performed. An ambiguous condition exists if name has not
been associated with an xt yet.

An ambiguous condition exists if POSTPONE, [COMPILE], ['] or ' is applied to
ACTION-OF.
----------------------------------------------------------------------
extension-query:

Add the following to table 3.5:

String Value data type Constant?
X:deferred - - string present only if DEFER,
DEFER@, DEFER!, IS and ACTION-OF are present
X:extension-query - - string present
X:parse-name - - string present only if PARSE-NAME is
present

Add the following to table 15.1:

X:defined - - string present only if [DEFINED] and
[UNDEFINED] are present

Append in Section 2.2.4.1:

- ENVIRONMENT? string if the word belongs to a Forth200x extension.
--------------------------------------------------------------------
parse-name:

PARSE-NAME CORE EXT X:parse-name

( "<spaces>name" -- c-addr u )

Skip leading space delimiters. Parse name delimited by a space.

c-addr is the address of the selected string within the input buffer and u is
its length in characters. If the parse area is empty or contains only white
space, the resulting string has length zero.
---------------------------------------------------------------------
defined:

[DEFINED] "bracket-defined" TOOLS EXT X:defined

Compilation: Perform the execution semantics given below.

Execution: ( "<spaces>name" -- flag )

Skip leading space delimiters. Parse name delimited by a space.
Return a true flag if /name/ is the name of a word that can be found
(according to the rules in the system's FIND); otherwise return a
false flag. [DEFINED] is an immediate word.


[UNDEFINED] "bracket-undefined" TOOLS EXT X:defined

Compilation: Perform the execution semantics given below.

Execution: ( "<spaces>name" -- flag )

Skip leading space delimiters. Parse name delimited by a space.
Return a false flag if /name/ is the name of a word that can be found
(according to the rules in the system's FIND); otherwise return a true
flag. [UNDEFINED] is an immediate word.