NetNews Usenet Archive 1992 #18/NN_1992_18.iso/spool/comp/lang/forth/2985

Internet Message Format | 1992-08-20 | 7.6 KB

Path: sparky!uunet!olivea!mintaka.lcs.mit.edu!hal.gnu.ai.mit.edu!mikc
From: [e-mail] (Mike Coughlin)
Newsgroups: comp.lang.forth
Subject: Re: Still Trying to Decide about the Standard
Message-ID: <[e-mail]>
Date: 20 Aug 92 13:21:57 GMT
References: <3956.UUL1.3#[e-mail]> <[e-mail]> <vz!n=[e-mail]>
Sender: [e-mail]
Organization: /etc/organization
Lines: 138

In article <vz!n=[e-mail]> [e-mail] (Chris Waters) writes:
>In <[e-mail]> [e-mail] (Mike Coughlin) writes:
>
>>In article <3956.UUL1.3#[e-mail]> [e-mail] (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!
>
   Forth got its real start on the PDP-11. I remember the days when the
8080 was popular, and Forth wasn't used nearly as much as it is now.
But don't confuse the systems with the language. Forth has a certain
way of doing things that is the same now as it was fifteen years ago.
If we take a look at what Forth is today, we see a hodge-podge of
uncoordinated features in search of documentation. It reminds me of the
programming systems used on the mini computers twenty years ago. When
I first saw Forth I was amazed at how much improvement could be made
in programming by throwing features away instead of adding them.

>>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!
>
   Forth cannot be described without describing its practice. Forth is
not just a collection of words. It is a way of doing things that is
very much different from the way other computer langauges do things.
I don't say that the standard should be a beginners tutorial, but if
it is to describe Forth, it must have tutorial material in it. And
if this material is unclear, the document will be useless.

>>>   (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 one 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.
>
   Well I can certainly agree about my statement being a gross
oversimplification of the problem. In fact, I even think all the messages
I've seen over the past few years about the standard have been
oversimplifications.
   If the buyers of Forth systems would state that they will not fork
over their cash for systems that have different names, then the vendors
would start using the same names. If people who publish code would
always use standard words, system buyers would know what word names
to look for. But it hasn't happened yet. Having a new feature is
always more interesting than using the same old words. I don't expect
a new standard document to change that.

>>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.
     So we have a standard, but we don't have to follow it. We can
use the core words to change everything else. I don't like the new
core words any better than the old core words, so I wonder which
I should use.
>
>> 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!
>
    We don't have to worry about '+' being standardized. The cpu
designers have done that for us. Its difficult words like '/' that
we have to worry about.
    The requirement to write new Forth standards keeps us from
concentrating on the task at hand. The publication of new algorithims
in the C language is what keeps C in the mainstream of popularity
in the computing world today. What could we do to have new algorithims
published in Forth instead? After the 83 standard was published,
Laxen & Perry put their Forth system in the public domain. So we had
not only a standard collection of Forth words, but a system that ran
the same way on different platforms. A few applications were published
using F83 and an attempt was made to publish portable code. But that
has died down because there is to be an ANSI standard. We have had
the chance to publish portable code in the past, but people don't
do it. There is always some excuse to tinker with the system, change
the words, make some improvements, include machine code for one
particular platform, and so on. Without the desire to produce
portable code, it woun't happen. It doesn't matter if Forth is too
old fashioned or if it has just had the latest wizzy thing added to
it.

>Sheesh!
>
>I don't even know why I bother.
   I know why I bother. I don't want to have to work with C programs.
The main thing I hate about these mesages is they take too long to
read. And vastly too long to write.