,---------------. | Contributions | `---------------´ ,------------------------------------------ | 2025-10-25 12:50:27 finnw wrote: | testcase - Testing for non-state-smartness | see: https://forth-standard.org/standard/core/Tick#contribution-419 `------------------------------------------ I have found this test useful when modifying a non-standard Forth (that previously had a state-smart **`'`**) to adopt the standard sematics. It fails (leaving 1 instead) for the state-smart version. > `T{ : GT1 ' DUP EXECUTE 1+ ; -> }T` > `T{ 0 GT1 DROP 1+ -> 2 }T` ,---------. | Replies | `---------´ ,------------------------------------------ | 2025-10-11 07:18:16 ruv replies: | proposal - Standardize the well-known -ROT | see: https://forth-standard.org/proposals/standardize-the-well-known-rot#reply-1597 `------------------------------------------ I agree, of the options considered, the best pronunciation is "unrot", and the best name, I think, is `unrot`. Rationale: - this name is more consistent with the "un-rot" pronunciation and the naming conventions used in other standard word names; - in general, names without special characters are better than with special characters (if the special character does not have a special meaning); - note that a leading minus means "to subtract". > whether the standards body should be in the business of prescribing new behavior rather than documenting existing behavior. In fact, the standards body is also in the business of prescribing new behavior — there are numerous examples of this. Regarding existing practices, I believe it should not standardize bad practices (including unfortunate/inconsistent names). In this case, a possible solution is to standardize `unrot` and add a requirement: "If the Forth system provides the word `-rot`, that word shall have the same semantics as specified for `unrot` in this glossary entry". Standardized in this way, it allows programs to do the following: ```forth [undefined] unrot [if] [defined] -rot [if] synonym unort -rot [else] : unrot rot rot ; [then] [then] ``` Or simply: ```forth [undefined] unrot [if] : unrot rot rot ; [then] ``` > And if "unrot" is the most popular pronunciation, how hard would it be to convince implementations like gforth to add `unrot` as an alias to `-rot` just for the better etymology? It seems, there is no need to convince implementations, as this word is optional. --- As for the word inverse to `roll` — I agree, there is no need for such a word. ,------------------------------------------ | 2025-10-11 07:42:38 PeterFalth replies: | proposal - Standardize the well-known RDROP | see: https://forth-standard.org/proposals/standardize-the-well-known-rdrop#reply-1598 `------------------------------------------ I have this functionality in my Forths for a long time but with the name R>DROP. I think that is a better name. There are no other names that directly manipulate the return stack like rdup, rswap. The existing words move items to and from the return and data stack R>DROP also communicates this. I certainly did not invent R>DROP so there are also other systems using this. I have now stopped using R>DROP and put back the space! My compilers produce the same code in both cases. ,------------------------------------------ | 2025-10-12 17:13:21 obijohn replies: | proposal - Standardize the well-known -ROT | see: https://forth-standard.org/proposals/standardize-the-well-known-rot#reply-1599 `------------------------------------------ > Other options for naming: In my (perpetually) in-progress implementation, I call it `tor`, which is literally "rot" reversed :). I do have a synonym for `-rot`, though. It seems that's the naming most people tend to use. ,------------------------------------------ | 2025-10-13 18:32:13 obijohn replies: | proposal - Octal prefix | see: https://forth-standard.org/proposals/octal-prefix#reply-1600 `------------------------------------------ With the [recognizer proposal](https://forth-standard.org/proposals/recognizer-committee-proposal-2025-09-11) on the table, I'm a bit hesitant to introduce another prefix symbol into the Standard. This would limit the ability of programs to provide recognizers for their own prefixes. In fact, an octal prefix recognizer might make a very good example to include in the proposal. Common Lisp explicitly reserves a few characters solely for use by the programmer (see Figure 2-7 and the accompanying text in section [2.1.4 of the HyperSpec](https://www.lispworks.com/documentation/HyperSpec/Body/02_ad.htm)). I like that approach, but I don't think it's needed for Forth -- as long as we don't take too much away from the user. ,------------------------------------------ | 2025-10-13 18:42:49 JimPeterson replies: | comment - Interpretation of the top input parameter of PICK | see: https://forth-standard.org/standard/core/PICK#reply-1601 `------------------------------------------ I really feel like this naming is asking for trouble. I understand that the following words treat the top of the stack as just a pair of cells, not necessarily a double: ``` 2! 2>R 2@ 2R> 2R@ 2CONSTANT 2DROP 2LITERAL 2VALUE 2VARIABLE ``` But having called them names like `D!`, or `DLITERAL`, or `DVALUE`, etc., would have been a good choice that had some reasonable consistency with `F!` and `FLITERAL` and `FVALUE`, etc., but I guess that ship has sailed, and there's absolutely no correcting it without a significant overhaul and deprecation warnings. My main concern, though, is calling something `2ROLL` in the context of a system that has words like `2OVER`, `2ROT`, and `2SWAP`. Those three existing words strongly imply that words starting with `2` will treat the stack as though it is a stack of double-cell values and perform well-understood stack operations on them, such that users may (incorrectly) assume that the index supplied to `2ROLL` would be how many double-cell values are affected (minus 1). It feels only slightly less likely that they would make the same mistake with `2PICK`. ,------------------------------------------ | 2025-10-14 15:13:15 ruv replies: | proposal - Fix stack comments for N>R and NR> | see: https://forth-standard.org/proposals/fix-stack-comments-for-n-r-and-nr-#reply-1602 `------------------------------------------ @AntonErtl [wrote](https://forth-standard.org/proposals/fix-stack-comments-for-n-r-and-nr-#reply-1564) > In general, _u_ is preferable to _+n_, because _+n_ leaves it undefined what happens for negative _n_. _+n_ is the right choice in cases where system behaviour varies for negative _n_, but otherwise, we should either specify _u_ or _n_ with a specific behaviour for negative _n_. That's reasonable. Then, if the parameter is of type _+n_, it makes sense to specify for it _u_ if it's an input parameter, and _+n_ if it's an output parameter. Similarly, like we specify _x_ for an input boolean (zero or nonzero), and _flag_ for an output one. ,------------------------------------------ | 2025-10-17 15:33:28 ruv replies: | proposal - Standardize the well-known RDROP | see: https://forth-standard.org/proposals/standardize-the-well-known-rdrop#reply-1603 `------------------------------------------ > Rationale: This operation may be more efficient than `r> drop`. I use `rdrop` rather than `r> drop` not for the efficiency of the generated code, but for better readability. The phrase `r> drop` contains **two** words and is perceived as two actions (i.e., an additional function composition), but `rdrop` is a single action. For the same reason I use `tuck` rather than `swap over`. `r>drop` seems inconsistent with the family of words: `drop`, `fdrop`, `cs-drop`.