[comp.lang.forth] various BASIS10 remarks & suggestions

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