ir230@sdcc6.ucsd.edu (john wavrik) (06/05/90)
Mitch Bradley writes: > So, "NOT" is no longer a standard word (and in actual fact, > "NOT" has not been portable since 1983). This is not the case. The Forth-83 Standard was quite specific. It states that NOT will perform a one's complement of its argument (see p. 36) and it further states that all standard words returning a "true flag" must return a number with all bits set (p. 10). There is no ambiguity on this point -- all standard systems behaved in the same way. > Instead, the word "INVERT" > means bitwise logical inversion, no questions asked, and the word > "0=" means flag negation. > Again, those people who insist on using "NOT" in their application > are free to define it at the start of their application, to mean > whatever they insist that it should mean. Let us examine the case of someone who has a body of Forth-83 code to run on a system which adheres to the proposed Standard -- or perhaps someone who wants to type in some code (adhering to the Forth-83 Standard) found in an article on Forth Dimensions or JFAR. Since NOT is not a word in the proposed standard, the code will not run -- IT IS BROKEN. Moreover, it is broken in a serious way -- it can only be fixed by rewriting code. In spite of what Mitch Bradley seems to think, one cannot just add a definition of NOT as a prelude to fix the code. The original code used NOT (as was the Forth-83 Team's intent) to function in both a boolean and bitwise sense. For this to be possible on the new system, standard words leaving a true flag would have to leave a number with all bits set. I would assume that those dissenting members of the ANSI team object to this stipulation (since most Forth-79 and FIG-Forth used 1 for true). The only fix is for the user to go through the code replacing NOT by 0= or INVERT according to its use. Current code *will* be broken by the proposed Standard. Quite Frankly I think that rewriting code (as well as any books and instructional material we may have written) is to be expected when we change Standards. This is why we should not change Standards often and why a proposed Standard should be worked on until it is damned good. John J Wavrik jjwavrik@ucsd.edu Dept of Math C-012 Univ of Calif - San Diego La Jolla, CA 92093