wsbusup@eutws1.win.tue.nl (Jan Stout) (01/29/91)
FS: Well, since you asked, I'll make a few comments. >COLROW I don't like the name. I presume it is to set a cursor position on the screen. I prefer the arguments to be ( row col - ) rather than ( col row - ). I could go along with the name TAB for this. Why not AT? Anyway, let's not require it! If possible, let's remove it altogether. If it must be kept, let's not use the ugly name. How can you expect people to go along with your ( row col -- ) proposal if you don't give some example of the benefits of this factoring. Ie what is wrong with using the standard math (x,y) positioning? Perhaps you can name a word that uses fixed columns variable rows, so that it can easily be factored in N TAB/AT, the same way DO's argumentorder could be justified. ( so we have : SPACES 0 ?DO SPACE LOOP ; instead of : SPACES 0 SWAP ?DO SPACE LOOP ; ) FS: >"This Standard does not require that each word be provided in > executable form. This may the thing I like most (dislike least, perhaps) about the ANSI standard. It's the way I deal with DO LOOP in Pygmy. (Thanks to Robert Berkey) it's available in source form to load for anyone who wants it, but it doesn't burden my system. Again I don't understand your enthousiasm for FOR/NEXT over DO/LOOP. True enough using DO/LOOP often involves some stackacrobatics to get the right parameters, but then again DO/LOOP enables easier indexing "in the loop" with I so will probably execute faster. As an example: : TYPE SWAP OVER + ?DO I C@ EMIT LOOP ; instead of : TYPE FOR C@+ EMIT NEXT ; with : C@+ 1+ DUP 1- C@ ; FS: > Toronto I want the decimal point to indicate double precision (not floating point). Do indeed you use that many dpliterals??? My opinion is that the occasional use of doubles shouldn't imply an alternative syntax (use of .) that outside the forthcommunity always meant fpformat. I'd say use 0 0 for your 0. or if you've sprayed a lot of 0. in your code define a constant ie 0 0 2CONSTANT D0 and use D0 instead of 0. ... Expect to hear your replies:) Jan Stout
rob@idacom.uucp (Rob Chapman) (02/04/91)
In article <387@rc6.urc.tue.nl> wsbusup@eutws1.win.tue.nl (Jan Stout) writes: >True enough using DO/LOOP often involves some stackacrobatics to get the >right parameters, but then again DO/LOOP enables easier indexing >"in the loop" with I so will probably execute faster. >As an example: > >: TYPE SWAP OVER + > ?DO I C@ EMIT LOOP ; >instead of >: TYPE FOR C@+ EMIT NEXT ; >with : C@+ 1+ DUP 1- C@ ; This is fine for byte size cells but if you're incrementing through an array of CELL size cells, simply: : DOTS ( a \ n -- ) FOR @+ . NEXT DROP ; instead of any of: : DOTS ( a \ n -- ) 0 ?DO DUP @ . CELL + LOOP ; : DOTS ( a \ n -- ) 0 ?DO DUP I CELL * + @ . LOOP ; : DOTS ( a \ n -- ) CELL * OVER + SWAP ?DO I @ . CELL +LOOP ; I assume the stack diagram for @+ ( a -- a+ \ n ). These incrementing fetch words are some of the newer "ideas" injected into the Forth domain by Chuck. He's had a chance to see what Forth really looks like in hardware. These words usually translate to single assembler instruction, or very few. I consider these words and the FOR NEXT loop to be a better factoring of indexing and looping functionality. >Again I don't understand your enthousiasm for FOR/NEXT over DO/LOOP. There are two ways of judging a new idea: 1. Reject it and try and find ways to substantiate your rejection (you will always succeed). 2. Accept it and try it with a positive attitude. Rob
wmb@MITCH.ENG.SUN.COM (02/05/91)
> : DOTS ( a \ n -- ) FOR @+ . NEXT DROP ; > > instead of any of: > > : DOTS ( a \ n -- ) 0 ?DO DUP @ . CELL + LOOP ; > : DOTS ( a \ n -- ) 0 ?DO DUP I CELL * + @ . LOOP ; > : DOTS ( a \ n -- ) CELL * OVER + SWAP ?DO I @ . CELL +LOOP ; How about: : DOTS ( a \ n -- ) 0 ?DO @+ . LOOP DROP ; It should be easy for the compiler to figure out that it can do the optimization. Chuck wasted a lot of people's time when he introduced a new function to handle a special case of an existing construct, rather than make his compiler a little smarter. The compiler optimization would have made everybody's existing code run faster, rather than making everybody rewrite their code, which then would be incompatible with systems without FOR .. NEXT . Admittedly, DO .. LOOP is a bit of a crock, but it is a crock with a lot of history behind it, and it does in fact work. > I assume the stack diagram for @+ ( a -- a+ \ n ). These incrementing fetch > words are some of the newer "ideas" injected into the Forth domain by Chuck. > He's had a chance to see what Forth really looks like in hardware. Of course, C has had autoincrementing pointers for 20 years. In Forth, a new idea is when Chuck reinvents or finally decides to use something that has been around since the dawn of time. Then everybody decides that, if Chuck says it, it must be right. Mitch Bradley, wmb@Eng.Sun.COM
dwp@willett.pgh.pa.us (Doug Philips) (02/11/91)
In article <9102050318.AA12062@ucbvax.Berkeley.EDU>, wmb@MITCH.ENG.SUN.COM writes: > It should be easy for the compiler to figure out that it can do the > optimization. Chuck wasted a lot of people's time when he introduced > a new function to handle a special case of an existing construct, rather > than make his compiler a little smarter. The compiler optimization would > have made everybody's existing code run faster, rather than making everybody > rewrite their code, which then would be incompatible with systems without > FOR .. NEXT . > > Admittedly, DO .. LOOP is a bit of a crock, but it is a crock with a lot > of history behind it, and it does in fact work. I think you hit the nail on the head. CM strikes me (from what I've read) as one that is willing to toss crockery and start afresh with the "right" thing. As to whether X3J14 should do the same, I doubt it. Too bad that there isn't a category for <This feature is here because of our mandate for not breaking lots of code. However, this feature is being replaced by X which is what should be used to write new code.> > Of course, C has had autoincrementing pointers for 20 years. In Forth, > a new idea is when Chuck reinvents or finally decides to use something > that has been around since the dawn of time. Then everybody decides that, > if Chuck says it, it must be right. That seems to be a problem with languages defined by a visionary. -Doug --- Preferred: dwp@willett.pgh.pa.us Ok: {pitt,sei,uunet}!willett!dwp
wmb@MITCH.ENG.SUN.COM (02/13/91)
> Too bad that > there isn't a category for <This feature is here because of our mandate for > not breaking lots of code. However, this feature is being replaced by X > which is what should be used to write new code.> Ah, but there is. Look at CONVERT , >NUMBER and EXPECT , ACCEPT . >NUMBER and ACCEPT essentially perform the same functions as CONVERT and EXPECT, but they fix some problems. CONVERT requires a non-numeric character at the end of the string it's converting, which makes it a real pain to use with arbitrary strings (it also essentially forces the string returned by WORD to have an uncounted blank at the end). EXPECT returns its value in the variable SPAN, whose contents can get clobbered by the text interpreter. The "magic word" describing the category is "obsolescent". Mitch