,---------------. | Contributions | `---------------´ ,------------------------------------------ | 2024-03-29 01:18:49 ruv wrote: | requestClarification - | see: https://forth-standard.org/standard/doc#contribution-338 `------------------------------------------ The section "[4.1.2 Ambiguous conditions](https://forth-standard.org/standard/doc#doc:ambiguous)" says: > The following general ambiguous conditions could occur because of a combination of factors: This wording seems unclear since in other places ambiguous conditions are declared using "to exist" rather than "to occur". Don't you think this phrase should sound something like this: - The following general ambiguous conditions exist and could occur because of a combination of factors: ,---------. | Replies | `---------´ ,------------------------------------------ | 2024-03-05 06:29:23 AntonErtl replies: | requestClarification - Behavior of `0 SPACES` | see: https://forth-standard.org/standard/core/SPACES#reply-1211 `------------------------------------------ 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. ,------------------------------------------ | 2024-03-06 19:19:43 ruv replies: | requestClarification - Behavior of `0 SPACES` | see: https://forth-standard.org/standard/core/SPACES#reply-1212 `------------------------------------------ > 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`). ,------------------------------------------ | 2024-03-06 20:55:19 ruv replies: | requestClarification - shadowed names | see: https://forth-standard.org/standard/tools/TRAVERSE-WORDLIST#reply-1213 `------------------------------------------ > Forth-2012 says: "Execute xt once for every word in the wordlist wid", but does not say whether "every word" includes shadowed words or not. If some standard word removes anything from a word list — this action must be explicitly specified. There are only two such words: [15.6.2.1580 `FORGET`](https://forth-standard.org/standard/tools/FORGET) and [6.2.1850 `MARKER`](https://forth-standard.org/standard/core/MARKER). Creating a named definition implies placing it into the compilation word list. This does not imply removing anything from the compilation word list (otherwise it should be specified). Before the word `TRAVERSE-WORDLIST` was introduced, a program could not detect whether the system removes a shadowed word from the word list, so the system was implicitly allowed to do it. But now **a Forth system is not allowed to remove shadowed names from the compilation word list**, I think. ,------------------------------------------ | 2024-03-07 18:41:03 AntonErtl replies: | requestClarification - shadowed names | see: https://forth-standard.org/standard/tools/TRAVERSE-WORDLIST#reply-1214 `------------------------------------------ Yes, a system that implements `marker` or `forget` needs to make words visible again that were shadowed by or after defining the marker or the forgotten word. Looking at [the CfP](http://www.forth200x.org/traverse-wordlist.html), it says explicitly: > Whether duplicated nodes are visited or not by TRAVERSE-WORDLIST is undefined. and gives an example. So the intention was to give no guarantees about that. Maybe we should put that intention explicitly in the standard text. Alternatively, if you want a guarantee, investigate existing practice, and, if it agrees with your preference, make a proposal for standardizing that. ,------------------------------------------ | 2024-03-07 18:44:05 AntonErtl replies: | requestClarification - Behavior of `0 SPACES` | see: https://forth-standard.org/standard/core/SPACES#reply-1215 `------------------------------------------ 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. ,------------------------------------------ | 2024-03-29 00:17:32 ruv replies: | requestClarification - How can the zero result be used in a Standard program? | see: https://forth-standard.org/standard/tools/NAMEtoINTERPRET#reply-1216 `------------------------------------------ I agree, the possibility of the zero result in `name>interpret` is only a restriction for programs (see also my rationale in [comment #1111](https://forth-standard.org/proposals/name-interpret-wording#reply-1118)). But what does this possibility provide for systems? Nothing! Because in any case a system can have an internal word that returns `xt|0` if it needs that. It seems, a better choice was to make `name>interpret` always return some `xt`.