6.1.2230 SPACES CORE

To honor the "greater than zero"

  : SPACES 0 MAX 0 ?DO SPACE LOOP ;

Also, it does not describe explicitly what to do if n is less than 0. Should it does nothing, or is it an ambiguous condition.

Can we use u instead of n in the specification?

Testing Gforth, iforth, lxf, SwiftForth, VFX, all but lxf do nothing on -1 spaces. lxf does not just output spaces, but other data.

One possible interpretation of the statement is like a program: If the condition is not satisfied, skip the rest and do nothing. However, it is better to make the other case explicit, even if the idea is to do nothing.

My guess is that the intention was to do nothing if n<0. Changing to u would break programs that rely on the interpretation outlined above and implemented in most Forth systems. I would just add an "otherwise" clause. Of course, if you can provide good evidence that there are no such programs, we could change the n to u.

Interestingly, Forth-83 specifies +n and specifies the "+n is zero" case. This makes is more likely that the extension to "n" is intentional and that the interpretation outlined above is intended.

Interestingly, Forth-83 specifies +n and specifies the "+n is zero" case.

For comparison:

• Forth-79: SPACES ( n -- ) Transmit n spaces to the current output device. Take no action for n of zero or less.
• Forth-83: SPACES ( +n -- ) Displays +n ASCII spaces. Nothing is displayed if +n is zero.
• Forth-94: SPACES ( n -- )
• Forth-94: AT-XY ( u1 u2 -- )

In Forth-79 a negative argument is allowed.

In Forth-83 a negative argument is disallowed. I.e., an ambiguous condition exists if n < 0. So, a system may display an error message and abort in this case, as well as take no action.

Evolution of TYPE:

• Forth-79: TYPE ( addr n -- ) No action takes place for n less than or equal to zero.
• Forth-83: TYPE ( addr +n -- ) Nothing is displayed if +n is zero.
• Forth-94: TYPE ( c-addr u -- )

Evolution of -TRAILING:

• Forth-79: -TRAILING ( addr n1 -- addr n2 ) An error condition exists if n1 is negative.
• Forth-83: -TRAILING ( addr +n1 -- addr +n2 )
• Forth-94: -TRAILING ( c-addr u1 -- c-addr u2 )

Evolution of BLANK:

• Forth-79: BLANK ( addr n -- ) If n is less than or equal to zero, take no action.
• Forth-83: BLANK ( addr u -- ) No action is taken if u is zero.
• Forth-94: BLANK ( c-addr u -- )

Evolution of FILL:

• Forth-79: FILL ( addr n byte -- ) If the quantity n is less than or equal to zero, take no action.
• Forth-83: FILL ( addr u 8b -- ) No action is taken if u is zero.
• Forth-94: FILL ( c-addr u char -- )

Evolution of MOVE:

• Forth-79: MOVE ( addr1 addr2 n -- ) If n is negative or zero, nothing is moved.
• Forth-83: MOVE ( addr1 addr2 u -- ) If u is zero nothing is moved.
• Forth-94: MOVE ( addr1 addr2 u -- )

The trend is that additional checks are removed from implementations, and the case when this argument is a signed negative number is treated as non standard (a program error). If the argument is a signed number, it shall be +n (positive or zero). NB: +n ⇒ u and +n ⇒ n.

I would suggest to make SPACES ( +n -- ) — this allows implementations to take no actions for a signed negative number, and makes programs that pass a negative number to SPACES non standard (I think there are not many such programs).

If we leave n as is in SPACE — it will be inconsistent: the question is why do we allow a negative argument for this word, and don't allow it for other words (like FILL or BLANK).

Given the Forth-94 made all these changes for the other words, but chose "n" for SPACES, makes me suspect that that choice was deliberate rather than an oversight, and that there was existing practice using SPACES with n<0.