,---------------. | Contributions | `---------------´ ,------------------------------------------ | 2026-09-01 21:49:03 NathanHesterman wrote: | proposal - Semantic Source Modes | see: https://forth-standard.org/proposals/semantic-source-modes#contribution-446 `------------------------------------------ # Author: Nathan Hesterman # Change Log: 2026-09-01 — Initial proposal. # Problem: Forth source has traditionally been treated as an undifferentiated stream of characters. The text interpreter parses that stream, normally using whitespace, and determines the meaning of the resulting tokens from dictionary contents, interpreter state, parsing words, and other context. Traditional Forth must therefore recover semantic distinctions from an otherwise untyped character stream. These distinctions include such things as: • ordinary Forth source • compile semantics • interpretation semantics • postpone semantics • definitions • data • text • comments This results in mechanisms such as parsing words, delimiters, escaping conventions, STATE, immediate words, and words such as POSTPONE. For example, text requires some delimiter: S" This is text" The delimiter consequently cannot occur freely in the payload without an escaping or doubling convention. Similarly: POSTPONE foo uses one source word to specify how another source word is to be treated. The semantic information is not attached to foo in the source; it must be established by the operation of POSTPONE. colorForth demonstrated an alternative source model in which semantic information can be part of the source representation itself. Color was one means of presenting that information to the programmer. It was not necessary to the underlying concept. There is also a broader purpose behind this proposal. Forth has continued to evolve outside the family of systems normally described as ANS Forth. Systems such as colorForth, etherForth, r3, and other descendants should be regarded as experiments in Forth language design, not merely as incompatible dialects outside the scope of standardization. The continued existence of such systems gives the Forth community something valuable: decades of experience with alternative solutions to problems that traditional Forth solves differently. A future Forth standard should consider that experience. This does not mean incorporating another Forth wholesale, nor does it mean abandoning compatibility with existing standard programs. Instead, later Forths should be examined for abstractions that have proven simpler or more expressive than mechanisms inherited by standard Forth. Where such an abstraction can coexist with existing Forth, the standard should consider providing a path toward it. Semantic source is one example. Traditional Forth reconstructs much of a program's intended meaning from an undifferentiated character stream. colorForth demonstrated that some of this information can instead accompany the source. etherForth retained the principle using a different encoding, and r3 demonstrates another way of expressing semantic distinctions in source. The particular representation is less important than the common lesson. Backward compatibility and evolution need not be opposing goals. An existing Forth source file containing no semantic information can continue to mean exactly what it means today. New source can make use of richer semantics when an implementation supports them. Over time, experience can determine whether those semantics provide better abstractions for facilities presently expressed through parsing words, delimiters, compiler state, or other mechanisms. The standard need not freeze Forth at any particular historical implementation model in order to preserve programs written to that model. A standard can preserve the past while still providing a path toward a smaller, simpler Forth. # Solution: Provide a minimal, backward-compatible mechanism by which Forth source can carry semantic information explicitly. A NUL byte (00) in the source indicates that the following byte identifies a semantic source mode: 00 The selected semantic mode persists until another semantic mode is encountered. All source containing no semantic mode markers remains conventional Forth source and is processed exactly as before. The intent is not to standardize colors, an editor, or a particular source-code presentation. It is to standardize a means by which source can say what subsequent source means. For example, instead of requiring a textual delimiter: S" This is text" semantic source could express: This is arbitrary text containing " ; or any other Forth characters There is no textual terminator to escape. The change of semantic mode terminates the text. Similarly: POSTPONE foo could conceptually be represented by selecting postpone semantics and supplying foo. The semantic information belongs to the source item rather than being supplied by another word that parses it. The semantic mode persists until another mode marker occurs. It is therefore unnecessary to attach a tag to every word or character. This retains the compactness that motivated tagged source systems such as colorForth while allowing conventional source and semantic source to coexist. # Backward compatibility Backward compatibility is a primary objective. Existing Forth source contains no semantic mode markers and requires no modification. A semantic-source-aware system encountering no NUL bytes behaves as an ordinary Forth system. Thus semantic source is an extension of the existing source model rather than a replacement for traditional Forth source. UTF-8 is also unaffected because NUL does not occur as part of the UTF-8 representation of any character other than U+0000 itself. If literal NUL is required in semantic payload, a semantic mode or escape convention can be defined for that purpose. Presentation is not semantics This proposal deliberately does not specify how semantic modes are displayed or entered. An editor might represent semantic modes using color, bold, italic, underline, strike-through, font differences, textual prefixes, symbols, auditory cues, or any other suitable presentation. A programmer unable to distinguish colors must not lose semantic information. Likewise, an editor might assign function keys or other input methods to semantic modes. These are editor concerns and should not be part of the language standard. The source contains the semantic identifier. Its presentation is implementation-defined. # Relationship to colorForth and etherForth colorForth and later etherForth provide prior art for semantically tagged Forth source. The important idea being adopted here is not literal color. It is that source elements can carry semantic information which would otherwise have to be reconstructed by the interpreter. This proposal attempts to separate that abstraction from the particular editors, visual representations, character encodings, and hardware environments in which those systems implemented it. # Relationship to Recognizers Recognizer proposals improve the ability of a Forth system to determine the semantics of parsed input. Semantic source addresses an earlier stage of the problem. A recognizer begins with source text and attempts to determine what it means. Semantic source permits the producer of the source to state what it means. These mechanisms need not conflict. Traditional source can continue to be parsed and recognized in the usual manner, while semantic source can supply information directly. This suggests a possible longer-term abstraction in which conventional text parsing, recognizers, colorForth-like source, and other source representations all produce semantic source items for the interpreter/compiler. # Initial semantic modes This proposal does not attempt to assign a final set of standardized semantic mode numbers. That should follow agreement on the source mechanism itself. Candidate modes include: ordinary interpret compile postpone text comment define data Experience with colorForth, etherForth, r3, and existing standard Forth should be examined before selecting the smallest useful standardized set. Implementations should also have room for implementation-defined modes. # Questions remaining for discussion include: 1 Is a persistent semantic source mode an appropriate abstraction, or should semantic tags apply to individual source items? 2 Is NUL followed by a mode byte an appropriate backward-compatible encoding? 3 Which semantic distinctions should initially be standardized? 4 Should ordinary mode explicitly invoke the existing standard text interpreter? 5 How should literal NUL be represented when required? 6 Can the existing recognizer work provide the interpreter/compiler interface to which semantic source modes are ultimately translated? 7 Should the standard define semantic source independently of its serialized representation, with NUL mode being only one standard interchange encoding? # Typical use: (Optional) A conventional Forth source file remains unchanged: : foo 1 2 + ; A semantic-source-aware system processes this exactly as existing Forth source because no semantic mode markers occur. A source stream can enter a semantic mode by including: NUL and remains in that mode until another: NUL is encountered. Conceptually, a mixture of conventional and semantic source might be: ordinary Forth source NUL arbitrary text including " ; and other Forth characters NUL ordinary Forth source The visual representation of and is not prescribed. An editor may represent them as colors, font attributes, symbols, or other cues. The stored semantic information, rather than its presentation, determines the meaning. # Proposal: Add the concept of a semantic source mode to Forth source processing. 1 A NUL byte encountered in semantic-source-aware input indicates that the following byte is a semantic source-mode identifier. 2 A semantic source mode remains in effect until another semantic source-mode identifier is encountered. 3 Source containing no semantic source-mode identifiers retains existing Forth source semantics. 4 The visual, textual, auditory, or other presentation of semantic source modes is implementation-defined and has no effect on program semantics. 5 The initial standardized set and numerical assignment of semantic modes remain to be determined. Candidate modes include ordinary, interpret, compile, postpone, text, comment, define, and data. 6 Implementations may provide implementation-defined semantic modes in addition to standardized modes. 7 A means shall be provided to represent a literal NUL when required within semantic payload. The proposed mechanism can therefore be summarized as: NUL which changes the semantic interpretation of subsequent source. Without this sequence, Forth source behaves exactly as it does today. The proposal does not standardize color. It proposes standardizing the idea demonstrated by colorForth: semantics can be part of the source. # Reference implementation: No reference implementation is provided at this stage. Implementation requires access to the mechanism by which an implementation obtains and interprets source input. This mechanism is system-dependent in existing Forth systems. A reference implementation should be developed after the semantic-source interface and initial semantic modes have been agreed upon. A prototype implementation should demonstrate at minimum: • conventional Forth source executing without modification; • recognition of NUL ; • persistent switching between ordinary and semantic source modes; • semantic text containing characters that would otherwise serve as delimiters; • restoration of ordinary Forth source processing; • at least one semantic mode affecting interpretation or compilation semantics. Such an implementation would also provide experience for determining whether the proposed encoding belongs in the standard itself or should instead be one serialization of a more abstract semantic-source interface. # Testing: (Optional) Tests should establish that: 1 Existing Forth source containing no NUL bytes retains its existing behavior. 2 A NUL followed by a valid semantic mode changes the current semantic source mode. 3 The selected semantic mode persists across subsequent source until another mode marker is encountered. 4 Returning to ordinary mode restores conventional Forth source processing. 5 Text or other payload may contain characters normally used as Forth delimiters without those characters terminating the semantic region. 6 UTF-8 input is not confused with semantic mode markers. 7 The defined literal-NUL mechanism permits U+0000 or a NUL payload byte to be represented when required. 8 Invalid or unsupported semantic mode identifiers produce defined implementation behavior. Detailed Appendix F test cases should be supplied after the standardized semantic modes and their required behavior have been determined. ,---------. | Replies | `---------´ ,------------------------------------------ | 2026-08-17 12:18:38 AntonErtl replies: | requestClarification - Revise the Two's Complement Wrap-Around Integers | see: https://forth-standard.org/standard/usage#reply-1715 `------------------------------------------ About 1: Good catch, but Peter Knaggs probably caught it when he put the proposal in the document. About 2: True is defined as all-bits-set, and in twos-complement representation, the representation of -1 is all-bits-set. Concerning subtype relationships, I don't think that what's given in the standard is usable for type checking existing, working code. Forth programmers have made use of their knowledge of the representation of types since the beginning, this knowledge holds true in pretty much every Forth system (particularly systems that aspire to conforming to the standard), and if the standard is interpreted as disallowing making use of such knowledge, that would be contrary to common practice. And in the case of flags in particular, the change from the Forth-79 representation of true (1) to the Forth-83 one (all-bits-set/-1) has been done with the intention of using the flag as mask. There were no Forth type checkers around when Forth-94 or its predecessors were created, so anything related to types in the standard has not been designed for such use (certainly not with any practical experience), and if `< negate` or `< -` work as intended, but do not typecheck, that's a deficiency of the type checker, possibly the type checking rules. Concerning meta-information, I would manage that in a way that is invisible to the non-meta parts of the cells. And in that case, again, if you have all-bits-set in the non-meta part of the cell, that can be used as a mask, as a flag, or as a number. E.g., you would not want `INVERT to invert all meta-information bits of the cell, or for `negate` to two's-complement all of them. ,------------------------------------------ | 2026-08-17 14:08:55 ruv replies: | requestClarification - Revise the Two's Complement Wrap-Around Integers | see: https://forth-standard.org/standard/usage#reply-1716 `------------------------------------------ > True is defined as all-bits-set, All bits **in a cell**, as [3.1.3.1 states](https://forth-standard.org/standard/usage#subsubsection.3.1.3.1:~:text=a%20single%2Dcell%20value%20with%20all%20bits%20set). > in twos-complement representation, the representation of -1 is all-bits-set. All all bits designated for representing signed integers (**not necessary all bits in a cell**). That's why `t{ -1 -> true }t` is not guaranteed by the proposal. Forth-2012 requires only the minimal range. See [3.1.3.2 Integers](https://forth-standard.org/standard/usage#subsubsection.3.1.3.2), [3.1.4.1 Double-cell integers](https://forth-standard.org/standard/usage#subsubsection.3.1.4.1), and [A.3.2.1 Numbers](https://forth-standard.org/standard/rationale#subsubsection.A.3.2.1:~:text=nor%20to%20set%20the%20range%20of%20unsigned%20numbers%20to%20the%20full%20size%20of%20a%20cell.). To require that the representations of `-1` and `true` is the same, we could specify the minimal number of bits in a cell separately, and express the exact range of integer numbers through the number of bits in a cell. To allow flags in arithmetic operands, we have to specify subtyping: - `flag ⇒ n`; > Concerning subtype relationships, I don't think that what's given in the standard is usable for type checking existing, working code. I believe it is usable for type checking standard programs, but some rules from the prose should be expressed formally. Also, a few issues should be fixed. NB: type checking can be complete but unsound. Could you provide a standard program example where subtype relationships are not usable for type checking? ,------------------------------------------ | 2026-08-17 19:10:59 ruv replies: | proposal - Exclude zero from the data types that are identifiers | see: https://forth-standard.org/proposals/exclude-zero-from-the-data-types-that-are-identifiers#reply-1717 `------------------------------------------ I now see some problems with my proposal (and am going to update it). ### 1. Type difference operation is unsuitable We would like to reduce the set of allowed *representations* for values of certain data types, such as `xt`, `nt`, `wid`, `fileid`. But the type difference operation `\` **is not suitable** for that. The reason is that the type difference operation excludes *values*, not *representations*. Note that data types can be formally *disjoint* even if their values share the same set of representations. The same representation denotes the same value only relative to the same data type. To solve this problem, we could use something like *representation-aware relative complement* operation "`\ₚ`" instead of the simple type difference "`\`". Then, we could write: `nt ⇒ x\ₚ0` or `nt ⇒ x\ₚflag`. ### 2. Address arithmetic may produce 0 We would like to prohibit the use of `0` as a valid address. However, excluding the `0` value from the `addr` data type complicates the specification of address arithmetic. - For example, the stack diagram `( a-addr1 -- a-addr2 )` for the word `cell+` becomes incorrect. To solve this problem, we could (instead of excluding `0`) specify in the prose that the system shall not identify any location in data space with address `0`. ,------------------------------------------ | 2026-08-19 14:12:10 ruv replies: | requestClarification - Revise the Two's Complement Wrap-Around Integers | see: https://forth-standard.org/standard/usage#reply-1718 `------------------------------------------ > we could specify the minimal number of bits in a cell separately By the way, [3.1.3 Single-cell types](https://forth-standard.org/standard/usage#subsection.3.1.3:~:text=contain%20at%20least%20sixteen%20bits) already separately specifies that the size of a cell shall be at least 16 bits. Concerning the ranges of integers. Note that Forth-2012 allows the range of double-cell integers to be equal to the range of single-cell integers, if the later one is [big enough](https://forth-standard.org/standard/usage#subsubsection.3.1.4.1:~:text=range%20of%20double%2Dcell%20unsigned%20integers%20shall%20include%20%7B0%20%2E%2E%2E%204294967295%7D%2E). For example, when the ranges of single-cell integers are {-2147483647 ... +2147483647} (singed) and {0 ... 4294967295} (unsigned), Forth-2012 allows to implement double-cell arithmetic as simple as: ```forth : d+ ( d d -- d ) drop nip + s>d ; : d- ( d d -- d ) drop nip - s>d ; ``` Does the proposal prohibit such implementations? ----- Concerning meta-information. Obviously, an implementation can designate some bits (or bytes) for meta-information in `xt`, `wid`, and other opaque data types. However, I still don't see why an implementation cannot use some bits for meta-information in `u`, `n`, and `addr` data types. Another example is to provide the [carry bit](https://en.wikipedia.org/wiki/Carry_flag) in outputs of arithmetic operations (and ignore this bit in inputs). The `invert` word produces a value of the data type `x`, and this value cannot be used as an input to a word expecting a value of the data type `u`, `n`, or `addr`. That is, if the user applies `invert` to an integer number, the meta-information bits will be inverted, and it's up to the user. The `negate` word must aware of the meta-information bits (if any) and process them correctly. Note that in a Forth-2012 Program (without environmental dependencies), a flag, as well as an arbitrary tuple of bits in a cell, cannot be used as an integer number. ,------------------------------------------ | 2026-08-21 10:36:14 ruv replies: | comment - Tail call elimination | see: https://forth-standard.org/standard/core/RECURSE#reply-1719 `------------------------------------------ @AntonErtl [wrote](https://forth-standard.org/standard/core/RECURSE#reply-979:~:text=you%20can%20still%20implement%20a%20Forth%20interpreter%20in%20asm%2Ejs%20and%20such%20an%20interpreter%20can%20support%20tail%2Dcall%20elimination): > you can still implement a Forth interpreter in asm.js and such an interpreter can support tail-call elimination. Yes, it is possible in direct or indirect threaded code (i.e., when using an address interpreter), but not in subroutine threaded code. In some cases it is possible to convert `recurse exit` to jump/loop, but I'm not sure it is always possible/feasible for an indirectly recursive tail call. Providing a separate word that generates jump to the start of the word makes this feature testable. > If you have a particular asm.js-based implementation in mind, please provide a pointer. For example, see [WAForth](https://github.com/remko/waforth), which is based on WebAssembly. Its documentation [says](https://mko.re/blog/waforth/#the-interpreter:~:text=each%20word%20is%20implemented%20as%20a%20single%20WebAssembly%20function%2C%20and%20the%20system%20uses%20calls%20and%20indirect%20calls%20%28see%20below%29%20to%20execute%20words): - > WAForth uses subroutine threading, where each word is implemented as a single WebAssembly function, and the system uses calls and indirect calls (see below) to execute words. ,------------------------------------------ | 2026-08-23 03:11:16 FrancoisLaagel replies: | comment - Tail call elimination | see: https://forth-standard.org/standard/core/RECURSE#reply-1720 `------------------------------------------ Anton is right, of course. In an STC implementation--I prefer to call it 'native'--tail call elimination can be smart. Maybe too smart. In Z79Forth/A, I get: : truc recurse exit ; ok see truc 19D2 7E19D2 jmp TRUC ok And the beast conforms to the standard in every measurable way. Which can be absolutely annoying when it comes to observability concerns. A few days ago, I had to bypass my only optimization (tail call removal) in order to make reference to 'CATCH' visible and, when you operate with only 8 KB of EEPROM, that comes at a very sizeable price... ,------------------------------------------ | 2026-08-23 10:47:44 ruv replies: | comment - Tail call elimination | see: https://forth-standard.org/standard/core/RECURSE#reply-1721 `------------------------------------------ Note: "[_tail call_](https://en.wikipedia.org/wiki/Tail_call)" is *any* call before exit. `recurse exit` is a special case of a tail call, which is a directly recursive tail call. > Which can be absolutely annoying when it comes to observability concerns. The requirement to eliminate tail call (or only directly recursive tail call) could be too restrictive for implementations, and it is not backward compatible (i.e., the old systems become non-standard). However, the introduction of a new control-flow word is backward compatible, and its presence is easy to verify (for a program). ,------------------------------------------ | 2026-09-02 08:43:24 PeterFalth replies: | proposal - Recognizer committee proposal 2025-09-11 | see: https://forth-standard.org/proposals/recognizer-committee-proposal-2025-09-11#reply-1722 `------------------------------------------ At the beginning of this year I took my implementation of recognizers in **ntf64/lxf64** from an addon to be completely integrated and the only system for recognizing words, numbers and other things. I want to share my experiences. Name recognizing has become very efficient and it is possible in a standard way to add new recognizers. ORDER has been updated to also list recognizers ``` order Order: $00A0´0328 1´021 Forth $00A0´0348 5 Root Current: $00A0´0328 1´021 Forth Loaded recognizers: $00A0´1B30 Locals-recognizer $00A0´07D0 Name-recognizer $00A0´07A8 Number-recognizer $00A0´1F80 Float-recognizer $00A0´2000 String-recognizer $00A0´1BB8 Tick-recognizer $00A0´1B90 To>-recognizer $00A0´1C28 Only-recognizer $00A0´0788 Abort not found ok ``` As locals has nothing in common with names in my system it gets its own recognizer. Locals cannot be postponed in my implementation. The only-recognizer will recognize one word, ONLY, it will do its standard function and also set the locals, name and number recognizers at the top. The abort recognizer will always be found last, always succeed and perform -13 throw when executed. The number, float, string, tick, to recognizers do just what you expect. The interesting one is **rec-name**. I put a link to the translate-xxx in every word header. Now a every word knows how to compile and postpone itself! I use 3 "standard" translate records. - translate-name - translate-name-immediate - translate-name-macro From when a word is found, by rec-name, there are no more conditionals until it is executed, compiled or postponed. Not even state is tested, it is used as an index. In the system there are 65 immediate, 893 macros and 823 normal words. Linking the header to the translate record also opened up a possibility to correctly handle "state smart" words. Take S" as an example. ``` : [S"] 34 parse slit ; immediate ' ht-execute :noname drop postpone [S"] ; :noname drop [n'] [S"] lit, postpone ht-execute ; create translate-s" , , , : S" 34 parse dup >r pocket dup >r swap move r> r> ; translate-s" set-translator ``` *ht is the nt in my system, [n'] gets the nt.* I have introduced **set-translator** that takes a translate-xxx and sets it as the default translator for the last defined word. I have also introduced **recognizer:** used like ``` ' rec-local recognizer: Locals-recognizer ``` This serves 3 purposes: - It gives the recognizer a name - It inserts the recognizer in the recognizer order just after the number recognizer - Executed it moves the recognizer to be the first ONLY for example is defied as ``` : ONLY ( -- )     1 #order ! root-wordlist context !     number-recognizer name-recognizer locals-recognizer ; ``` In my system recognizers are kept in a linked list. **rec-forth** is implemented, but not as a deferred word. Interpret instead is a deferred word in my system. I think that is a better level to have the possibility to change recognizing. I have not implemented get-recs, set-recs, rec-sequence as they are not needed in my system. I have now an efficient interpreter that in a standard way can be extended! I have looked at recognizers from other systems to understand if they are useful for me. Unfortunately none will compile without modifications. Not because the recognizer systems are different but because they all use words specific to its original system. That includes my own recognizers also. ,------------------------------------------ | 2026-09-02 14:34:44 PeterKnaggs replies: | proposal - Relax documentation requirements of Ambiguous Conditions | see: https://forth-standard.org/proposals/relax-documentation-requirements-of-ambiguous-conditions#reply-1723 `------------------------------------------ If a system is claiming to be standard it *MUST* document where it differs from the standard, where the standard allows such deviation. ,------------------------------------------ | 2026-09-02 14:48:17 PeterKnaggs replies: | proposal - Recognizer committee proposal 2025-09-11 | see: https://forth-standard.org/proposals/recognizer-committee-proposal-2025-09-11#reply-1724 `------------------------------------------ ,------------------------------------------ | 2026-09-02 14:49:26 FrancoisLaagel replies: | proposal - Recognizer committee proposal 2025-09-11 | see: https://forth-standard.org/proposals/recognizer-committee-proposal-2025-09-11#reply-1725 `------------------------------------------ ,------------------------------------------ | 2026-07-14 15:31:42 ruv replies: | proposal - Recognizer committee proposal 2025-09-11 | see: https://forth-standard.org/proposals/recognizer-committee-proposal-2025-09-11#reply-1726 `------------------------------------------ Anton [wrote](https://forth-standard.org/proposals/recognizer-committee-proposal-2025-09-11?hideDiff#reply-1685) on 2026-07-05: > The details of the translations produced by `rec-name` and `rec-float` are specified in prose. I don't see it in the prose. For `rec-name` the prose says (a fragment): - `rec-name ( c-addr u -- translation )` If _c-addr u_ is the name of a visible named word, _translation_ represents the text-interpretation semantics (interpreting, compiling, postponing) of that word, and has the translation token _translate-name_. From this specification, even the size of the output data object on the stack remains unclear. > If you prefer to put these details in the stack comment, for `rec-name` that would be > `rec-name ( c-addr u -- local-sys translate-local | nt translate-name | translate-none )` This is better, but then `translate-name` (and others) should be specified as a data type symbol. ,------------------------------------------ | 2026-07-15 05:32:41 AntonErtl replies: | proposal - Recognizer committee proposal 2025-09-11 | see: https://forth-standard.org/proposals/recognizer-committee-proposal-2025-09-11#reply-1727 `------------------------------------------ Taking your example fragment, the stack effect says that the result is a translation, and the prose says that its translation token is `translate-name`. And if you look at the specification of `translate-name`, its prose says: > Stack effect to produce a translation: ( nt -- translation ) And the stack effect of `translate-name` is ( -- translate-name ). This means that a translation with the translation token translate-name consists of the stack items ( nt translate-name ). ,------------------------------------------ | 2026-07-16 11:52:07 ruv replies: | proposal - Recognizer committee proposal 2025-09-11 | see: https://forth-standard.org/proposals/recognizer-committee-proposal-2025-09-11#reply-1728 `------------------------------------------ > This means that a translation with the translation token translate-name consists of the stack items `( nt translate-name )`. Agreed. But it's too obscure and unclear. "translation [...] has the translation token translate-name" — "translate-name" is not a translation token, but a word that returns a translation token. Then, looking at the `translate-name` semantic description, the phrase "stack effect to produce a translation" does not seem like a normative text, too. One way to make this more clear and normative is to use _intersection_ of arrow types (stack effects). If we use the symbol «`^^`» to denote the intersection operator on arrow types: - `translate-name` Execution: `( -- translation-token ^^ nt -- translation )` Thus, it is possible to do without introducing **subtypes** of _translation-token_, but these subtypes are needed in practice (in stack diagrams of real programs), and they make things more clear. The symbols for these subtypes can be derived from the symbol "translation-token", e.g. "translation-token-nt", "translation-token-cell", "translation-token-float", but that's too long. I would suggest to use a short prefix, e.g. "tt-" or "td-" for these data type symbols. ,------------------------------------------ | 2026-09-02 15:50:49 BerndPaysan replies: | proposal - Recognizer committee proposal 2025-09-11 | see: https://forth-standard.org/proposals/recognizer-committee-proposal-2025-09-11#reply-1730 `------------------------------------------ Gforth has been implementing draft variants of this proposal since the very beginning, and the current snapshots already implements this proposal, which will become Gforth 1.0 very soon. ,------------------------------------------ | 2026-09-02 16:11:43 LeonWagner replies: | proposal - Standardize the well-known BOUNDS | see: https://forth-standard.org/proposals/standardize-the-well-known-bounds#reply-1731 `------------------------------------------ Alternative stack comment: `( addr1 n -- addr2 addr1 )` The second input input argument should not be restricted to unsigned values unless you really want to exclude the use of `+LOOP`. ,------------------------------------------ | 2026-09-02 16:37:04 GeraldWodni replies: | proposal - Test Proposal | see: https://forth-standard.org/proposals/test-proposal#reply-1732 `------------------------------------------ Test of system version ,------------------------------------------ | 2026-09-02 20:40:25 GeraldWodni replies: | proposal - Test | see: https://forth-standard.org/proposals/test#reply-1733 `------------------------------------------ Test-Accept, can we still vote afterwards? We would like to!