,---------------. | Contributions | `---------------´ ,------------------------------------------ | 2026-02-28 11:03:59 EkkehardSkirl wrote: | requestClarification - 2.1. Definitions of terms: Control-, Float-, Exception-stacks and may be more | see: https://forth-standard.org/standard/notation#contribution-426 `------------------------------------------ The standard talks about control-, float-, and exception-stack too. So my proposal ist to create entries similar to the following: * **stack:**: There are six last in, first out list types possible differentiated by their use * data-stack * return-stack * float-stack * control-stack * exception-stack * source-stack The control-stack, exception-stack, and source-stack may be, but need not be, implemented using the return stack if and only if other standard token will be satisfied. The float-stack exists only if the optional Floating-Point word set is present. The exception-stack exists only if the optional Exception word set is present. * **float-stack:** A last in, first out list that shall be used by all floating-point operators. * **control-stack:** A last in, first out list that shall be used by all control flow actions. * **exception-stack:** A last in, first out list that shall be used for the nesting of exception frames. Since the sources could be nested it looks useful to me to introduce additional * **source-stack:** A last in, first out list that shall be used for the nesting of input sources. This nesting in my rememberings was discussed somewhere I don't find yet any more. ,---------. | Replies | `---------´ ,------------------------------------------ | 2026-02-25 09:17:11 ruv replies: | requestClarification - Implementation Query? | see: https://forth-standard.org/standard/core/ENVIRONMENTq#reply-1625 `------------------------------------------ > Should there be a standard environmental query that returns a string specifying which Forth implementation is present? Probably yes, similar to User-Agent string in browsers, but it should be used only for logs/messages, and never in place of **feature detection**. Therefore, to avoid misuse, a mechanism for detection features should be established first. This will allow checking specific components rather than the system name/version. The idea is that instead of `is-gforth [if] ... [else] ... [then]` we should use `"some-gforth-feature" provided [if] ... [else] ... [then]`. Note that "some-gforth-feature" can be provided by any forth system, not only by Gforth. Typically, we would like to check for a specific word (or several words), or for a specific **set of words**. But we cannot rely on word names due to potential conflicts. Therefore, we need globally unique namespace identifiers, and we must check for the presence of a word name only in a specific namespace. It is well known that URIs work well as namespace identifiers, because they are human-readable, unique, and don't need any additional central repository. So, a possible approach is as follows: ```forth begin-using-namespaces \ turn on the corresponding recognizer : sf ( -- sd.namespace ) "https://gforth.org/ns/some-feature" ; \ sf -- for "some-feature" \ check for a namespace sf namespace-available [if] ... [else] ... [then] \ make sure that the corresponding module is available sf import-module \ check for a specific word [defined] sf:some-word [if] \ use the feature : my-word ... sf:some-word ... ; [else] \ Use some workaround [then] end-using-namespaces ``` ,------------------------------------------ | 2026-02-25 10:11:18 ruv replies: | proposal - Forth Standards, Backward Compatibility and modern `state of the art` words with their `historical traditional` counterparts. | see: https://forth-standard.org/proposals/forth-standards-backward-compatibility-and-modern-state-of-the-art-words-with-their-historical-traditional-counterparts-#reply-1626 `------------------------------------------ > Creating *backward compatibility* word sets and move the *historical traditional* words to there, if modern *state of the art* word pendants exist. If you are considering creating a new section (a word set) in the document, please note that proposals to move a word between sections usually do not find sufficient support. Regarding obsolescent words, they are usually excluded from the document on the next iteration. I don't think we should create a new normative section (a word set) containing specifications for obsolescent word. > Dictionary Manipulation: `LATEST` vs. `GET-CURRENT` > Previously, `LATEST` was a variable that could be easily read using `@`. Probably, you mean the word `current`. In FIG-Forth, the word `latest` returns an NFA (Name Field Area, now *name token*), not an address of the NFA (as I recently [mentioned](https://forth-standard.org/proposals/new-words-latest-name-and-latest-name-in#reply-1612)). The word `last` traditionally returns an address that contains NFA, see Forth-83, the section "UNCONTROLLED REFERENCE WORDS" ([link](https://github.com/larsbrinkhoff/forth-documents/blob/master/Forth83.txt#L4269)). ,------------------------------------------ | 2026-02-25 10:19:46 ruv replies: | requestClarification - The buffer containing c-addr u may be transient and valid until the next invocation of NAME>STRING | see: https://forth-standard.org/standard/tools/NAMEtoSTRING#reply-1627 `------------------------------------------ > Being transient until the next call to `NAME>STRING` necessitates that this word requires its own transient space and cannot use the transient spaces of other words Yes, but a transient buffer is not required, it is only allowed. > So more precise may be "... and is valid ...". Or maybe this: "The buffer containing *c-addr u* may be transient, but in any case it must be valid until the next invocation of `NAME>STRING`" ,------------------------------------------ | 2026-02-27 14:29:48 JimPeterson replies: | requestClarification - Implementation Query? | see: https://forth-standard.org/standard/core/ENVIRONMENTq#reply-1628 `------------------------------------------ I definitely see how it is best to switch based on particular features, rather than implementations, but that only works when the implementer has successfully guessed, ahead of time, what the user is concerned about. The situation I'm trying to address (the situation I'm in) is when the implementer has not provided a method for querying about a particular quirk/feature and the user is left to try to work around it. For instance, no implementer is going to (generally) implement the query "fsqrt-is-buggy" successfully, but if the user finds himself in that situation, the only way to write portable code will be to check implementation and version. All that said, I think we agree that both aspects are good to have. And when the feature-specific query exists, that's the better switch to use. ,------------------------------------------ | 2026-02-28 11:26:52 EkkehardSkirl replies: | requestClarification - The buffer containing c-addr u may be transient and valid until the next invocation of NAME>STRING | see: https://forth-standard.org/standard/tools/NAMEtoSTRING#reply-1629 `------------------------------------------ >"but in any case it must be" I agree with you. ,------------------------------------------ | 2026-02-28 11:54:26 EkkehardSkirl replies: | proposal - Forth Standards, Backward Compatibility and modern `state of the art` words with their `historical traditional` counterparts. | see: https://forth-standard.org/proposals/forth-standards-backward-compatibility-and-modern-state-of-the-art-words-with-their-historical-traditional-counterparts-#reply-1630 `------------------------------------------ What I'd like to propose for discussion is a more future-oriented approach to the standard (what I mean by "state of the art"), incorporating all the positive experiences and progressive insights gained, without clinging too tightly to the past. However, to ensure that the past is also adequately addressed, the standard should provide a framework for integrating it when needed. So, I envision the standard having two parts: the current standardizations and, secondly, the option to bridge the gap to the past. And sometimes I sense a kind of fear, between the lines, that it will be seen as "bad" if a system doesn't conform to Standard 999 but only to Standard 666. But Standard 666 is also perfectly fine if it fulfills its purpose, even if sometimes with somewhat more "complex" methods, isn't it? And programs that conform to standard 666 might be considered inferior to those that conform to standard 999. But isn't the primary goal of programming a program that fulfills its tasks, not necessarily adhering to the latest standard at all costs? The last two paragraphs were more philosophical in nature. I can only suggest something like this. Whether such a committee then considers such modern approaches is beyond my control. And I realize that this will likely be a very long-term undertaking that can't be implemented in the very next standard. ,------------------------------------------ | 2026-02-28 13:18:51 ruv replies: | proposal - Forth Standards, Backward Compatibility and modern `state of the art` words with their `historical traditional` counterparts. | see: https://forth-standard.org/proposals/forth-standards-backward-compatibility-and-modern-state-of-the-art-words-with-their-historical-traditional-counterparts-#reply-1631 `------------------------------------------ > The last two paragraphs were more philosophical in nature. Yes, and the ideas are quite general. Could you please identify and describe the first **specific change** in the document of the Standard? The smaller the change, the better. ,------------------------------------------ | 2026-02-28 16:43:36 ruv replies: | requestClarification - 2.1. Definitions of terms: Control-, Float-, Exception-stacks and may be more | see: https://forth-standard.org/standard/notation#reply-1632 `------------------------------------------ @EkkehardSkirl, your contribution has type "Request for clarification", but it does not contain any question. > my proposal ist to create entries In general I agree: if the terms "data stack" and "return stack" are given, why is not the term "control-flow stack"? Specific comments 1. I think the definition of a term should not contain implementation details such as "implemented using the return stack". 2. It is probably better to use the defined term "stack" instead of repeating "last in, first out list". Otherwise, the term "stack" is excessive. 3. Definitions of terms that are not used in the normative parts (like "source stack") should not be included in the section 2.1. 4. Terms used only within one word set are given in its corresponding section. - The term "exception stack" is given in [9.3.3](https://forth-standard.org/standard/exception#subsection.9.3.3); probably, it should be in [section 9.2](https://forth-standard.org/standard/exception#section.9.2). - The definition for "floating-point stack" is given in [12.3.3](https://forth-standard.org/standard/float#float:stack); maybe, a better place is [12.2.1 Definition of terms](https://forth-standard.org/standard/float#subsection.12.2.1). ,------------------------------------------ | 2026-02-28 19:50:37 ruv replies: | requestClarification - Implementation Query? | see: https://forth-standard.org/standard/core/ENVIRONMENTq#reply-1633 `------------------------------------------ > but that only works when the implementer has successfully guessed, ahead of time, what the user is concerned about. I don't see that. A lazy approach is to provide all **stable** system-specific words under a single namespace. For example, Gforth specific words in the "`https://gforth.org/`" namespace. A better approach is to split them into modules whose implementations are independent of the *implementation* of other modules, and assign each module its own namespace. It's worth nothing that, conceptually, the name of a word together with its namespace constitutes a fully qualified name, and a fully qualified name identifies an API (contract). For example, the `seal` word in the `https://gforth.org/` namespace (or perhaps `https://gforth.org/ns/search-order`), provided by any implementation, must behave as specified in the Gforth [documentation](https://gforth.org/manual/Word-Lists.html#index-seal). > The situation I'm trying to address (the situation I'm in) is when the implementer has not provided a method for querying about a particular quirk/feature and the user is left to try to work around it. If your choice is based on the Forth system name/version, you can use methods **specific to that system** without any loss. For example: ```forth s" gforth" environment? [if] "000.007." starts-with [else] false [then] [if] \ An implementation based on Gforth v0.7.* ... [else] \ A standard based implementation ... [then] ``` > For instance, no implementer is going to (generally) implement the query "fsqrt-is-buggy" successfully, but if the user finds himself in that situation, the only way to write portable code will be to check implementation and version. For some bugs or capabilities it is true (see [examples](https://github.com/Modernizr/Modernizr/wiki/Undetectables) for web-browsers), but not for a known bug in `fsqrt`. If you know that some system provides `fsqrt` with some known bug, it is better to detect this bug, not the system name/version. For example, check for precision loss in Newton’s method: ```forth 1e-38 fsqrt 1e-19 f- f0= invert [if] \ the bug exists \ Use your implementation include ./fsqrt-fix.fth [then] ```