,---------------. | Contributions | `---------------´ ,------------------------------------------ | 2026-07-20 14:28:21 AbstractionFirst wrote: | comment - Should the standard distinguish application interfaces from implementation interfaces? | see: https://forth-standard.org/standard/core/toIN#contribution-439 `------------------------------------------ The Forth standard currently conflates two distinct kinds of interfaces: those intended for portable application programs and those intended primarily for implementing Forth systems. This distinction is important because these two categories serve different purposes. **Application interfaces express the semantics of portable Forth programs. Implementation interfaces expose or manipulate the internal operation of a Forth system.** Examples of the latter include words such as `>IN`, `SOURCE`, `REFILL`, and `SAVE-INPUT`. Such words are essential for implementing a Forth system, but they do not define the semantics of portable Forth programs. Would it be beneficial for future revisions of the standard to distinguish these interfaces explicitly, perhaps by introducing a separate word set dedicated to implementation support (e.g. `INTERPRETER`, `IMPLEMENTATION`, `SYSTEM`, or `ENGINE`)? Such a distinction would strengthen the separation between language semantics and implementation mechanisms while preserving implementation freedom. ,---------. | Replies | `---------´ ,------------------------------------------ | 2026-07-20 08:26:37 ruv replies: | comment - BASE exposes representation rather than abstraction | see: https://forth-standard.org/standard/core/BASE#reply-1690 `------------------------------------------ The word `TO` has a number of disadvantages, and many in the Forth community avoid using it. In Forth-2012, separate getters and setters are used. For example, [`precision`](https://forth-standard.org/standard/float/PRECISION) and [`set-precision`](https://forth-standard.org/standard/float/SET-PRECISION). As a replacement to the word `base` I would prefer the following interface: - `radix` Execution: `( -- +n )` - `+n` is the current radix (base) of number conversion. - `set-radix` Execution: `( u|n -- )` - if `u|n` is not in the range {2..36}, an exception is thrown (or at least may be thrown). Note that with `to` it could be difficult to check the input value and throw an exception. ,------------------------------------------ | 2026-07-20 08:48:01 AntonErtl replies: | comment - A language standard should specify abstractions rather than mechanisms | see: https://forth-standard.org/standard/core/SAVE-INPUT#reply-1691 `------------------------------------------ > Can a portable application express a requirement that naturally maps to SAVE-INPUT? Given the lack of guarantees in `restore-input`, probably not. If `restore-input` was specified more tightly, yes. The usage would be a multi-line variant of what `>in` is used for (judging from the rationale). My impression is that nobody uses `save-input` and `restore-input` in code that is intended to be portable, though. And while there are occasional questions about what these words are good for, nobody has actually pushed for a tightening of the specification. My guess is that if these words are removed from the standard, no one who intends to write a standard program will miss them. > If these words are intended primarily for implementors of Forth systems rather than for portable application programs Reading the rationale, the intention was to provide a feature for portable application programs. My dim memory of some of the discussions about these words is that some people have pointed out that some systems use them to implement some other words, such as IIRC `included`. These words do not expose implementation mechanisms. I can think of many implementation approaches that support useful implementations of these words, and none that are incompatible with useful implementations of these words. And useless implementations do not care about the implementation of the input stream at all. ,------------------------------------------ | 2026-07-20 09:07:34 AntonErtl replies: | comment - BASE exposes representation rather than abstraction | see: https://forth-standard.org/standard/core/BASE#reply-1692 `------------------------------------------ If `base` had been specified as a `value` (or with getter and setter) in the infancy of Forth, that would have some benefits today. However, it actually has been specified as (user) variable, and we now have established practice in both systems that implement `base` and programs that use `base`, so we cannot change `base` into a value. One possible route around that would be to propose an alternative word (or words) with the preferred interface for standardization, get that standardized, then make `base` obsolescent, and many years later destandardize `base`. However, no alternative has any established (much less common) practice. And arguments about things like "exposes implementation mechanisms" are generally used (often incorrectly) when arguing against proposals, but I don't remember any proposal that was based solely on this argument that has been successful. ,------------------------------------------ | 2026-07-20 13:31:28 Klaus_Schleisiek replies: | comment - SAVE-INPUT | see: https://forth-standard.org/proposals/obsolescence-for-save-input-and-restore-input#reply-1693 `------------------------------------------ I needed save-input and restore-input in order to do lazy compilation in my uCore cross-compiler. The rational was minimizing the code size of applications in a one-pass compilation process. This is what I did: I restructured often used words in "libraries" that were derived from load files of these words. The application would only need a few of them. Therefore it would have been a waste of code memory space to always compile all of them. The library consisted of the original load file, which I sliced up in "sibling groups" using ~ in front of each group, which consisted of just one definition in most cases. This embellished file could be loaded as usual using INCLUDE, because then ~ would be an immediate no-op. It could also be loaded using LIBRARY instead. In that case ~ would compile the following sibling group as a - lets call it - library word. Library words are immediate and the parameter list consists of the file and the position of the source code of that group. When compiling the application, every now and then such a library word would be found and executed in the middle of compiling some application word. This triggers a sequence of events: 1) Delete the unfinished :-definition that requires the library word. 2) Use save-input to remember the file and location of the aborted definition. 3) Change the input stream to point to the file and location in the library file. 4) Compile from the library file until the next ~ 5) Use restore-input to get back to where we interrupted comiling the application. 6) Continue compiling the application. This code can be written in such a way that it works recursively, i.e. a library word may need another library word potentially from a different library etc. This way the uCore cross-compiler produces optimal code in one pass. I venture to say that save-input / restore-input is a very valuable application word. If it would have been not there, my code would have to be much more system dependent, fiddeling with the internals of e.g. Gforth with all the headaches this creates when its internal structure is silently modified by the implementors. Therefore: Don't deprecate it! Instead, define it in a strict way so that it will do the same on every system. ,------------------------------------------ | 2026-07-20 17:46:31 AbstractionFirst replies: | comment - A language standard should specify abstractions rather than mechanisms | see: https://forth-standard.org/standard/core/SAVE-INPUT#reply-1694 `------------------------------------------ I think my original point was not expressed clearly enough. My intention was not to discuss whether SAVE-INPUT is useful, whether it should be specified more tightly, or how it can be implemented. The question I was trying to raise is a different one: **Should facilities that manipulate the interpreter's own state belong to the application interface at all?** In other words, my concern is not the design of SAVE-INPUT itself, but the criteria used to decide whether such words belong in the standard programming interface for portable applications. ,------------------------------------------ | 2026-07-20 19:33:54 ruv replies: | comment - A language standard should specify abstractions rather than mechanisms | see: https://forth-standard.org/standard/core/SAVE-INPUT#reply-1695 `------------------------------------------ > Should facilities that manipulate the interpreter's own state belong to the application interface at all? Your point was that `save-input` and `restore-input` are not in the same category as `parse` and `refill`. I didn't see any criteria by which these categories are distinguished. All of these words manipulate the state of the Forth system, namely, the state of the input source (in contrast, `evaluate` does not affect the state of the input source). Changing the value at `>in` also manipulates the state of the input source, as does its potential replacement, the word `set-source-offset`. The Forth standard, at its core, defines an interface to the Forth system (an API). See [1.2 Scope](https://forth-standard.org/standard/intro#section.1.2:~:text=This%20standard%20specifies%20an%20interface%20between%20a%20Forth%20System%20and%20a%20Forth%20Program%20by%20defining%20the%20words%20provided%20by%20a%20Standard%20System%2E), which says: "This standard specifies an interface between a Forth System and a Forth Program by defining the words provided by a Standard System". It's impossible to remove all words that affect the state of the Forth system. ,------------------------------------------ | 2026-07-20 20:21:46 AbstractionFirst replies: | comment - BASE exposes representation rather than abstraction | see: https://forth-standard.org/standard/core/BASE#reply-1696 `------------------------------------------ My point is broader than `BASE` itself. The issue is the language model, not the implementation. The current interface requires programmers to access the radix through two separate operations involving an address (`BASE @`, `BASE !`). In other words, the programmer performs two operations where there is conceptually only one. Introducing a direct interface would simplify the programming model, not merely optimize an implementation. ,------------------------------------------ | 2026-07-20 21:06:52 AbstractionFirst replies: | comment - A language standard should specify abstractions rather than mechanisms | see: https://forth-standard.org/standard/core/SAVE-INPUT#reply-1697 `------------------------------------------ The distinction I am proposing is not based on whether a word manipulates the state of the Forth system. It is about the language model. The current standard mixes together words that are primarily needed by Forth implementors with words that are intended for general application programming. My point is about the architecture of the language as a whole rather than the implementation of individual words. ,------------------------------------------ | 2026-07-20 22:56:31 ruv replies: | comment - A language standard should specify abstractions rather than mechanisms | see: https://forth-standard.org/standard/core/SAVE-INPUT#reply-1698 `------------------------------------------ > My point is about the architecture of the language as a whole rather than the implementation of individual words. You should probably present your ideas as a [new proposal](https://forth-standard.org/profile/proposals/add) with specific changes, rather than as comments on individual words.