rcstjs@eutws1.win.tue.nl (Jan Stout) (03/21/90)
1. >COLROW I don't like the unpredictable operation of this word (which arguments lead to proper operation) and would therefore like to see some variables like #COLS and #ROWS (meaning the max # of colums, max # of rows resp. on the current output device...) to enter the Standard. A value of 0 could signify a non-COL/ROW oriented outputdevice. (Is there an account available of Forths using the y x -AT syntax?) 2. ?KEY Hasn't anyone read Brodie's Thinking Forth ??? I'd say ?KEY's primary function is to establish if a key is struck, yes or no. Clearly this reflects a boolean function. I'd suggest KEY? as the proper name for this function, bearing in mind Brodie's Forthics. 3. S>D and D>S These words use the S to indicate single precision numbers. Throughout the remaider of the Standard the single-precision-type-indication is simply omitted. At first sight >D and D> seem appropriate, but D> should stand for `double precision greater than' so other analogies are called for. My suggestion is N>D and D>N because of the abbreviation of singles in stackcomments. 4. COMPILE Can anyone explain to me why a definition of : COMPILE >R DUP 3 + >R C@ C, ( store the JSR ) @ , ; wouldn't run on subroutine threaders? 5. ?DO I'd say TD never has implemented his own DO-LOOP, since during compilation ?DO's extra adres can be seen by LOOP as just another LEAVE reference and be solved accordingly. Whether this should be called `smart' is ^2U. (Why not let the orig dest duo be sys anyway?) 6. INVERT NOT's renaming because of F79 ad FIG compatibility strikes me as rather nonconsistent: the 79 NOT comes from an environment where 1 instead of -1 meant TRUE, so `and' and `or' operators could be implemented by * and + respectively. The F83 Standard however, discarded of this (inefficient) concept and made -1 truth, thereby condemning NOT to bitwise operation as a member of the AND, OR and XOR team. It seems strange for NOT to adhere to the old valuation-model, especiallly when 0= is available to achieve the same goal. 7. #>, EXPECT, FIND, FORGET I'd prefer all string operators to accept 'em uncounted and deliver 'em counted, like TYPE ad WORD do, to increase flexibility and uniformity. PS: I've been looking for "'s definition is the F83 standard, but found none...
wmb@MITCH.ENG.SUN.COM (03/23/90)
> 2. ?KEY > Hasn't anyone read Brodie's Thinking Forth ??? > I'd say ?KEY's primary function is to establish if a key is struck, > yes or no. Clearly this reflects a boolean function. I'd suggest KEY? > as the proper name for this function, bearing in mind Brodie's Forthics. There was a bitter argument about this. Most of the committee members appeared to prefer KEY? ( -- flag ), but there were a few who were adamant about having the function return the character if one is available. That cadre basically threatened to shoot down the whole proposal if they didn't get their way (a simple majority is not enough to pass a proposal). The rest of us decided to go along, because we wanted the functionality badly enough to accept the second-best packaging of it. The name was set at ?KEY so that us reasonable folks can then define KEY? to do the right thing. > 4. COMPILE > Can anyone explain to me why a definition of > : COMPILE >R DUP 3 + >R C@ C, ( store the JSR ) @ , ; > wouldn't run on subroutine threaders? (Note: above definition contains several typos, but the intent is nevertheless clear). You can't be sure that the following token has been compiled as a jsr. It might have been expanded in-line or even peephole-optimized. There is little point in using subroutine threading if you are not going to do some in-line machine code expansion. Subroutine threading without some in-line expansion is a lose, both in space and time, on most processors. > 5. ?DO > I'd say TD never has implemented his own DO-LOOP, since during compilation > ?DO's extra adres can be seen by LOOP as just another LEAVE reference and > be solved accordingly. Whether this should be called `smart' is ^2U. > > (Why not let the orig dest duo be sys anyway?) I argued this point rather vehemently at the next-to-last meeting. However, since Wil Baden, the architect of the current control flow scheme, wasn't present, the committee was uncomfortable about acting on it. > 6. INVERT > NOT's renaming because of F79 ad FIG compatibility strikes me as rather > nonconsistent: the 79 NOT comes from an environment where 1 instead of -1 > meant TRUE, so `and' and `or' operators could be implemented by * and + > respectively. The F83 Standard however, discarded of this (inefficient) > concept and made -1 truth, thereby condemning NOT to bitwise operation > as a member of the AND, OR and XOR team. It seems strange for NOT to > adhere to the old valuation-model, especiallly when 0= is available to > achieve the same goal. This is a religious issue about which different people have different strongly-held opinions. The committee argued about this for 2 *years* before finally agreeing on the INVERT compromise. > PS: I've been looking for "'s definition is the F83 standard, but found > none... It's not in the F83 standard, but it is present in several widely-distributed systems. Unfortunately it isn't the same in all systems. F83, F-PC, and MasterForth use it as " ( -- adr len ) while MacForth uses " ( -- adr ) Fortunately, Don Colburn is a very reasonable individual, and he was willing to compromise on this issue. Mitch Bradley
andrew@idacom.uucp (Andrew Scott) (03/24/90)
> 4. COMPILE > Can anyone explain to me why a definition of > : COMPILE >R DUP 3 + >R C@ C, ( store the JSR ) @ , ; > wouldn't run on subroutine threaders? The main problem is that COMPILE assumes that it is followed by a "jsr xx", when many (most?) subroutine threading Forths optimize certain code sequences. For example, if the code for DUP is inlined for speed when it is compiled, then ... COMPILE DUP ... won't work very well. I'm now of the opinion that COMPILE should have been defined similar to EXECUTE: COMPILE ( execution token -- ) COMPILE DUP would be replaced by ['] DUP COMPILE. While we're at it, let's get rid of [COMPILE] also: ['] IF EXECUTE replaces [COMPILE] IF Both of these work fine with optimizing subroutine threaded Forths. The problem with COMPILE and [COMPILE] (and even BASIS's POSTPONE) is that they are all adding more prefix operators to the language. It's much more useful for words to take their arguments from the stack instead of the input stream (like [COMPILE] and some versions of COMPILE). The examples above show that ' and ['] (or just ' if you like state smart words) help factor things. Rob Chapman has implemented both these ideas in his bot-Forth. I'm doing the same for my current project. -- Andrew Scott | mail: andrew@idacom.uucp | - or - {att, watmath, ubc-cs}!alberta!idacom!andrew | - or - uunet!myrias!aunro!idacom!andrew Mark Messier: he's gotta have Hart!
wmb@MITCH.ENG.SUN.COM (03/24/90)
> Andrew Scott writes: > I'm now of the opinion that COMPILE should have been defined similar to > EXECUTE: > > COMPILE ( execution-token -- ) > > COMPILE DUP would be replaced by ['] DUP COMPILE. > ... > The problem with COMPILE and [COMPILE] (and even BASIS's POSTPONE) is that > they are all adding more prefix operators to the language. It's much more > useful for words to take their arguments from the stack instead of the > input stream (like [COMPILE] and some versions of COMPILE). The examples > above show that ' and ['] (or just ' if you like state smart words) help > factor things. I have a proposal to this effect in front of the ANS Forth committee right now. The word is called COMPILE-TOKEN (it can't be called just COMPILE , because that would break a lot of existing code), and it works just like it says above. It came up for discussion at the last meeting, and went the way that a lot of my proposals seem to go: A majority agrees, but the minority is large enough that the proposal goes into limbo. On this particular issue, after the discussion was over, I came up with what I think are airtight answers to all of the objections raised during the discussion, and published those answers in a technical comment. Maybe next meeting things will start to look up. All you folks could help by calling up ANSI Forth committee members and voicing your support of COMPILE-TOKEN . Mitch (down with prefix operators in Forth!) Bradley