[445] 2026-08-16 09:01:47 ruv wrote:

requestClarification - Revise the Two's Complement Wrap-Around Integers

The is a proposal: 2s-Complement Wrap-Around Integers (html source in the Forth-Standard repository). It was accepted in 2015. Apparently, it was accepted only on a conceptual level, not in the wording, as a note says: "accepted, further wordsmithing".

1. There is a typo in the range 2^(n-1)<=x<2^(n-1) (the start and end of the range is the same). It should be -2^(n-1) <= x < 2^(n-1), assuming that exponentiation has higher precedence than the unary minus.

2. There is an inconsistency: the proposal suggests to remove "Programs that use flags as arithmetic operands have an environmental dependency." from 3.1.3.1, but it does not formally require that the representation of true is equal to the representation of -1, and does not make flag a subtype of u and n.

• NB: the phrase "n is the number of bits in the result" does not mean that n is the number of bits in the cell.

Given that the number of bits in the cell is arbitrary (when it is greater than 16), I would prefer not to make flag a subtype of u or n. This would allow implementations to use part of the cell for metainformation (for example, to distinguish addresses from other numbers) and also to perform some runtime checks — as allowed by Forth-2012.

[r1711] 2026-08-03 07:03:24 AntonErtl replies:

requestClarification - Inconsistent semantic description in `CELLS`

What does "the size of -3 cells" mean?

What does -3 mean? One definition is that it is the result of a subtraction. Others are "magnitude of loss or deficiency".

You can use these (and probably other) definitions to think about negative sizes. E.g., when you subtract one address from another one, the result may be negative. When you allot a negative size, you deallocate dictionary space.

ambiguous condition on overflow

Actually, I see the text that references cells only in the description of the proposal, not in the normative part, and, OTOH, it's not obvious to me that the standard without the proposal makes overflow explicitly ambiguous. If we specify explicitly that cells wraps around, it becomes not only obvious that the result is probably not what the programmer wants, but also what the result is, which is much better than an ambiguous condition.

Concerning the stack diagram, the usual approach is to write ( n1|u1 -- n2|u2 ). If we want refined stack diagrams, I think that would be a different proposal that affects a lot of words. I don't agree that we should only specify the intersection of n and u, but if we wanted that, the stack diagram would be ( +n1 -- +n2 ).

Concerning your alternative text: it is correct, but harder to understand. Given that there has never been a question about what cells (as currently defined) means, not even for corner cases, I don't think that the alternative text is an improvement.

[r1712] 2026-08-03 08:22:03 AntonErtl replies:

requestClarification - Inconsistent semantic description in `CELLS`

Thinking about it again, the alternative text (together with the 2s-complement proposal) describes exactly what happens if the result does not fit in a cell, while the current text does not, so the alternative text is more appropriate for the normative text, while the current text is appropriate for the rationale.

When does it matter? E.g., with the well-defined result for all n|u, the distributive law "+ cells is equivalent to cells swap cells +" holds, while with an ambiguous condition or a lack of definition, it does not or is at least questionable.

Cell+ and char+ are also affected. Chars, OTOH, is no longer affected, thanks to the "1 chars = 1" proposal.

[r1713] 2026-08-03 12:00:37 FrancoisLaagel replies:

requestClarification - BYE Semantics Needs Clarification

The reference implementation of QUIT, even though it is not normative, should at the very least not be misleading. Bernd/Anton proposed the required fixes three years ago. They are not visible in "Forth 200x Draft 21.1 9th January, 2025."

[r1714] 2026-08-03 23:09:32 ruv replies:

requestClarification - Inconsistent semantic description in `CELLS`

Actually, I see the text that references cells only in the description of the proposal, not in the normative part, and, OTOH, it's not obvious to me that the standard without the proposal makes overflow explicitly ambiguous.

It is in 4.1.2. The omission in the proposal was mentioned by Peter Knaggs.

---

I don't agree that we should only specify the intersection of n and u, but if we wanted that, the stack diagram would be ( +n1 -- +n2 ).

There is a subtle point about the differences between data types and arrow types.

In Forth, data types and arrow types constitute two distinct sorts of types. Data types are inhabited by data objects, whereas arrow types are inhabited by Forth definitions. Each sort forms a bounded lattice under the subtyping relationship. Intersection and union of types are defined as the meet and join induced by the subtyping order.

Let's denote intersection of data type with the symbol "^".

The intersection of the data type n and u is +n (that is their meet) : ( n^u ) = ( +n ).

But the arrow type ( n -- n ^^ u -- u ) is not equivalent to the arrow type ( +n -- +n ), that is ( n^u -- n^u ). The type ( n -- n ^^ u -- u ) is inhabited by all and only those Forth definitions that inhabit both ( n -- n ) and ( u -- u ) arrow types.

Unlike data types, arrow types are ordered contravariantly in their argument types and covariantly in their result types. Consequently, the arrow type ( n|u -- n|u ) is a subtype of neither ( n -- n ) nor ( u -- u ). Therefore, a definition with the arrow type ( n|u -- n|u ) cannot be used in a context where ( n -- n ) is required. For example, if the word cells were assigned the type ( n|u -- n|u ), then the phrase ( d n ) cells ( n|u ) sm/rem would be formally ambiguous due to data types mismatch.