[comp.lang.forth] What should the Standard include?

ForthNet@willett.UUCP (ForthNet articles from GEnie) (08/06/90)

Category 10,  Topic 30
Message 88        Sun Aug 05, 1990
R.BERKEY [Robert]            at 06:42 PDT
 
 

 ----------------------------------------------------------------------
 ANSI X3J14 Forth Technical Proposal                        Page 1 of 1
 ----------------------------------------------------------------------
             Title: One's- and Two's-Complement ALUs
 Related Proposals:
        Keyword(s):                                        Proposal (X)
     Forth Word(s):                                        Comment  ( )
 ----------------------------------------------------------------------
 Abstract:
    Policy statement for ALUs covered by BASIS.
 ------------------
 Discussion:

 Removing a bit pattern for zero as was passed in Melbourne, on behalf of a
 generalized concept of ALUs, is useless to today's programmers, and
 radically impacts upward compatibility.  Without the corresponding analysis
 and proposals for separating the number concept of "zero" from the flag
 concept of "false", the BASIS document is rendered inconsistent.  For
 example,  IF  is currently a word without a clear meaning.

 Given Forth's lack of penetration into the "sign-magnitude market",
 specifications for sign-magnitude ALUs are untestable.  Without the
 experience of actual needs, or evidence of such need, the specifications may
 or may not serve a useful purpose.  But nothing in BASIS prevents Forth from
 being brought up on a sign-magnitude machine.  Further, such concepts
 adversely impact useful programming and upward compatibility.  _The_
 _fundamental working concept that the conventional Forth number space is_
 _circular, is demonstrated in BASIS in the definition of WITHIN and the_
 _specification concerning overflow, as well as in previous standards._

 The inclusion of one's-complement-ALUs considerations is also outside the
 scope of ordinary Forth programming.  However, the inclusion of
 one's-complement ALUs with two's-complement ALUs, which are both circular
 number spaces, is less radical than the inclusion of sign-magnitude, etc.,
 ALUs; there is existing practice in the field; and one of the committee's
 members is able to represent the one's complement needs.

 This proposal, among other things, mitigates the potential for oversights
 in BASIS in specification involving one's complement ALUs, specification
 which is needed by standard programs.  By defaulting to two's complement in
 the absence of a label that ideas from other ALUs are involved, such
 labeling serves the purpose of communication of programming ideas: this is
 consistent with current literature.

 -------------------
 Proposal:

   It is the policy of the committee to primarily consider only one's and
   two's complement architectures.  The various labeling for "standard
   programs" will provide labeling for one's complement as a special case.

 ---------------------------------------------------------------------
 Submitted by:  Robert Berkey                           Date: 90-08-05
 Address:       47000 Warm Springs Blvd. #253       Ph: (415) 659-1334
                Fremont, CA 94539                 Msgs: GEnie R.BERKEY

 ANSI X3J14 Forth Standards Committee
 111 N. Sepulveda Blvd., Suite 300, Manhattan Beach, CA 90266
 ---------------------------------------------------------------------

-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: uunet!willett!dwp or willett!dwp@hobbes.cert.sei.cmu.edu

ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (09/03/90)

Category 10,  Topic 30
Message 89        Fri Aug 31, 1990
D.RUFFER [Dennis]            at 13:14 EDT
 
From Elizabeth Rather, Chair, ANS X3J14 Technical Committee:

This is addressed to those who have been commenting extensively on our work on
UseNet and related boards.

We very much appreciate your interest.  I have circulated copies of many of
your comments in the TC.  I'd like to take the opportunity to try to clarify a
few things.

I understand that many of you share our goal to have a "perfect" standard. 
Unfortunately, you don't all agree as to the definition of "perfect", and
neither do all members of the TC.  There are at least five widely shared
definitions:

1. A rich standard that includes all common words plus many extensions so that
anything I might want to do is encompassed.  I need to be able to count on all
my favorite words being supported by all Forth systems in order to be able to
write complex, interesting programs portably.  Program size isn't an issue,
since all systems have many megabytes of memory nowadays.

2. A lean, mean standard that specifies a minimum wordset whose availability I
can rely on, but isn't encumbered with so many general-purpose capabilities
that systems are too big to run in a 16- bit address space with room for
useful programs.  I'm happy to assume the responsibility for adding those
extensions I need.

3. FORTH-83, with minor fixups like 32-bit system support.

4. FORTH-79, with minor fixups like 32-bit system support.

5. No standard.  Who are you to tell me what to do?

Only the last group can be easily satisfied, by acknowledging their right to
ignore whatever standard we pass.  Most of our time is spent working out
compromises between the other four viewpoints. These compromises are developed
over hours of work, and like all compromises they can be expected to make
everyone somewhat unhappy. But it's important for you to realize just how hard
we're trying to find solutions that will be as satisfactory as possible to as
many people as possible.
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: uunet!willett!dwp or dwp@willett.pgh.pa.us

peter@ficc.ferranti.com (Peter da Silva) (09/05/90)

> There are at least five widely shared definitions:

> 1. A rich standard ...

> 2. A lean, mean standard ...

> 3. FORTH-83, with minor fixups like 32-bit system support.

> 4. FORTH-79, with minor fixups like 32-bit system support.

> 5. No standard.  Who are you to tell me what to do?

You missed one...

  6. Fig-FORTH.
-- 
Peter da Silva.   `-_-'
+1 713 274 5180.   'U`
peter@ferranti.com

ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (02/06/91)

 Date: 02-03-91 (09:45)              Number: 1028 of 1028 (Echo)
   To: GARY SMITH                    Refer#: 1024
 From: RAY DUNCAN                      Read: NO
 Subj: WHAT SHOULD THE STANDARD      Status: PUBLIC MESSAGE
 Conf: FORTH (58)                 Read Type: GENERAL (+)

    >SET-ORDER can be done portably in ANS FORTH

 Only if everyone implements *ALL* the extension word sets.  In our own
 case, I can definitely promise you that LMI will *NOT* implement the
 extension words that it considers brain-damaged, which definitely
 includes ALSO and ONLY.

 NET/Mail : LMI Forth Board, Los Angeles, CA (213) 306-3530
 <<<>>>
-----
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

ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (02/09/91)

   To: RAY DUNCAN                    Refer#: 1028
 From: JACK WOEHR                      Read: NO
 Subj: WHAT SHOULD THE STANDARD      Status: PUBLIC MESSAGE
 Conf: FORTH (58)                 Read Type: GENERAL (+)

 -> >SET-ORDER can be done portably in ANS FORTH
 ->
 -> Only if everyone implements *ALL* the extension word sets.  In our
 -> own case, I can definitely promise you that LMI will *NOT* implement
 -> the extension words that it considers brain-damaged, which definitely
 -> includes ALSO and ONLY.

         Uh .. I think them hummers (ONLY/ALSO) is gone these days.

         Also, I doubt if you would have to implement DOUBLE EXT or
 FILE EXT or FLOAT to get SET-ORDER up and running!

         Ray, you used to be Assistant Grand BooHoo of this effort,
 you should take another look at BASIS and think long and hard about
 lending your prestigious name to pushing this thing thru, esp. now
 as it looks like we are going for dpANS toot sweet.

     =jax= "they only broke my ROM systems a *teensy* bit :-)"
-----
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

ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (02/18/91)

Category 10,  Topic 30
Message 97        Sat Feb 16, 1991
B.RODRIGUEZ2 [Brad]          at 16:23 EST
 
From Mitch Bradley:

> The problem with criteria, either "necessary" or "sufficient",
 > is that there is no mechanism for either consistently applying
 > or enforcing them.

I couldn't have said it better myself!  However, this is not a problem with
criteria per se -- it's a problem with the TC.

Brad Rodriguez        | brad%candice@maccs.uucp      (God willing)
 B.RODRIGUEZ2 on GEnie | brad%candice@maccs.dcss.mcmaster.ca
 "Shoes for industry!" | bradford@maccs.dcss.mcmaster.ca  (archaic)

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

esj@harvee.UUCP (Eric S Johansson) (02/20/91)

In article <2363.UUL1.3#5129@willett.pgh.pa.us> ForthNet@willett.pgh.pa.us
(ForthNet articles from GEnie) writes:
>
> Category 10,  Topic 30
> Message 97        Sat Feb 16, 1991
> B.RODRIGUEZ2 [Brad]          at 16:23 EST
>  
> From Mitch Bradley:
> 
> > The problem with criteria, either "necessary" or "sufficient",
>  > is that there is no mechanism for either consistently applying
>  > or enforcing them.
> 
> I couldn't have said it better myself!  However, this is not a problem with
> criteria per se -- it's a problem with the TC.
> 
How can you claim this is a problem with the TC?  "necessary" and "sufficient"
are ambigious terms.  For example, would you go into an auto
mechanics shop, hand him (or her) your car and say "do what ever is 
necessary and send me the bill."  I think not (otherwise I want to be
your auto mechanic :-)

When ever any organization is working with ambigious criteria, you
get inconsistent results.  This is true for contracts,
standards, agreements, or any situation where group sez "we will do this"
and does not define "this".


--- eric
--
...
^^^     eric johansson   UUCP ...!uunet!wang!harvee!esj esj@harvee.uucp
* *     a juggling fool  AT&T (617) 577-4068 (w)
 o                       HAM  ka1eec
\_/			 CSNET johansson%hydra@polaroid.com
			 or      hydra!johansson@polaroid.com
	source of the public's fear of the unknown since 1956

jerry@TALOS.UUCP (Jerry Gitomer) (02/20/91)

esj@harvee.UUCP (Eric S Johansson) writes:

:In article <2363.UUL1.3#5129@willett.pgh.pa.us: ForthNet@willett.pgh.pa.us
:(ForthNet articles from GEnie) writes:
::
:: Category 10,  Topic 30
:: Message 97        Sat Feb 16, 1991
:: B.RODRIGUEZ2 [Brad]          at 16:23 EST
::
:: From Mitch Bradley:
::
:: : The problem with criteria, either "necessary" or "sufficient",
::  : is that there is no mechanism for either consistently applying
::  : or enforcing them.
::
:: I couldn't have said it better myself!  However, this is not a problem with
:: criteria per se -- it's a problem with the TC.
::
:How can you claim this is a problem with the TC?  "necessary" and "sufficient"
:are ambigious terms.  For example, would you go into an auto
:mechanics shop, hand him (or her) your car and say "do what ever is
:necessary and send me the bill."  I think not (otherwise I want to be
:your auto mechanic :-)

Unfortunately, twice I have had to hand my body to surgeons and
say "do whatever is necessary and send my insurance company the bill" :-( 

:When ever any organization is working with ambigious criteria, you
:get inconsistent results.  This is true for contracts,
:standards, agreements, or any situation where group sez "we will do this"
:and does not define "this".

The TC, like any other standards group, represents a multitude of
interests.  As a result ambiguous criteria cannot be avoided and
the resulting standard tends to be the least offensive compromise.

No one likes it, but without a strong defacto standard supported
by an industry giant, we shouldn't anticipate anything "better".

-- 
Jerry Gitomer at National Political Resources Inc, Alexandria, VA USA
I am apolitical, have no resources, and speak only for myself.
Ma Bell (703)683-9090      (UUCP:  ...{uupsi,vrdxhq}!pbs!npri6!jerry 

ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (02/27/91)

Category 10,  Topic 30
Message 111       Mon Feb 25, 1991
GARY-S                       at 06:23 EST
 
          
 Subject: Strings
 In Message: <9102222024.AA15755@ucbvax.Berkeley.EDU>
                                 wmb@MITCH.ENG.SUN.COM writes:

 >I suspect that if fstrings were proposed, the minimalists would scream
 >bloody murder.

   and rightfully so. fstrings has absolutely no place in the controlled
   word set. as ancillary baggage - fine. add a refrigerator if you want,
   but don't try to weigh down the core with personal gadgets.

     __         _  Gary Smith           * ... uunet!ddi1!lrark!glsrk!gars  *
    / _' _   _ (_' P. O. Drawer 7680    * GEnie Forth RT  &  Unix RT SysOp *
   /__/ (_|_/ '._) Little Rock,AR 72217 *   voice phone  :  501-227-7817   *
   ---------------        - U. S. A. -  *   group 3 fax  :  501-228-9374   *
-----
This message came from GEnie via willett.  You *cannot* reply to the author
using e-mail.  Please post a follow-up article, or use any instructions
the author may have included (USMail addresses, telephone #, etc.).
Report problems to: dwp@willett.pgh.pa.us _or_ uunet!willett!dwp

ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (03/04/91)

Category 10,  Topic 30
Message 113       Sat Mar 02, 1991
GARY-S                       at 06:23 EST
 
       
 In article <9102271415.AA28047@ucbvax.Berkeley.EDU>
                                  daemon@ucbvax.BERKELEY.EDU writes:

 >> and rightfully so. fstrings has absolutely no place in the controlled
 >> word set. as ancillary baggage - fine. add a refrigerator if you want,
 >> but don't try to weigh down the core with personal gadgets.
 >     
 >Not in my wildest dreams would I have proposed to put fstrings in the
 >CORE wordset, and I doubt that anyone else would have proposed it either.
 >     
 >Extended STRINGS wordset, maybe, but not CORE.
 >    
 >Would the minimalists have been right to scream bloody murder under those
 >conditions?

 Mitch, we've known each other long enough, well enough that you know I 
 would never presume to speak for _all_ minimalists (or all 'any group').
 My personal response is in line two of my original reply above.   

   Gary   gars@glsrk
-----
This message came from GEnie via willett.  You *cannot* reply to the author
using e-mail.  Please post a follow-up article, or use any instructions
the author may have included (USMail addresses, telephone #, etc.).
Report problems to: dwp@willett.pgh.pa.us _or_ uunet!willett!dwp

ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (03/04/91)

Category 10,  Topic 30
Message 114       Sat Mar 02, 1991
B.RODRIGUEZ2 [Brad]          at 22:24 EST
 
> ...any situation where group sez "we will do this" and does not
 > define "this".

Non sequitur, Eric.  It is precisely a definition of "this", namely,
 the necessary conditions, that I am asking for.

- Brad

-----
This message came from GEnie via willett.  You *cannot* reply to the author
using e-mail.  Please post a follow-up article, or use any instructions
the author may have included (USMail addresses, telephone #, etc.).
Report problems to: dwp@willett.pgh.pa.us _or_ uunet!willett!dwp

ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (04/07/91)

Category 10,  Topic 30
Message 120       Sun Apr 07, 1991
B.RODRIGUEZ2 [Brad]          at 11:50 EDT
 
From William J. Bouma:
 > What do you consider a "small machine" these days?  ...I consider
 > any machine with less than 4M RAM to small to be worth using...

"Small machine" (Brad's definition): any machine with a 64K or smaller address
space.

Not all of us use '386s and 68000s.  Nothing I've done commercially in the
last 3 years has required more than 32K.

- Brad
 Brad Rodriguez        | brad%candice@maccs.uucp      (God willing)
 B.RODRIGUEZ2 on GEnie | brad%candice@maccs.dcss.mcmaster.ca
 "Shoes for industry!" | bradford@maccs.dcss.mcmaster.ca  (archaic)

-----
This message came from GEnie via willett.  You *cannot* reply to the author
using e-mail.  Please post a follow-up article, or use any instructions
the author may have included (USMail addresses, telephone #, etc.).
Report problems to: dwp@willett.pgh.pa.us _or_ uunet!willett!dwp

ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (04/11/91)

Category 10,  Topic 30
Message 35        Wed Apr 10, 1991
ELLIOTT.C                    at 13:59 EDT

[ If anyone would like a copy of one/more/all of these files, please
  drop me a note at one of the addresses at the end of this message.
  All binary files are UUencoded.  Files are then split (if necessary)
  into mailer-acceptable sized pieces and then mailed to you.
  In order for me to answer your request, you must:
      Include the line containing the file name. (so I know what you want.)
      Include your email address in the _body_ of the message.  You _must_
	  include an address *relative to* the InterNet or well known
	  UseNet site.
  -dwp]

 
Messages up to Nov. '89 have been uploaded to  library 10 as st21189.arc
-----
This message came from GEnie via willett.  You *cannot* reply to the author
using e-mail.  Please post a follow-up article, or use any instructions
the author may have included (USMail addresses, telephone #, etc.).
Report problems to: dwp@willett.pgh.pa.us _or_ uunet!willett!dwp

ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (04/16/91)

Category 10,  Topic 30
Message 40        Sun Apr 14, 1991
B.RODRIGUEZ2 [Brad]          at 17:27 EDT
 
Well, I would hardly claim to be a spokesman for the "minimalist" camp --
indeed, most of us who have been branded "minimalists" don't even accept that
dichotomy.  I, for instance, accept floating-point and files....does that make
me a minimalist?  I'm quite happy with DEFER, as it meets my personal criteria
for a standard word.  (Which reminds me, I was supposed to post those here. 
Later.)

I am, however, sympathetic to the arguments a) DEFER can be portably defined
in ANS Forth, so it's not essential in the Standard, and b) DEFER shouldn't be
in the CORE wordset.  As one of the people who is _not_ programming Forth on
32-bit monsters, I am very sensitive to the size of both the core and
extension wordsets.

- Brad
 Brad Rodriguez        | brad%candice@maccs.uucp      (God willing)
 B.RODRIGUEZ2 on GEnie | brad%candice@maccs.dcss.mcmaster.ca
                      | bradford@maccs.dcss.mcmaster.ca  (archaic)
 "Yes, sonny, I remember when memory was measured in 'K'..."
-----
This message came from GEnie via willett.  You *cannot* reply to the author
using e-mail.  Please post a follow-up article, or use any instructions
the author may have included (USMail addresses, telephone #, etc.).
Report problems to: dwp@willett.pgh.pa.us _or_ uunet!willett!dwp

ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (04/24/91)

Category 10,  Topic 30
Message 43        Sun Apr 21, 1991
B.RODRIGUEZ2 [Brad]          at 21:50 EDT
 
As promised long ago, here is the text of proposal TP90-889 (defeated),
"Criteria for acceptance of new words."

---------------------------------------------------------------------
 Add the following text to the Standard, and use these criteria in TC
deliberations:

In order for a word to be adopted as a Forth standard, it must demonstrate
general acceptance, useful functionality, and implementability.

To establish general acceptance and usefulness, the exact word must have been
in use for at least one year in each of six or more major Forth systems
("major" being defined as having 200 or more users). These six systems must
include Forths for at least one 32-bit, one 16-bit, and one 8-bit processor.

Successful implementations must be demonstrated for at least one subroutine-
threaded, one direct-threaded, and one indirect-threaded Forth system.

Proposed words which do not satisfy these criteria shall be deemed
"experimental."
 ---------------------------------------------------------------------

One clarification: when this was presented in Detroit, I indicated that the
phrase "the exact word" did not apply to word NAMES, but only to function,
stack effect, argument values, side effects, etc.
 (I've recently thought to add the requirement that the six implementations
must be done by at least three different people, but the above is what was
proposed, and I'll stand by it.)

These are, In My Humble Opinion, very "light" criteria.  (The Boston group
proposed a five-year period.)  The intent is a) to ensure that new ideas can
be implemented in all Forth environments (e.g., subroutine-threaded), and b)
that new ideas be tried out before being adopted.  And yet there are entire
sections of X3J14 which can't even meet this feeble test!

A more damning indictment of X3J14 is that the TC rejected the VERY IDEA of
ANY such criteria, with ANY numbers inserted in the blanks.

                              * * *

I was once taught a very useful test for intellectual honesty, to see if an
opponent is open to argument or persuasion: ask him "What would it take to
change your mind on this subject?"  The above is my answer to that question --
show me six major systems for one year, and I'll quit carping about local
variables and exception handling.

But when I asked that question of the TC members, several replied "Nothing" --
which was proof that I was wasting my time.

Brad Rodriguez        | brad%candice@maccs.uucp      (God willing)
 B.RODRIGUEZ2 on GEnie | brad%candice@maccs.dcss.mcmaster.ca
 "Shoes for industry!" | bradford@maccs.dcss.mcmaster.ca  (archaic)

-----
This message came from GEnie via willett.  You *cannot* reply to the author
using e-mail.  Please post a follow-up article, or use any instructions
the author may have included (USMail addresses, telephone #, etc.).
Report problems to: dwp@willett.pgh.pa.us _or_ uunet!willett!dwp

REEVES@SLACVM.SLAC.STANFORD.EDU (Terry Reeves) (05/01/91)

In article <2669.UUL1.3#5129@willett.pgh.pa.us>, Brad Rodriguez writes
>
>These are, In My Humble Opinion, very "light" criteria.  (The Boston group
>proposed a five-year period.)  The intent is a) to ensure that new ideas can
>be implemented in all Forth environments (e.g., subroutine-threaded), and b)
>that new ideas be tried out before being adopted.  And yet there are entire
>sections of X3J14 which can't even meet this feeble test!
>

In my nowhere near humble opinion (I'm a high energy physicist. My ego is as
huge as the distances I probe are small.), the criteria proposed are not
light. In fact, I would see them as very stifling. My first quick reading of
the proposal seems to say that only those words which are already standard
across a major portion of the Forth community can be standardized. This would
not only require that all of the necessary systems implement the same ideas,
but that they implement them in almost exactly the same way. Since I am most
definitely not a minimalist, and I want the standard to address as many issues
as possible, I would reject the proposal almost out of hand.

                                                  Terry

P.S. I would also note that it might prevent some of the useful compromises
     that have taken place, i.e. WORDLIST and floored vs. symmetric division.

Disclaimer: The above are my own opinions. The are not necessarily related to
the official policies of SLAC, Stanford University, the Dept. of Energy, or
the U.S. government.

S47852EF@ETSUACAD.BITNET (05/02/91)

>In my nowhere near humble opinion (I'm a high energy physicist. My ego is as
>huge as the distances I probe are small.), the criteria proposed are not
>light. In fact, I would see them as very stifling. My first quick reading of
>the proposal seems to say that only those words which are already standard
>across a major portion of the Forth community can be standardized. This would
>not only require that all of the necessary systems implement the same ideas,
>but that they implement them in almost exactly the same way. Since I am most
>definitely not a minimalist, and I want the standard to address as many issues
>as possible, I would reject the proposal almost out of hand.

I don't know about that- look at all the C implementations (And they *DO*
differ amongst each other and can still claim ANSI portability!); they all
have concrete ideas of what the syntax should be and what should it basically
do.  Yet, they implement it differently- why should this be any different in
Forth?   It isn't.   Therefore, these criteria aren't as heavy as you make them
but not as light as Brad makes them- they are STILL reasonable.

>P.S. I would also note that it might prevent some of the useful compromises
>     that have taken place, i.e. WORDLIST and floored vs. symmetric division.

In your example, WORDLIST is the only thing that wouldn't have made it-
floored and symmetrical division has been around and implemented over most of
the entire existance of the language and therefore would pass the criteria.
(I.e.  You could have both in the language and DEFERed (Or, it's equivalent)
the '/' operator and assigned it the PFA of the form you want to use...
And we have had one or the other since atleast 1983-84 when the 83 standard
came out!)


Frank

Mitch.Bradley@ENG.SUN.COM (05/02/91)

> To establish general acceptance and usefulness, the exact word must have
> been in use for at least one year in each of six or more major Forth systems

> "the exact word" does not apply to word NAMES, but only to function,
> stack effect, argument values, side effects, etc.

This would effectively prevent ANY new words from making it into the
standard.  Counterexamples are solicited.  Please be prepared to defend
your claim by citing the 6 major systems.

To impose this requirement on the committee would prevent any progress
from being made.

Mitch.Bradley@Eng.Sun.COM

ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (05/06/91)

Category 10,  Topic 30
Message 50        Sun May 05, 1991
B.RODRIGUEZ2 [Brad]          at 10:09 EDT
 
All I can say is, the Forth community must be a lot smaller than I thought it
was.  (Someone once told me that there were about 150 Forth vendors.)

With the exception of the subroutine-threaded implementation -- and that was a
concession to the STC contingent that I was sure the TC would approve -- any
Forth usage from polyForth could meet these criteria.  Or anything from LMI
Forth.  Or from MPE.  In fact, the big weakness of my proposed criteria is
that they allow all six model systems to come from a single vendor.

Specific examples?  ONLY/ALSO.  TO.  Conditional compilation. FOR...NEXT. 
Probably file systems (although I'm not familiar with industry practice here).
Probably much of floating point (ditto). Almost certainly you could find two
or three strings packages to meet these criteria.

And given the number of vendors on the TC, it should take no more than 12
months and a fraction to meet this requirement for the most fevered products
of the TC's imagination.  Why is no one willing to do this?

The burden of proof is on the positive, in philosophy and in
jurisprudence....but evidently not in standards-making.

Brad Rodriguez        | brad%candice@maccs.uucp      (God willing)
 B.RODRIGUEZ2 on GEnie | brad%candice@maccs.dcss.mcmaster.ca
 "Shoes for industry!" | bradford@maccs.dcss.mcmaster.ca  (archaic)

-----
This message came from GEnie via willett.  You *cannot* reply to the author
using e-mail.  Please post a follow-up article, or use any instructions
the author may have included (USMail addresses, telephone #, etc.).
Report problems to: dwp@willett.pgh.pa.us _or_ uunet!willett!dwp

Mitch.Bradley@Eng.Sun.COM (05/08/91)

> All I can say is, the Forth community must be a lot smaller than I thought
> it was.  (Someone once told me that there were about 150 Forth vendors.)

In the early phases of the standards effort, the TC sent out hundreds
of copies of a questionnaire.  They tried to send it to every vendor they
could locate.  The questionnaire was fairly detailed, asking for information
about product's compliance and areas of noncompliance with existing standards,
areas where the standard should be improved, and other things.  It also
asked for copies of product manuals so the TC could learn details of these
implementations.

The response was underwhelming.  The TC got very few responses back.

> In fact, the big weakness of my proposed criteria is
> that they allow all six model systems to come from a single vendor.

I presume that citing 6 systems from the same vendor would not satisfy
the spirit of your requirement.  If so, then this criterion would be
useless; I could justify anything I wanted based on different versions
of Forthmacs.

> Specific examples?
> ONLY/ALSO.

Maybe, but there are serious problems with the semantics of VOCABULARY
and differences in the implementation of SEAL .  Also, in order to
make the ALSO/ONLY wordset complete, you need PREVIOUS, which probably
wouldn't "make the cut", and you also need some way to save and restore
the search order, which wouldn't make the cut.

>  TO.

Maybe.  It depends on how strictly you construe the "no semantic differences"
requirement.  Also, TO is only useful in the context of VALUE , which might
not satisfy the requirement, and with locals, which definitely would not
satisfy the semantic requirement.

> Conditional compilation.

Semantic differences exist.

> FOR...NEXT.

I doubt it.

> Probably file systems

I'm quite certain that it would not have been possible to achieve a
coherent, useful file system wordset based upon your proposed criteria.

> Probably much of floating point (ditto).

Yes, I expect that much of the floating point wordset would have passed.
But what about the rest?  A wordset with gaping holes is crippled.

> Almost certainly you could find two
> or three strings packages to meet these criteria.

Perhaps.  The only example of a strings package that would come close
is FSTRINGS, and I don't know of any Forth systems that come with it.

> And given the number of vendors on the TC, it should take no more than 12
> months and a fraction to meet this requirement for the most fevered products
> of the TC's imagination.  Why is no one willing to do this?

There are 4 significant vendors represented on the TC:
        FORTH, Inc (polyFORTH), Creative Solutions (MacForth),
        Bradley Forthware (Forthmacs), Vesta (some ROM Forths)

LMI (UR/Forth) used to be represented.  In addition, we know pretty much
about F83, F-PC, and MVP Forth from manuals and personal experience.

There is very little agreement between the products of these vendors in
terms of detailed semantics of extension packages.

> The burden of proof is on the positive, in philosophy and in
> jurisprudence....but evidently not in standards-making.

Philosophers can invent their own data.  In jurisprudence, what it really
comes down to is what the jury votes.

The ANS Forth committee relies on judgment, debate, and voting to make
its decisions.

Mitch.Bradley@Eng.Sun.COM