From: xtifr@netcom.com (Chris Waters)
Subject: Re: Still Trying to Decide about the Standard
Date: Wed, 19 Aug 92 18:33:00 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 

In <1992Aug19.125915.14313@mintaka.lcs.mit.edu> mikc@hal.gnu.ai.mit.edu (Mike Coughlin) writes:

>In article <3956.UUL1.3#5129@willett.pgh.pa.us> ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) writes:
>>Category 2,  Topic 2
>>Message 116       Thu Aug 06, 1992
>>E.RATHER [Elizabeth]         at 00:25 EDT
>> 
>>Re the recently quoted: 
>> My own view is that a standard should solidify,
>>clarify, extract,
>> and document existing practice. The problem is in identifying "existing
>>practice."  Does it mean:
>>   (a) Stuff previously standardized (remember, it's been 10 years since FORTH-
>>83)?
>    It may have been a decade years since the 1983 standard was published, 
>but we didn't get a good write-up out of that process. I've seen several 
>people say that the '83 standard has major mistakes in it and that it
>can't be implemented. So the most important thing in my mind is to document
>what Forth was like 10 or 15 years ago in a clear consistant way.

Huh?  10 or 15 years ago???  I have to heartily disagree!!  Who cares
what stone age systems that ran on the 8080 were like?  Let's take a
look at what Forth is like today!

>The committee followed the example
>of many other standards committees in writing hard to read documentation
>that is supposed to be aimed at experts in the field. It should be for
>those with technical backgrounds who never heard of Forth and want to know 
>what is standard Forth practice.

Again, huh?  The purpose of the standard is to describe the language. 
Not to describe practice, and not to stand as a tutorial!

>>   (c) Stuff that most implementors have done some way, but their approaches
>>differ (in which case, how to find a synthesis or pick one?)?
>   This is the most difficult area a committee has to deal with. If there
>was a clear solution, then the implementors would be doing it the same
>way.

Piffle!  Even with problems that have only one simple, clear solution,
different vendors may still have used different NAMES for the same
functions!  And picking on set of names may break a lot of existing code
that uses a different set of names.  I think that the statement above is
a gross oversimplification of the problem.

>Have they consulted with vendors and publishers of PD Forth
>systems who cannot attend meetings of the committee or who have not sent
>in proposals? 

Gawd, I sure hope not, considering how thoroughly lame most of the PD
systems I've seen have been!  :-)

>>   (d) Stuff that <n> implementors do (in which case, what is <n>? And, as in
>>(c), how to resolve different approaches to the same problem?)?
>    Don't forget that the negative of this statement also deserves
>consideration. Many implementors might deliberately leave out stuff
>because they don't want it.

And they can continue to do so.  Only the CORE wordset is required by
the standard to be present in any given implementation.

> Forth was created by selecting a particular
>combination of programming methods that worked together. Adding to this
>does not make a better system. Anything that is missing from a particular
>version of Forth can be added by the user.  It doesn't have to be done
>in a standard way. What we do have to standardize is the ability to 
>add what is needed, not create a list of all commonly used programming
>ideas.

Yeah, and for that matter, why bother to standardise words like `+'? 
After all, the user can define it for himself!  It doesn't have to be
done in a standard way.  And we all know that reinventing the wheel over
and over and over again is *much* more important than getting any real
work done.  The requirement to reinvent wheels, rather than
concentrating on the task at hand is why Forth enjoys such incredible
popularity in the mainstream computing world today!

Sheesh!

I don't even know why I bother.
-- 
Chris Waters    | the insane don't | NOBODY for President!
xtifr@netcom.COM| need disclaimers | Because Nobody's perfect!!