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

Text File | 1992-08-19 | 4.2 KB | 82 lines

Newsgroups: comp.lang.forth
Path: sparky!uunet!snorkelwacker.mit.edu!mintaka.lcs.mit.edu!hal.gnu.ai.mit.edu!mikc
From: [e-mail] (Mike Coughlin)
Subject: Still Trying to Decide about the Standard
Message-ID: <[e-mail]>
Sender: [e-mail]
Organization: /etc/organization
References: <3956.UUL1.3#[e-mail]>
Date: Wed, 19 Aug 1992 12:59:15 GMT
Lines: 70

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. Once
that is done, then we can think about adding new stuff. I don't think
basis accomplishes this first goal. 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. Members of the committee are mainly
concerned with adding new features to Forth that they use with other
systems instead of writing down the simple old boring way Forth does
things so well.

>   (b) Stuff that one implementor with lots of users has done for years?
   If one implementor has done something for years and nobody else has
copied it, then I think that something has been condemmed and rejected.

>   (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. Resolving this problem requires basic scientific research. Have the
members of the committee been selected because of their knowledge and
experience in symbolic logic, abstract mathematics, and computer
science? 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? Can we expect a worthwhile resolution of these problems
unless these things are done?

>   (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. 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.
    There are things in the standard that could be removed because any
implementor could have them but very few do. There is a bias to add
too many things to the standard.

>
>These are the issues the standards team has wrestled with to the best of its
>ability.
    I certainly know how hard the members of the committee have worked.
I sat thru three days of meetings. But there comes a time when you
reach beyond the state of the art. Less work on the standard would have
made a better document. Cutting out about one third of the words and
editing the explanitory text for less experienced Forth users would
make a big improvement. It is up to Forth users and vendors to make
Forth more standardized; the task is too big and important to be done
by a committee.