[378] 2025-06-13 14:21:51 JimPeterson wrote:

requestClarification - Can This Be Set?

There's no verbiage in the description explaining that the value stored at >IN can be modified by the user, yet the test cases perform exactly that. Must conforming implementations allow this behavior? Shouldn't there be an explicit note, rather than just an implication, that doing so will cause the very next parsing of a word to start at the new address, and that values stored at >IN must be char-aligned, and that it's an ambiguous condition to set this value to a region outside of the area returned via SOURCE?

[r1445] 2025-04-24 16:17:52 ruv replies:

testcase - First Tests Seem Wrong

It's a known problem. For example, see the comp.lang.forth discussion "Is there a hole in the SEARCH wordset?" from 2008 (and many other). Since then, no one has prepared a proposal on this matter.

but the first test uses the words FORTH and GET-ORDER after calling ONLY. An otherwise conforming implementation could fail this test,

Yes. Also, ONLY and FORTH words can be absent at all (because they are in the Search-Order extension word set), and then an otherwise conforming implementation will fail this test too.

it would be better if FORTH was also required in "the minimum search order"

It cannot be unconditionally required because FORTH belongs to the Search-Order extension word set. But it can say: "If the word FORTH is provided, the minimum search order shall include this word".

This is consistent with practice: typically, if the words ONLY and FORTH are both provided, the phrase ONLY FORTH works as expected.

---

The term "minimum search order" can be confusing. A better option: "minimum operational search order" (see a discussion in comp.lang.forth).

[r1446] 2025-05-23 15:27:07 LeonWagner replies:

proposal - Octal prefix

SwiftForth and SwiftX always used '&' as the octal prefix for at least 20 years. We would be fine with adding that the standard, although it is rarely used in practice.