,---------------. | Contributions | `---------------´ ,------------------------------------------ | 2026-07-24 12:57:22 FrancoisLaagel wrote: | requestClarification - BYE Semantics Needs Clarification | see: https://forth-standard.org/standard/tools/BYE#contribution-440 `------------------------------------------ BYE is used by QUIT's reference implementation. The specification I can see on forth-standard.org says "return control to the host operating system, if any." Under the latest SwiftForth implementation (x64-Linux 4.1.8), there is an operating system but upon a QUIT, control is simply returned to the interpreter. GForth 0.7.9 behaves in the same manner. So, as usual, we can fix the specification to match "common usage" or fix the implementations to match the specification. In Z79Forth, 'BYE' causes a system reboot, which renders all the debate about what 'QUIT' should or should not do, rather academic. ,---------. | Replies | `---------´ ,------------------------------------------ | 2026-07-21 07:07:16 AntonErtl replies: | comment - BASE exposes representation rather than abstraction | see: https://forth-standard.org/standard/core/BASE#reply-1699 `------------------------------------------ When designing a new language, such things should be taken into consideration. And in a new language, I would avoid global/user state like `base` if possible, no matter how the state is accessed and changed. But Forth is not a new language, and in its standardization important guidelines are existing practice and common practice. That is even more important for cases where existing words are to be removed or replaced. `base` is common practice. If you want to replace it, you have to convince many Forth programmers to use your alternative, and many Forth system implementors to implement it, and once that has happened, the alternative can be standardized. You will need to convince all Forth programmers to stop using `base` and to rewrite existing code to use your alternative in order to destandardize `base`. An example of that is `locals|` and `{:`. `{`, an alternative to `locals|` had common practice; John Hayes published an implementation in Forth-94 in SigForth, but Stephen Pelc keeps pointing out that MPE implemented it earlier; several other Forth systems implemented `{` and code that I saw posted used `{` more frequently than `locals|`. Based on the common practice `{` was standardized under the name `{:` in Forth-2012 (the name change happened due to a different existing practice of `{` in SwiftForth). Nobody has proposed destandardizing `locals|` yet (but then, if a system does not want to implement it, it can, because it's an extension word; but I am not aware of a system that implements `{:` but not `locals|`). ,------------------------------------------ | 2026-07-21 07:45:49 AntonErtl replies: | comment - Should the standard distinguish application interfaces from implementation interfaces? | see: https://forth-standard.org/standard/core/toIN#reply-1700 `------------------------------------------ All the words you list have been standardized only for application use. That is most obvious for `source`, `refill` and `save-input`, which were introduced in Forth-94 to provide an abstraction from the different mechanisms is for input from the terminal, from blocks, files, and `evaluate`d strings. Forth systems don't need these words internally, and they certainly don't need their standardization for their internal uses. `>in` has a longer legacy and one can consider it as exposing a system-implementation word of early Forth systems. However, the fact that it is standardized is not for the benefit of systems, but for the benefit of programs. As system implementor I disliked the need to keep `>in` up-to-date, and to start the next parse from `>in`. Is it the ideal interface? Probably not, but it is common practice. Given that these words have not been standardized for internal system usage, a distinction like you suggest makes no sense. The standard has the Programming-Tools wordset, which collects a variety of words that some might consider to be outside the scope of application programming. The criteria for inclusion in the Programming-Tools wordset are unclear, probably even to the members of the committees who made these decisions; one idea might be that if the feature is not in a language like Pascal, then it's a programming tool (note that already C has conditional compilation, which is in Programming Tools). Interestingly, none of the words you mention are in the Programming Tools wordset, so apparently the Forth-94 committee thought that they (especially `>in` and `source`, which are in the Core wordset) are more widely useful. ,------------------------------------------ | 2026-07-21 08:00:42 AntonErtl replies: | comment - A language standard should specify abstractions rather than mechanisms | see: https://forth-standard.org/standard/core/SAVE-INPUT#reply-1701 `------------------------------------------ > Should facilities that manipulate the interpreter's own state belong to the application interface at all? I generally recommend to not write parsing words, but writing them is common practice, and until we have made the alternatives (such as recognizers or passing strings) compelling enough that people rewrite their code in terms of the alternatives, there is common practice, and the standard should include words for writing them. > The current standard mixes together words that are primarily needed by Forth implementors with words that are intended for general application programming. There is no need to standardize words that are not useful outside the Forth system, and AFAICS, no such words have been standardized, certainly not those that you mentioned in your recent comments. These words are all intended for portable Forth programs; some people may consider not all of these programs to be "general application programs", but it's unclear what the criteria would be for this distinction. ,------------------------------------------ | 2026-07-21 08:09:48 ruv replies: | comment - Should the standard distinguish application interfaces from implementation interfaces? | see: https://forth-standard.org/standard/core/toIN#reply-1702 `------------------------------------------ @AbstractionFirst, your comment is completely irrelevant to the glossary entry `>IN`. It should have been posted elsewhere. > Would it be beneficial for future revisions of the standard to distinguish these interfaces explicitly, perhaps by introducing a separate word set Moving glossary entries from one section (word set) to another is possible in principle, but it has its drawbacks and does not offer significant benefits. A simpler approach is to add tags to glossary entries indicating which groups the word belong to. In any case, this should be discussed in a separate proposal. So, I close this comment. ,------------------------------------------ | 2026-07-21 09:04:07 pda replies: | comment - A language standard should specify abstractions rather than mechanisms | see: https://forth-standard.org/standard/core/SAVE-INPUT#reply-1703 `------------------------------------------ About the question in the title " A language standard should specify abstractions rather than mechanisms" , even when I agree with the sentence a fundamental question arise in my brain: is this sentence compatible with the philosophy of Forth itself? as far as I know Forth has always been a language that do not hide implementation to the user and developer, it focuses in simplicity and hardware aware design , so I feel walking the path of abstraction is walking the opposite way of Forth pathway , even when I agree Forth classification of world into words is a powerful kind of abstraction ,------------------------------------------ | 2026-07-21 16:29:13 AntonErtl replies: | comment - A language standard should specify abstractions rather than mechanisms | see: https://forth-standard.org/standard/core/SAVE-INPUT#reply-1704 `------------------------------------------ > is this sentence compatible with the philosophy of Forth itself? That depends on what you mean with "the philosophy of Forth"? If you mean Chuck Moore's philosophy, standardization itself is not compatible with it, so he has bowed out of the standardization process many decades ago. You can examine individual ideas that have been claimed to be part of the philosophy of Forth for compatibility with this sentence, but I think that it is a better use of your time to examine how well individual words or word groups satisfy goals like ease of use, ease of implementation, efficiency, portability between hardware platforms, portability between Forth systems, etc. I think that the Forth-94 committee generally did a good job in providing abstractions that satisfy many of these goals, with some exceptions. ,------------------------------------------ | 2026-07-22 17:12:08 ruv replies: | comment - SAVE-INPUT | see: https://forth-standard.org/proposals/obsolescence-for-save-input-and-restore-input#reply-1705 `------------------------------------------ > it would have been not there, my code would have to be much more system dependent I see similar code in [library.fs](https://github.com/microCore-VHDL/microCore/blob/master/software/library.fs) and [microcross.fs](https://github.com/microCore-VHDL/microCore/blob/master/software/microcross.fs) (in [microCore-VHDL/microCore](https://github.com/microCore-VHDL/microCore) at GitHub). It seems, this program is very system-specific and is far from a standard Forth program. Given such strong dependence on the system, even using non-standard `save-input` and `restore-input` adds almost nothing to dependency on the system. Or do you think your Forth system will stop providing `save-input` and `restore-input` if they become obsolete? > 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 Got it. This does not look like one-pass compiling, as, when a word is missing, you translate the definition body again, and again for each missing word. There are a number of other approaches (without `save-input`): - Since you are using a user-defined Forth text interpreter, you can save the portion of the input source from the start of a colon-definition into a buffer and then translate this portion from the buffer. - Or, the same as for words from the library, it is possible to add markup that allows to extract the whole definition body to lately translate it from a buffer (multiple times, if needed). - Or, you can load the whole file into a buffer and apply `evaluate` (with [proper `\`](https://forth-standard.org/proposals/support-for-single-line-comments-during-evaluate-)), and change `>in` instead of using `restore-input`. - Or, it is possible to compile a definition into an intermediate code format, and when all missing words are loaded, translate the intermediate code into the target code. - Or, when a missing word from a library is encountered, instead of discarding the definition, you can save the compiled code into a buffer, load the missing word, and then perform a binary translation of the compiled portion to the new location. - Or, when a missing word from a library is encountered, you can compiler an unresolved call. After the definition is compiled, you load missing words (translate their definitions) and resolve all unresolved calls (this is also recursive). ----- > Don't deprecate it! Instead, define it in a strict way so that it will do the same on every system. Somebody should prepare a proposal. And then, if we specify these words more tightly, the system implementers should either make these words stronger, or remove them. If we deprecate them, system implementers should not do anything, and authors of standard programs should stop using these words; however, such authors already don't use them. Therefore, no one should do anything.