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


,------------------------------------------
| 2024-07-01 12:02:00  ruv  wrote:
| requestClarification - Stack diagram for `{:`
| see: https://forth-standard.org/standard/locals/bColon#contribution-348
`------------------------------------------
The glossary entry for the word `{:` says:

> Compilation: _( i*x "<spaces>ccc :}" -- )_

There seems to be a typo here.  Actually, nothing can be consumed from the data stack when the word `{:` is encountered by the Forth text interpreter in compilation state.



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


,------------------------------------------
| 2024-06-29 16:15:09  AntonErtl  replies:
| requestClarification - Behavior of `represent` when buffer length is zero
| see: https://forth-standard.org/standard/float/REPRESENT#reply-1263
`------------------------------------------
> The character string shall consist of the u most significant digits of the significand

So with u=0 zero characters must be written to c-addr.  Any implementation that writes something there is buggy.  An exception for u=0 is also a bug (and in case of Gforth this bug will be fixed).

There is no basis for any claim that the u=0 case is unclear or unspecified.  And unsurprisingly, the person who claimed so presented no argument that would support such a claim.  Given that, why do you request clarification?   I don't think that the person who makes such claims will be swayed any more by an answer to such a request than by the clear wording cited above.

But given that this has been brought up, we should add at least one test case that tests u=0.  These test cases should also check that nothing is written at c-addr in that case.  So your test cases are not quite there.

Closing this because it is clearly specified.


,------------------------------------------
| 2024-06-30 13:53:25  ruv  replies:
| requestClarification - Why do we use +n and not u in the stack diagram for n>r and nr>
| see: https://forth-standard.org/proposals/fix-stack-comments-for-n-r-and-nr-#reply-1264
`------------------------------------------
In all cases where a stack parameter means the number of items on the stack, or a non-negative index of an item on the stack, this parameter shall have the data type "non-negative number" and the symbol _+n_ should be used for this parameter in a stack diagram.

### Rationale

1. We should use the smallest appropriate data type to describe a stack parameter. Thus, if it's known that a stack parameter always belongs to _+n_, we should not use the larger data type _u_ to describe this parameter.

2. We shall be consistent.  The word `depth ( -- +n )` [specifies](https://forth-standard.org/standard/core/DEPTH) that the returned parameter belongs to _+n_, that is, the stack depth cannot be more than _max-n_ (the largest usable signed integer, see [3.2.6](https://forth-standard.org/standard/usage#usage:env)). It means, for other words, a count of some items on the stack or a non-negative index of a stack item shall be described with _+n_ (or with a subtype of _+n_).

3. In practice, it is almost impossible that the stack depth increases _max-n_.  Because _max-n_ means that the stack takes amount of memory that is equal to at least a half of theoretically available data space in a Forth system.



,------------------------------------------
| 2024-07-01 17:00:40  ruv  replies:
| requestClarification - Stack diagram for `{:`
| see: https://forth-standard.org/standard/locals/bColon#reply-1265
`------------------------------------------
Probably, a more correct stack diagram is:

- Compilation: _( C: colon-sys -- colon-sys )_ _( "ccc :}" -- )_