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.| Forth Standard
I agree, of the options considered, the best pronunciation is "unrot", and the best name, I think, is `unrot`. | Forth Standard
## Author: | Forth Standard
> there are two different implementation styles: One parses, one sets a state. | Forth Standard
I'm not exactly sure how to mention this without leaving a comment here, since it affects this definition. Draft 21.1, specifically the [PDF](http://forth200x.org/documents/forth21-1.pdf) version uploaded last month, has a formatting issue in the text of the EKEY? definition on page 102. The second line of the last sentence overflows into the footer at the bottom of the page, making the text and footer (including the page number) unreadable. | Forth Standard
No one has written down any objections to this proposal for three years. | Forth Standard
PLACE +PLACE request for discussion| forth-standard.org
( "<spaces>name" -- )| forth-standard.org
AntonErtlNew Version: Traverse-wordlist does not find unnamed/unfinished definitions| forth-standard.org
15 The optional Programming-Tools word set| forth-standard.org
Contributions by mykesx| forth-standard.org
6 Glossary| forth-standard.org
@GeraldWodni [wrote](https://forth-standard.org/proposals/non-parsing-create#contribution-413): | Forth Standard
> : rec-tick ( addr u -- translation ) \ gforth-experimental | Forth Standard
Some committee members will look at this proposal if they update their FP package. But given the lack of a champion for this proposal at the moment, the committee has decided to retire this proposal for now. If any champion steps up, move it to informal again.| Forth Standard
A better to specify what behavior xt identifies when ticking such words as `s"` or `to`.| Forth Standard
providing a reference for a CORE word that uses words from CORE-EXT may seem invalid| forth-standard.org
6.1.0460 ; semicolon CORE| forth-standard.org
AntonErtl| forth-standard.org
Each of the solutions proposed so far has relied on non-standard (but presumably obvious) words: [211] and [r722] use `u>=`, [r725] uses `not`, [r726] uses `-rot`, [r727] uses `?exit` and `umin`. I'm not sure if that means more words should be standardized, or if we just need to be more careful in writing examples.| Forth Standard
```forth | Forth Standard
Anton [wrote](https://forth-standard.org/standard/core/ZeroEqual#reply-1523): | Forth Standard
Author:| forth-standard.org
Contributions by PeterKnaggs| forth-standard.org
AntonErtl| forth-standard.org
JennyBrien| forth-standard.org
Annex A: Rationale| forth-standard.org
16 The optional Search-Order word set| forth-standard.org
Contributions by ruv| forth-standard.org
Contributions by BerndPaysan| forth-standard.org
Contributions by AntonErtl| forth-standard.org
Forth| forth-standard.org
This implementation requires SPACES to gracefully ignore negative input; although it has been questioned whether that is intended by the standard: https://forth-standard.org/standard/core/SPACES#contribution-337. Note that this implementation does not use S>D; doing so would produce the wrong results on a twos-complement machine for the minimum integer value. | Forth Standard
> I don't really see how the implementation I propose is insufficient for your system, unless 0<> does not return either 0 or -1. I see that TRUE is declared to return "a single-cell value with all bits set", so maybe that doesn't translate to -1 in your system? | Forth Standard
The standard does not state that this is an ambiguous condition for this word, but using `[UNDEFINED]` without a name is most likely a programming mistake rather than intentional, so I think that this may be something we might fix in the future if we ever get around to it.| Forth Standard
The standard clearly specifies in 3.4.1 that the parsing of `."` ends when the parse area (line or block) ends. So if that definition is on the command line or in a file, it is equivalent to | Forth Standard
The webpage for 11.6.1.2165 inlines this Rationale quote from A.11.6.1.2165 S": | Forth Standard
For implementations that do not want to support full double arithmetic, it appears that Forth-2012 permits an implementation where a double uses fewer bits than twice the number of bits in a single. That is, I argue that as long as a single has at least 32 bits (the minimum required range of a double), an implementation-defined encoding of doubles where the only valid representations of a double are ( u 0 ) and ( n.negative -1 ) is possible (even if the testsuite needs more work before passi...| Forth Standard
It would help if I didn't typo `..` where `.` was intended.| Forth Standard
> So, my request for clarification includes figuring out whether this code should become well-defined or remain ambiguous: | Forth Standard
The following uses a couple of words from the double and string sets; the alternative using only words in core is more verbose. | Forth Standard
```forth | Forth Standard
I suggest the following as a reference implementation: | Forth Standard
It would be helpful to use the proper spelling "Pronunciation" rather than "Pronounciation".| Forth Standard
> The standard allows the implementations where IMMEDIATE affects the last definition in the compilation word list. It is the only reason for the following ambiguous condition (from 16.3.3): | Forth Standard
Dear Forthers,| forth-standard.org
Register| forth-standard.org
Register| forth-standard.org
I would change the stack diagram for `of` to `( C: case-sys1 -- case-sys2 of-sys )` — this stack diagram will formally allow the system to throw an exception if _case-sys1_ is absent on the top of the control-flow stack, and it will require a program to restore _case-sys1_ if it is temporary removed (and the data stack is used for the control-flow stack items). | Forth Standard
> Or, we could go the route of documenting the use of a buffer, | Forth Standard
> What should be the behavior when `find-name` is passed a 0-length string? | Forth Standard
RDROP is not part of the standard; your reference implementation should spell it out as R> DROP.| Forth Standard
I can see that tests for 2>R were not added until version 0.10 of the testsuite (Aug 2014), which post-dates Forth-2012 and thus explains why those tests are not visible in Annex F. Had I seen that test sooner, I would have caught the bug in my initial attempted implementation. Namely: | Forth Standard
The standard is clear that although the implementation can store j\*x words for the rest of the saved portion of the data stack with no 1:1 correspondence to the original i\*x words, the return stack MUST have n as its top entry. | Forth Standard
This website currently reflects Forth-2012, and AFAIK the tests come from the Forth-2012 document (which took them out of the test suite around 2012). When we release the next standard, the document and the tests in there will be updated (hopefully in some automated way). And maybe we will do the tests on this website directly from the test suite at some point. In any case, if you want to use up-to-date tests, go to [the source](https://github.com/gerryjackson/forth2012-test-suite).| Forth Standard
The standard already includes a reference implementation for CASE OF ENDOF ENDCASE, but it it tucked away in annex A Rationale instead of the more traditional annex E used by most other reference implementations; hence it does not show up when browsing to this page online. So maybe that makes this more of a web page request than yet another reference implementation - but to make life easier for the next reader: | Forth Standard
About "encode the difference between interpretation and compilation semantics". For immediate words, there is no difference. If a Forth system supports arbitrary combinations of interpretation and compilation semantics (e.g., with Gforth's `interpet/compile:`), the same xt can represent the interpretation semantics of one word and the compilation semantics of another word. E.g.: | Forth Standard
Rationale: | Forth Standard
When `read-line` is called with u1=0 at the end of the file, flag=true according to | Forth Standard
It is possible to test AGAIN without an infinite loop if combined with the tools set AHEAD and CS-ROLL, as in: | Forth Standard
6.1.1700 IF CORE| forth-standard.org
Contributions by lmr| forth-standard.org
On a system where the data space grows dynamically, there is no inherent compile-time limit on the maximum address in data space, and there might be no easy way to probe at runtime how large of an address can be allocated without failure. In that scenario, is it better to include the word UNUSED and have it return -1 to indicate unknown (or rather, the maximum unsigned integer since the prototype uses 'u'), or to omit the word UNUSED from the core extension set? Some traditional systems had...| forth-standard.org
> which at strict reading would state that a comment cannot contain ")" | Forth Standard
Annex F: Test Suite| forth-standard.org
ContributeContributions| forth-standard.org
It's a known problem.| forth-standard.org
I also found this irritating. And at first I completely eliminated block 0 (by using an offset), but later found that having a block 0 that cannot be used for load is the traditional way, so I changed Gforth to follow that way. Blocks are a traditional thing. If using Block 0 for something else was good enough in the times of floppy disks, it should be good enough now. In any case, it seems to me that you have understood the issue, and have no need for clarification, so I am closing this ...| forth-standard.org
Maybe it was already discussed, but to me the first test should be: | Forth Standard
# Gerund | Forth Standard
[5.6.2.2534 `[UNDEFINED]`](https://forth-standard.org/standard/tools/BracketUNDEFINED) should also be updated according to the new wording in `[DEFINED]`.| Forth Standard
The initial problem in `[defined]` was fixed by the proposal [Remove the “rules of FIND”](https://forth-standard.org/proposals/remove-the-rules-of-find-?hideDiff#reply-900). Close.| Forth Standard
It is obvious that the idea behind the stack diagram of `throw` is to specify what happens on the data stack in both cases, including the case where the control flow does not continue sequentially. And I think it's a good idea to specify the stack effect for that case, and it should also be done for `?do`. | Forth Standard
> Notwithstanding that, I wouldn't standardize any octal prefix; it's a lot of potential pain for not a lot of gain. Use recognizers if that's what you need. | Forth Standard
FYI It appears that a domain name exists... | Forth Standard
I was never good at following directions. | Forth Standard
In the latest draft, there is really no difference between core `FIND` and search-order `FIND`, because the difference has been factored out into Sections 3.4.2 and 16.3.3, as well as into 2.1 and 16.2. | Forth Standard
In the 2020 meeting the committee accepted this proposal in vote #18 with 11Y:0N:1A.| Forth Standard
> Circular references in implementation examples are _**hugely confusing**_ when used before the definition exists. | Forth Standard
> There are only few cases in Gforth, where the latest nt or 0 is needed, and `REVEAL` is one of them: it only needs to do something when `LATEST` is non-zero. | Forth Standard
MSB is not -1. It's the same as MIN-INT.| Forth Standard
MSB is the value where only the most significant bit is set: | Forth Standard
For reference, I collect the cases where ambiguous condition can be eliminated in the issue "[Eliminating of some ambiguous conditions](https://github.com/ForthHub/standard-evolution/issues/2)" on ForthHub/standard-evolution.| Forth Standard
> it's unclear whether use of `LOAD` invalidates the address that was returned by `SOURCE` | Forth Standard
There is an **inconsistency** in the section [4.1.2 Ambiguous conditions](https://forth-standard.org/standard/doc#doc:ambiguous), which says: | Forth Standard
# Authors | Forth Standard
yes!| Forth Standard
This is work for the editor.| Forth Standard
On behalf of the committee: There is no common practice for arithmetic operations on several FP sizes. `F@`, `DF@`, `SF@` all put the same sized FP value on the FP stack. A proposal for multiple arithmetic sizes is unlikely to gain consensus.| Forth Standard
As discussed in [r32](https://forth-standard.org/proposals/wlscope-wordlists-switching-made-easier#reply-32), the committee has discussed this.| Forth Standard
This is just a wording change.| Forth Standard
Please advance the proposal to be more formal, along the lines of [ruv's reply](https://forth-standard.org/proposals/f-r-and-fr-to-support-dynamically-scoped-floating-point-variables#reply-1115). One thing that you should also mention is that the return stack pointer may not comply with the usual FP alignment requirements, and your words must cope with that.| Forth Standard
This is just a wording change.| Forth Standard
Ongoing discussion| Forth Standard
The author wants to incorporate the following replies: | Forth Standard
| Forth Standard
| Forth Standard
Redundant with the "Special Memory Access" word set.| Forth Standard
The feedback I got at the Forth200x meeting is to have `b@` `b>s` `b!` (with some dissenting opinions, but `c@` `c!` will still work), to change c to b in the table of conventions, to use u, not x, and to use c-addr, not addr.| Forth Standard
Currently, the standard does not support control characters (including newlines) in `evaluate`d strings, see [New Line characters in a string passed to EVALUATE](https://forth-standard.org/standard/core/EVALUATE#reply-782). So your proposal would have to change this first. We are therefore moving it to considered. One way to strengthen your proposal would be to discuss existing practice: What do systems do when newlines are passed to `evaluate`?| Forth Standard