From: ruvim.pinka@gmail.com   
      
   On 2024-09-23 20:52, Anton Ertl wrote:   
   > Ruvim  writes:   
   >> On 2024-09-23 12:36, albert@spenarnc.xs4all.nl wrote:   
   >> I also wanted to say that there is an opinion that this definition does   
   >> not implement `s"` specified in 11.6.1.2165. An interesting question for   
   >> those who share this opinion: how can 11.6.1.2165 be changed (if at all)   
   >> to allow this implementation?   
   >   
   > The implementation is not in your posting, but I guess you mean a   
   > STATE-smart implementation.  One way to allow a STATE-smart   
   > implementation of S" would be to state something like the following in   
   > the "Interpretation:" section of the glossary entry of 11.6.1.2165:   
   >   
   > An ambiguous condition exists if the interpretation semantics of S" is   
   > performed in other than interpration state.   
   >   
   > Likewise, add the following to the "Compilation:" section:   
   >   
   > An ambiguous condition exists if the compilation semantics of S" is   
   > performed in other than compilation state.   
      
      
   So, according to this approach, in the specification for every   
   unordinary word that is allowed to be implemented as a single-xt or as a   
   dual-xt word, you have to mention these ambiguous conditions.   
      
   This would be a poor language for specification such words, I think.   
      
   It looks like in this approach, you actually partially specify a   
   behavior for xt1 and partially specify a behavior for xt2, and you also   
   specify in which STATE xt1 shall be executed, and in which STATE xt2   
   shall be executed. One problem in this approach is that you have to   
   repeat the latter for every such word. And another problem is that you   
   still don't specify how to obtain xt1 and xt2.   
      
      
   A better way is to only specify what behavior shall be exhibit when the   
   Forth text interpreter encounters the word in interpretation state (the   
   (observable) interpretation semantics), and what behavior shall be   
   exhibit when the Forth text interpreter encounters the word in   
   compilation state (the (observable) compilation semantics). And in a   
   *common* part specify once how to perform this or that behavior.   
      
      
      
      
   For example, we can say:   
      
   Performing the execution semantics of a word in interpretation state   
   shall exhibit the (observable) interpretation semantics of the word.   
      
   An ambiguous condition exists if execution semantics for a word are not   
   defined by the standard and the system-dependent execution semantics of   
   the word are performed in compilation state.   
      
   An ambiguous condition exists if interpretation semantics for a word are   
   not defined by the standard and the system-dependent execution semantics   
   of the word are performed.   
      
   Note. The execution semantics of a word are identified by an execution   
   token that can be obtained using `find` in interpretation state,   
   `search-wordlist`, `name>interpret`, `'`, `[']`.   
      
   Note. At the moment, if a Forth system provides some standard word and   
   does not provide an execution token of this word, then the system cannot   
   provide the word `forth-wordlist` (due to 16.6.1.1595).   
      
      
      
   Concerning performing (observable) compilation semantics — this should   
   be specified in `find`, and `name>compile`.  In `search-wordlist` we   
   should better specify the meaning of the top output value.   
      
      
   --   
   Ruvim   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)