,---------------. | Contributions | `---------------´ ,------------------------------------------ | 2023-03-11 02:25:18 JimPeterson wrote: | referenceImplementation - Possible Reference Implementation | see: https://forth-standard.org/standard/core/CONSTANT#contribution-293 `------------------------------------------ Maybe this?: ``` : constant >r : r> postpone literal postpone ; ; ``` ,---------. | Replies | `---------´ ,------------------------------------------ | 2023-03-06 20:54:23 ruv replies: | proposal - WLSCOPE -- wordlists switching made easier | see: https://forth-standard.org/proposals/wlscope-wordlists-switching-made-easier#reply-1001 `------------------------------------------ > Add the word `DEFINE ( xt c-addr u -- )` Sure, such a word should be standardized — many systems have it under names like `aka`, `alias`, `naming`, `enroll-name`, etc. > as a deferred word A deferred word is a bad choice for an API, since a deferred word cannot be redefined, since the system's words `to`, `action-of`, `defer@`, `defer!` are not applicable to the redefined word. Therefore, a separate getter and setter should be used in APIs. > the system's own wordlist mechanic can be leveraged to provide the user with arbitrary named storage capability, storing user data as xt. Why not to expose such a mechanic under its own general API, which is not connected to execution tokens and immediacy? It can be even implemented as a portable library. > We might also want a `DELETE-WORDLIST ( wid -- )`, to clean up later. I think, this functionality cannot be implemented in most systems. In some cases [`marker`](https://forth-standard.org/standard/core/MARKER) can be used instead. ,------------------------------------------ | 2023-03-07 00:48:39 ruv replies: | comment - Data object notion usage | see: https://forth-standard.org/standard/usage#reply-1002 `------------------------------------------ @AidanPitt-Brooke, thank you for your effort in this convoluted topic. As I understand, "data object" is a [*primitive notion*](https://en.wikipedia.org/wiki/Primitive_notion) in the standard (as well as a similar notion "set of information"). It's not an object in OOP sense. A data object is a _sequence of bits_, from which you can infer neither its length nor its data type in the general case (i.e., it does not know its type). The standard considers only data objects that can be placed on some stack (among the data stack, control-flow stack, floating-point stack, return stack, exception stack). It means that any data object (which is available for a program) can be represented as a [*tuple*](https://en.wikipedia.org/wiki/Tuple) of the stack items, on which this data object is placed. NB: in some cases the length of a tuple is unknown for a program, and this length can be even zero (e.g. for _nest-sys_ on the return stack). Of course, actual implementations might operate on compound data objects in memory, but these data objects are usually unavailable for a program, and formally (in the standard) they are represented by other data objects — opaque identifiers (which are tuples). For example, an identifier of execution semantics, word list identifier, file identifier, result of `save-input` _( i*x u.i )_. NB: obviously, some data objects don't have a numeric interpretation at all — formally, they are not numbers (in algebraic sense). "An ambiguous condition exists if an incorrectly typed **data object is encountered**" — what a word, during execution, consumes from a stack or produces on the stack are just data objects only. Then, what does the term "value" mean in this context? As I can see, it is either a synonym for "data object", or an interpretation of a data object as a number (a numeric value). Anyway, it's unclear what does "a set of permissible values for a data object" mean? What different values can a single concrete data object have? ,------------------------------------------ | 2023-03-07 13:46:06 ruv replies: | proposal - Update rationale for SLITERAL | see: https://forth-standard.org/proposals/update-rationale-for-sliteral#reply-1003 `------------------------------------------ ## Author Ruv ## Change Log - 2023-03-07 Better wordings in several places, correction some typos - 2023-03-06 Initial version ## Problem In the [draft 2020-01](https://github.com/Forth-Standard/forth-standard/blob/6e4d1083c06e8e326b53f29072570fe510b58aec/forth.pdf), the section A.17.6.1.2212 `SLITERAL` conflicts with the section 6.1.2165 `S"`. In 2017 it was decided to merge the words FILE `S"` and `S\"` into the corresponding words in CORE/CORE-EXT (see the [minutes 2017](https://github.com/Forth-Standard/forth200x/blob/master/meetings/2017-notes#L92) and preceding discussion "[Core-ext `S\"` should reference File-ext `S\"`](https://forth-standard.org/proposals/core-ext-s-should-reference-file-ext-s-)"). It was implemented in the draft 2020-01. However, the section A.17.6.1.2212 has not been updated, and it shows an implementation for the version of CORE `S"` before 2017, which leads to confusions (it was noticed by Anthony Howe in "[Confusion over `S"` and `SLITERAL`](https://github.com/ForthHub/discussion/discussions/128)"). ## Solution Update the section A.17.6.1.2212 according to the new 6.1.2165. Take into account [A.6.1.0190 `."`](https://forth-standard.org/standard/rationale#rat:core:.q). ## Proposal Replace the content of the section [A.17.6.1.2212 `SLITERAL`](https://forth-standard.org/standard/rationale#rat:string:SLITERAL) by the following: > The current functionality of 6.1.2165 `S"` may be provided by the following definition: > ``` > : S" ( "ccc" -- c-addr u | ) > [CHAR] " PARSE STATE @ IF POSTPONE SLITERAL THEN > ; IMMEDIATE > ``` > Depending on the Forth system implementation, this definition can lead to the following environmental restrictions: > - the lifetime of the string returned by the interpretation semantics for `S"` is only valid until the input buffer has been refilled or the input source is not the same; > - the compilation semantics for `S"` that are appended by applying `POSTPONE` to `S"` cannot be performed if the system in interpretation state (due to a possible restriction of `POSTPONE`). In the section 6.1.2165 `S"`, add into the last paragraph, which starts with "See:", at the end before the dot: > , A.17.6.1.2212 `SLITERAL` ,------------------------------------------ | 2023-03-07 15:03:36 ruv replies: | proposal - Update rationale for SLITERAL | see: https://forth-standard.org/proposals/update-rationale-for-sliteral#reply-1004 `------------------------------------------ The phrase "the input source is changed" is slightly ambiguous, since it can mean: - "the **state** of the input source is changed"; - "the **identity** of the input source is changed" (i.e., another source is used as the input source, with its own state). The phrase "the input source is not the same" (which is used in [A.6.2.2182 `SAVE-INPUT`](https://forth-standard.org/standard/rationale#rat:core:SAVE-INPUT)) means that identity of the input source is changed. Therefore, in the version 2023-03-07 the form "is not the same" is used, instead of "is changed". ,------------------------------------------ | 2023-03-09 10:38:44 ruv replies: | proposal - Relax documentation requirements of Ambiguous Conditions | see: https://forth-standard.org/proposals/relax-documentation-requirements-of-ambiguous-conditions#reply-1005 `------------------------------------------ By the way, the introduction of [Chapter 4](https://forth-standard.org/standard/doc#chapter.4) already allows to not specify a particular behavior in an ambiguous condition case, but it still requires to explain reasons. ,------------------------------------------ | 2023-03-10 11:39:07 ruv replies: | comment - Behavior when no text found | see: https://forth-standard.org/standard/core/CHAR#reply-1006 `------------------------------------------ The section [3.4.1 Parsing](https://forth-standard.org/standard/usage#usage:parsing) says: "Parsing may change the contents of `>IN`, but shall not affect the contents of the input buffer". It means, `CHAR`, doing parsing, shall not refill the input buffer. On the other hand, [4.1.2 Ambiguous conditions](https://forth-standard.org/standard/doc#subsection.4.1.2) says that an ambiguous condition can occur due to "unexpected end of input buffer, resulting in an attempt to use a zero-length string as a _name_". NB: "_name_" is not necessary a word name. It's a special [parsed text abbreviation](https://forth-standard.org/standard/notation#notation:parsed), which means "a token delimited by space" (actually a lexeme). Due to this ambiguous condition, `CHAR` may do anything if _name_ is empty string, including refilling the input buffer. Probably a good choice is just to throw an exception.