,---------------. | Contributions | `---------------´ ,------------------------------------------ | 2024-09-19 14:31:15 gethbo wrote: | requestClarification - Clarification on what constitutes an ambiguous condition for this word. | see: https://forth-standard.org/standard/core/PICK#contribution-363 `------------------------------------------ The description for this word says: "...An ambiguous condition exists if there are less than u+2 items on the stack before PICK is executed" In this example with 3 items on the stack: (x2 x1 x0 2 -- x2 x1 x0 x2) This example worked in gforth - However u+2 = 4 and since 3 < 4 this is an ambiguous condition. I might be missing something here but shouldn't this read : "An ambiguous condition exists if there are less than u+1 items on the stack before PICK is executed" ,---------. | Replies | `---------´ ,------------------------------------------ | 2024-09-04 17:01:50 ruv replies: | requestClarification - Behavior on oversized WORD | see: https://forth-standard.org/standard/core/WORD#reply-1301 `------------------------------------------ > What is the behavior for words of intermediate length? Ambiguous condition (my understanding is this is the case traditionally)? It's up to the system. A system is allowed to support definition names longer than 31 characters. Then, the size of the region identified by `WORD` must be at least the maximum supported definition name length. An ambiguous condition exists if the system encounters a name that is longer than the maximum supported length, as [4.1.2 Ambiguous conditions] says: - a definition name exceeded the maximum length allowed (3.3.1.2 Definition names); In this case a system may truncate the name, may throw an exception, or may take other cations (see [3.4.4 Possible actions on an ambiguous condition](https://forth-standard.org/standard/usage#usage:ambiguous)). In the future, systems may be required to throw an exception with a specific throw code in this case (in the frame of eliminating some ambiguous conditions). [3.3.1.2 Definition names](https://forth-standard.org/standard/usage#usage:names) says: - Programs with definition names longer than 31 characters have an environmental dependency. > If I'm understanding correctly this also means that an implementation that, e.g., returns counted strings where only the region they occupy is available to the program even if this should be shorter than 33 characters is not compliant? A don't see any statement that disallows a program to modify the region identified by `WORD`. If a program is allowed to do it, than yes, this region shall be at least 33 characters long, regardless how many characters are occupied. ,------------------------------------------ | 2024-09-05 08:18:41 ruv replies: | requestClarification - Behavior on oversized WORD | see: https://forth-standard.org/standard/core/WORD#reply-1302 `------------------------------------------ I missed it, there is a better option in the section [4.1.2 Ambiguous conditions](https://forth-standard.org/standard/doc#doc:ambiguous): - string longer than a counted string returned by 6.1.2450 `WORD`; Also, the section [4.1.1 Implementation-defined options](https://forth-standard.org/standard/doc#subsection.4.1.1) says that a standard system shall document the size of buffer for `WORD`: - size of buffer at 6.1.2450 `WORD` (3.3.3.6 Other transient regions); It is worth nothing that a program is not allowed to modify the contents of the region identified by `WORD` **when** its address **become invalid** as specified in [3.3.3.6 Other transient regions](https://forth-standard.org/standard/usage#usage:transient). In some systems this buffer's location is _sliding_, since it is offset from `here`, and compiled code may reside at past addresses of the buffer. ,------------------------------------------ | 2024-09-05 16:32:34 soundwave replies: | requestClarification - Behavior on oversized WORD | see: https://forth-standard.org/standard/core/WORD#reply-1303 `------------------------------------------ - string longer than a counted string returned by [6.1.2450 WORD](https://forth-standard.org/standard/core/WORD]); would seem to only apply to those words longer than a counted string, not necessarily larger than the transient region for WORD. The relevant ambiguous condition seems to actually be - parsed string overflow; which afaict can only apply to WORD, which makes sense. Just a little confusing as it does not seem to be mentioned anywhere but in the list of ambiguous conditions that parsing can overflow, not even in the section for parsing. Furthermore there's multiple passages that speak to WORD being limited by counted string length, which is fair as this will certainly be true for some systems, but won't be for minimal ones. ,------------------------------------------ | 2024-09-05 17:19:16 ruv replies: | requestClarification - Behavior on oversized WORD | see: https://forth-standard.org/standard/core/WORD#reply-1304 `------------------------------------------ Correction: "worth nothing" should be read as "worth noting" ----- > The relevant ambiguous condition seems to actually be > > - parsed string overflow; > > which afaict can only apply to WORD, which makes sense. I cannot agree. Have a look at the following pairs: - About parsed string: - **Implementation-defined option:** maximum size of a parsed string (3.4.1 Parsing); - **Ambiguous condition:** parsed string overflow; - About `WORD`: - **Implementation-defined option:** size of buffer at 6.1.2450 `WORD` (3.3.3.6 Other transient regions); - **Ambiguous condition:** string longer than a counted string returned by 6.1.2450 `WORD`; The association of "parsed string overflow" with "size of buffer at 6.1.2450 WORD" seems incorrect. Also, [3.4.1 Parsing](https://forth-standard.org/standard/usage#usage:parsing) says: "the number of characters parsed may be from zero to the implementation-defined maximum length of a counted string". I think, this is about any parsing string (including strings parsed with `PARSE`, `PARSE-NAME`, `S"`, `C"`, etc). But parsing with `WORD` just imposes stronger restrictions. ----- > Just a little confusing as Agreed. This should be fixed. ,------------------------------------------ | 2024-09-19 14:36:24 ruv replies: | proposal - Special memory access words | see: https://forth-standard.org/proposals/special-memory-access-words#reply-1305 `------------------------------------------ @AntonErtle [wrote](https://forth-standard.org/proposals/special-memory-access-words#reply-1259): > #### addr vs. c-addr > > Yes, as far as the standard is concerned, `addr` has the least alignment requirements. But it is also used in practice as a stand-in for any kind of address, including addresses with stricter alignment requirements (I am sure I am not alone in this usage of `addr`); so using `c-addr` makes the intent of not requiring alignment clearer to the reader. If this specification is a part of the standard, it **shall be consistent** with other parts of the standard. So we should either use `addr` (in accordance with the language of the standard), or use `c-addr` and replace `addr` with `c-addr` in *all parts* of the standard (i.e. change the language of the standard). Don't you agree? Perhaps this change of the language of the standard should be presented as a separate proposal. ,------------------------------------------ | 2024-09-20 04:19:48 AntonErtl replies: | requestClarification - Clarification on what constitutes an ambiguous condition for this word. | see: https://forth-standard.org/standard/core/PICK#reply-1306 `------------------------------------------ In your example there are 4 items on the stack. You have to count the `2`, too.