,---------------.
| Contributions |
`---------------´


,------------------------------------------
| 2025-06-30 18:01:34  EricBlake  wrote:
| comment - Typo in 3.2.1.2
| see: https://forth-standard.org/standard/usage#contribution-379
`------------------------------------------
Where the standard currently mentions:
```
The characters "a" though to "z" should be treated the same as "A" though "Z",
```
it should instead mention
```
The characters "a" through to "z" should be treated the same as "A" through "Z",
```
that is, fix both instances of "though" to "through".



,------------------------------------------
| 2025-06-30 18:21:53  EricBlake  wrote:
| requestClarification - Can balanced () be nested inside ( and .( comments?
| see: https://forth-standard.org/standard/core/p#contribution-380
`------------------------------------------
The text is unclear on whether "ccc)" as the text to be parsed after recognition of the "(" and ".(" words may include nesting of ().  Table 2.1 in 2.2.3 Parsed text notation states merely
```
 ccc		a parsed sequence of arbitrary characters, excluding the delimiter character 
```
which at strict reading would state that a comment cannot contain ")" and therefore probably should not contain "(".  But in practice, it seems several Forth implementations have ALWAYS supported comments such as "( n -- n' (n modified by ...) )", and where you can quickly add another layer of () around large blocks of code if "(" automatically refills the input buffer until finding the final balancing ")".  For an example, here is the jonesforth implementation: http://git.annexia.org/?p=jonesforth.git;a=blob;f=jonesforth.f;h=5c1309574a;hb=66c569981#l216

If this is desirable, the specification for "(" and/or for the Parsed text notation definition of ccc needs to be updated to account for nesting.  If it is not desirable to mandate this (but to still allow implementations that support it), the text for "(" and ".(" should probably document that it is ambiguous behavior if "(" appears in the "ccc)" word.

https://www.reddit.com/r/Forth/comments/69nivq/is_there_a_good_way_to_do_nested_comments_in_ans/ is an interesting discussion on the topic.



,------------------------------------------
| 2025-06-30 18:50:41  EricBlake  wrote:
| comment - F.3.18 typo
| see: https://forth-standard.org/standard/testsuite#contribution-381
`------------------------------------------
"Testing of the input source can be quit dificult." Well yeah, it's well known in computer science that the halting problem is non-computable ;)  Please fix the double typo, where it seems like the intended text is "quite difficult".


,---------.
| Replies |
`---------´


,------------------------------------------
| 2025-06-14 05:39:55  AntonErtl  replies:
| requestClarification - Can This Be Set?
| see: https://forth-standard.org/standard/core/toIN#reply-1447
`------------------------------------------
`>IN` produces the address of a cell, and storing to that address is one of the standard operations one can use addresses for.  If the standard committee did not intend that, the standard would specify that explicitly, as in the case of `STATE`.

You find some of the answers to your questions in [3.4.1 Parsing](https://forth-standard.org/standard/usage#subsection.3.4.1):

> the selected string begins with the next character in the parse area, which is the character indexed by the contents of >IN. An ambiguous condition exists if the number in >IN is greater than the size of the input buffer.

That section also mentions one specific case of storing into `>IN`.

The value in `>IN` is an offset in characters, so increasing it by 1 means that the parse area now starts at the next character, even if 1 chars > 1.  So character alignment of the value in `>IN` would not make sense.

Adding "See also: 3.4.1 Parsing" to 6.1.0560 would be useful, however.

All questions are answered, so I am closing this.  If anything is unclear, please reopen it.




,------------------------------------------
| 2025-06-17 10:22:49  StephenPelc  replies:
| proposal - Octal prefix
| see: https://forth-standard.org/proposals/octal-prefix#reply-1448
`------------------------------------------
VFX Forth does not support a '&' prefix for octal and we have no plans to add it, although implementation is trivial.
.
However we do support leading '0x' and trailing 'h' for hexadecimal.

Stephen