ForthNet@willett.UUCP (ForthNet articles from GEnie) (03/15/90)
Category 18, Topic 65 Message 2 Tue Mar 13, 1990 D.RUFFER [Dennis] at 23:48 EST RE: hiebeler@cs.rpi.edu (Dave Hiebeler) > I'm looking for some information about F83. Dave, check for the files F83TUTOR.ARC or F83-20.MAN. I haven't looked, but they may contain the information you are looking for. Also, FIG carries "Inside F83" by C.H. Ting which contains the following map of the header: |7|6|5|4|3|2|1|0| |---------------| | File # | | VIEW FIELD |---------| | | Block # | |---------------| | | LINK FIELD |- Link address-| | | |---------------| |1|P|S| COUNT | NAME FIELD |0| CHAR | |0| CHAR | . . . |0| CHAR | |1| CHAR | |---------------| | INNER INTERP. | CODE FIELD |- -| | ADDRESS | |---------------| | | PARAMETER FIELD . . . Call FIG at (408) 277-0668 to order you own copy. DaR ----- This message came from GEnie via willett through a semi-automated process. Report problems to: 'uunet!willett!dwp' or 'willett!dwp@gateway.sei.cmu.edu'
ForthNet@willett.UUCP (ForthNet articles from GEnie) (07/18/90)
Category 18, Topic 65
Message 4 Tue Jul 17, 1990
D.RUFFER [Dennis] at 02:17 EDT
Re: ir230@sdcc6.ucsd.edu (john wavrik)
I agree with you John, when you say that it would be illuminating if the FORTH-
83 team would present some rationale, but after asking for explainations
myself, the answers were less than satisfactory. The responses you have given
are in line with those answers, so let me try to provide another perspective.
I will not go so far as saying the work done on previous standards was
"haphazard and incompetent", but I will say that neither of the previous
standards devoted enough time to the effort to allow their decisions to be
sufficiently contemplated. From what I've heard:
Forth-79 came from a 1 day meeting
Forth-83 came from one week's efforts
Whereas: ANS Forth has taken 3 years so far
Now, you tell me who has contemplated the problems more?
> LOGIC AND BITWISE OPERATIONS
> The words AND, OR and NOT are part of the English language. They
> are used in common speech in a logical sense.
I can completely agree with that statement John, but some of your supporting
arguements leave me with questions.
The FORTH-83 standard defines "true" as:
"A non-zero value represents the true state of a flag. Any non-zero value
will be accepted by a standard word as 'true'; all standard words return a 16-
bit value with all bits set to one when returning a 'true' flag."
If, in your example, the flag "raining" was a variable that contained the
amount of water falling from the sky, then the following is precisely how it
must be stated to the computer:
> If raining = 0 then we will go to the zoo.
Since the 83 standards team decided that "Any non-zero value will be accepted
by a standard word as 'true'" then I contend that defining NOT as a bit-wise
operator is inconsistant with their own rules.
While I might agree that defining NOT as 0= is certainly redundant, I can not
agree with the problems that defining it as COM (or whatever you call a bit
inversion) is worth the problems that it causes. Having tried to convert many
programs from one to the other I can tell you it is not trivial. You claim
that doing arithmetic on flags is a poor programming practice. However, no
matter if I agree with you or not, the fact is that converting NOT to a
bitwise operator breaks code which is against the charter of the ANS Forth
team and should have been considered in the 83 standard.
So, now we have both, 0= and INVERT. Either can be used in a non- conflicting
manner. Any program can be brought into compliance with the standard with a
simple search and replace or by defining NOT to be what you need in a prelude.
A very elegant compromise!
> MONO-ADDRESSING
> [None of the reports from ANSI have indicated how this difference
> between '79 and '83 is being handled]
This has been handled by the addition of the term "execution token" which is
defined as:
"A single-cell value that identifies a word definition. Returned by ' and
FIND, consumed by EXECUTE."
There is no conflict if you do not define what part of the header (or memory)
this single-cell value points to.
> STATE-SMART WORDS
> [None of the reports from ANSI have indicated how this difference
> between '79 and '83 is being handled]
Some members of the ANS Forth team still consider this to be objectionable,
but they certainly don't have the "religious" furor that they used to have.
Some people will be happy to hear that the definition " will have both a
compiled and interpretive behaviour (i.e. state-smart) in BASIS 12.
> DO..LOOP
> [None of the reports from ANSI have indicated how this difference
> between '79 and '83 is being handled]
I'm not a very good judge here, but it appears as if the essence of the 83
standard has been preserved in the ANS standard. They have recognized the
problem, however, by including the definition for ?DO to the EXT CORE word set
which was sorely missing from the 83 standard (luckly, Lexan and Perry saved
us all :-)
> DIVISION
> Numbers and their arithmetic are not within the domain of
> computer language teams to define. Some think numbers were
> created by God -- others by the mathematicians of
> antiquity.
And still others believe they were created by the manufacturers of the
hardware that they are working on. I completely agree with you here, but why
do you go on and try to specify your concept of what is "more useful" or
"preferable"?
> It must be clear to the user which
> subset is represented and exactly how the arithmetic
> operations in the language differ from the corresponding
> operations in mathematics.
Is this not what the ANS team has done? The operating domains of all the
division operators have been carefully specified, and a simple alternative has
been provided if these domains are not sufficient. There are no
"implementation dependency" or "floating" properties to these definitions, and
any user can be sure of the results as long as the rules are followed.
When are people going to recognize that no language community has been able to
agree on the results of integer division on negative numbers. The ANS
Standard goes farther than any other language standard has gone. The 83
standard went farther than can be accepted by the community at large.
> PICK, ROLL
The 83 standard definitions appear to have survived, but they have been moved
to the EXT CORE word set so those of us that have no need for those stack
gymnastics do not need to carry them around where ever we go.
My initiation to F83 was very similar to yours John, but I did not come away
with the feeling that Forth-83 was better than what I was using. The
difference, I think, was that I did not move up from Forth-79, but I moved
down from polyFORTH. The difference in perspective is significant.
Your requirement that new additions to Forth go through many implementations,
IMHO has been followed by the ANS team. If the same requirement had been made
back in '83, we would not be having this discussion. I think that each of the
team members is accutely aware of the cost of the additions, and they are
doing the best they can in resolving some very long standing debates in Forth.
Finally, your closing remarks were excellent. I hope you don't mind if I
close with them also.
> We should *all* rewrite our systems to comply
> with the new Standard. And we should use our new found
> portability to cooperatively build structures larger than
> the wheel.
Precisely! DaR
-----
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.eduForthNet@willett.UUCP (ForthNet articles from GEnie) (07/18/90)
Category 18, Topic 65
Message 6 Tue Jul 17, 1990
GARY-S at 07:40 EDT
In an article Mario Camou Riveroll writes:
Where can I get a book that describes Forth-79....
Glen Haydon's revised (the new one !) 'All About Forth', second
edition even contains source documentation for both 79 and 83, plus
in-depth studies of most current implementations.
Gary
-----
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