Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!pitt!willett!ForthNet
From: ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie)
Newsgroups: comp.lang.forth
Subject: ANS FORTH TECHNICAL COMMITTEE
Message-ID: <2265.UUL1.3#5129@willett.pgh.pa.us>
Date: 25 Jan 91 03:34:12 GMT
Organization: (n.) to be organized.  But that's not important right now.
Lines: 110

Category 10,  Topic 2
Message 289       Thu Jan 24, 1991
D.RUFFER [Dennis]            at 21:31 EST
 
Forwarded from Elizabeth Rather:

This is in response to recent comments on the various boards.

I'm happy to see some specifics among the generalizations re X3J14, to wit a
strong request from Petty to remove >COLROW and LEX, and some constructive
comments about control structures.  The latter are of concern to me, too, as I
believe they aren't adequately specified yet; I am working on some proposals
to that end.

Regarding >COLROW, I'd really like to see a "show of hands" as to whether:

1.  It should be removed altogether (it's not required, it's in CORE
    EXTENSIONS).
 2.  It should be kept as is.
 3.  It should be given a different name and description (if so,
    what?).

Some form of this function is found in virtually *all* Forth systems.  This
particular form is, I believe, in LMI Forth. Although I personally would
prefer to see it named TAB and with the stack arguments reversed (polyFORTH
usage) I believe it's better to have some version of this common function
standardized than none. Please, folks, take a position!

Regarding LEX, I personally would prefer to see the entire string wordset go,
and there are many on the TC that feel that LEX is the only useful word in the
set.  Once again, stand up and be
 counted:  how do you vote?

RE moving 2DROP, 2DUP, 2OVER, 2SWAP, etc. to DOUBLE:  these words have not
only been in all standards and all Forths of which I am aware, they are
extremely useful even on 32-bit implementations for manipulating pairs of
cells.

RE a "portability" wordset with ALIGN etc.:  Separate wordsets are optional,
that is, a "standard system" may not have them.  If these words are required
to ensure that standard programs are portable across machines of differing
cell size and alignment requirements, programs have to be able to count on
their presence.  They simply aren't useful if they aren't required.

RE an Input Stream wordset with #TIB, etc.:  what we are standardizing is a
programming system, not a run-time environment. A Forth programming system is
interactive, and therefore has a way of handling an input stream.  If we were
to make these words optional we would surely bring down storms of protest from
people who feel, with Wavrik, that we're taking away functionality.  I don't
agree with Wavrik about xBRANCH words (they aren't in most Forth systems
anyway, so he isn't losing anything), I certainly would be upset to lose
these.

Petty is mistaken in his belief that we're standardizing a "Forth kernel." 
Nothing in BASIS deals with what's in a kernel.  The CORE wordset is a list of
words that must be present in some form in a standard system.  See B14 Section
5.1:

"This Standard does not require that each word be provided in executable form.
The implementor may choose to provide word definitions, including definitions
of words in the core word set, in source form only.  This is acceptable as
long as a mechanism exists for adding the word definitions to the dictionary."

(NOTE:  this text may move, as there are several proposals pending for
reorganizing and clarifying Section 5, but the TC is vehemently committed to
this principle.)

RE ONLY/ALSO:  there are two proposals pending to discard these words.  Once
again, how do you feel?

RE Brad Rodriguez' complaint that we didn't give more time to some of the
proposals from his Toronto friends:  Those that I remember represented
controversies that we had discussed exhaustively in past meetings, such as
case insensitivity, use of a decimal point to indicate floating point in input
(which would break a great deal of existing code), and divorcing host OS files
from BLOCKS (which represents an important compromise hammered out over many
hours, guaranteeing a way to access disk compatible between native and non-
native implementations).  We don't regard any of these as trivial issues; we
worked very hard and long on them in past meetings, but these proposals didn't
contribute any new facts or logic that would justify reopening them.  We also
failed several Toronto proposals that would have added words; this ought to
please BFIG.

In fact, of the 43 proposals submitted by the Toronto group, 20 passed in some
form.  This is a very high passage ratio for an outside group -- the overall
pass rate for outside proposals has been about 20%.  Outside proposals fail
either because they raise issues that have already been dealt with (without
contributing anything new on the subject), they violate widespread standard
 practice, or because they add lots of whizzy new words, which (BFIG
notwithstanding) we have usually declined to do.

RE reported uncertainty about definitions of "standard system," "standard
program," etc.:  Please, those of you that have those concerns, read Section
5.6 (Compliance and Labeling) carefully and
 tell me what confuses you.  I promise I will try to fix it, as we all regard
this as a vital issue.

OK, FOLKS, PUT UP OR SHUT UP.  I HAVE LISTED SOME ISSUES THAT ARE OPEN FOR
DISCUSSION AT THE NEXT MEETING AND I PERSONALLY PLEDGE TO
 REPRESENT MAJORITY VOTES ON THE ABOVE ISSUES.  TAKE A POSITION AND
 TELL ME WHAT YOU THINK AND WHY!

Once again, the next meeting of X3J14 is Jan. 29-Feb. 2 at FORTH, Inc., 111 N.
Sepulveda, #300, Manhattan Beach, CA.  You're welcome to attend; if you wish
to do so, please call me at (213) 372-8493.
-----
This message came from GEnie via willett.  You cannot Reply to the author
using email.  Please post a follow-up article, or use any instructions
the author may have included (USMail addresses, telephone #, whatever).
Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwp