,---------------. | Contributions | `---------------´ ,------------------------------------------ | 2026-08-16 09:01:47 ruv wrote: | requestClarification - Revise the Two's Complement Wrap-Around Integers | see: https://forth-standard.org/standard/usage#contribution-445 `------------------------------------------ The is a proposal: [2s-Complement Wrap-Around Integers](http://www.forth200x.org/twos-complement.html) ([html source](https://github.com/Forth-Standard/forth200x/blob/master/twos-complement.html) in the Forth-Standard repository). It [was accepted](https://github.com/Forth-Standard/forth200x/blob/91f1ed9c756aac27f57e939c270b5f2c84262427/meetings/2015-notes#L56) 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](http://www.forth200x.org/twos-complement.html#:~:text=range%202%5E%28n%2D1%29%3C%3Dx%3C2%5E%28n%2D1%29) `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](http://www.forth200x.org/twos-complement.html#:~:text=Remove%20%22Programs%20that%20use%20flags%20as%20arithmetic%20operands%20have%20an%20environmental%20dependency%2E%22%20from%203%2E1%2E3%2E1%2E) to remove "Programs that use flags as arithmetic operands have an environmental dependency." from [3.1.3.1](https://forth-standard.org/standard/usage#subsubsection.3.1.3.1:~:text=Programs%20that%20use%20flags%20as%20arithmetic%20operands%20have%20an%20environmental%20dependency%2E), 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](http://www.forth200x.org/twos-complement.html#:~:text=where%20n%20is%20the%20number%20of%20bits%20in%20the%20result) "`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. ,---------. | Replies | `---------´ ,------------------------------------------ | 2026-08-03 07:03:24 AntonErtl replies: | requestClarification - Inconsistent semantic description in `CELLS` | see: https://forth-standard.org/standard/core/CELLS#reply-1711 `------------------------------------------ > What does "the size of -3 cells" mean? What does -3 mean? [One definition]( https://en.wikipedia.org/wiki/Negative_number#As_the_result_of_subtraction) is that it is the result of a subtraction. [Others](https://en.wikipedia.org/wiki/Negative_number) 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. ,------------------------------------------ | 2026-08-03 08:22:03 AntonErtl replies: | requestClarification - Inconsistent semantic description in `CELLS` | see: https://forth-standard.org/standard/core/CELLS#reply-1712 `------------------------------------------ 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. ,------------------------------------------ | 2026-08-03 12:00:37 FrancoisLaagel replies: | requestClarification - BYE Semantics Needs Clarification | see: https://forth-standard.org/standard/tools/BYE#reply-1713 `------------------------------------------ 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." ,------------------------------------------ | 2026-08-03 23:09:32 ruv replies: | requestClarification - Inconsistent semantic description in `CELLS` | see: https://forth-standard.org/standard/core/CELLS#reply-1714 `------------------------------------------ > 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](https://forth-standard.org/standard/doc#doc:ambiguous:~:text=producing%20a%20result%20out%20of%20range). The omission in the proposal [was mentioned](https://github.com/Forth-Standard/forth200x/blob/91f1ed9c756aac27f57e939c270b5f2c84262427/twos-complement.html#L69-L78) 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](https://en.wikipedia.org/wiki/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](https://en.wikipedia.org/wiki/Subtyping#Function_types) 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.