Digest #321 2025-10-26
Contributions
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+ ; -> }TT{ 0 GT1 DROP 1+ -> 2 }T
Replies
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:
[undefined] unrot [if] [defined] -rot [if]
synonym unort -rot
[else]
: unrot rot rot ;
[then] [then]
Or simply:
[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
unrotas an alias to-rotjust 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.
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.
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.
With the recognizer proposal 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). 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.
comment - Interpretation of the top input parameter of PICK
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.
@AntonErtl wrote
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.
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.