,---------------. | Contributions | `---------------´ ,------------------------------------------ | 2021-04-17 06:23:37 TG9541 wrote: | example - What is the intent, purpose or meaning of TO? | see: https://forth-standard.org/standard/core/TO#contribution-188 `------------------------------------------ The word interpretation and compilation semantic of the word is defined but I fail to understand the context of its usage without, at least, an example. In order to use or implement `TO` but as a human I first have to understand the intent, purpose or meaning of the word in the context of Forth. Rationale: in the English language the word `to` has many idiomatic uses - coming from a Forth-79 background its purpose, meaning or intent isn't obvious and no reference to the documentation of modern implementation is offered. ,------------------------------------------ | 2021-04-17 07:08:48 TG9541 wrote: | requestClarification - Advantages of a Forth system with a STATE flag? | see: https://forth-standard.org/standard/core/STATE#contribution-189 `------------------------------------------ I'd like to ask politely for the rationale to mandate an implementation that requires using `STATE @` (while forbidding `STATE !`) instead of just requiring a word that returns the state. Rationale: eForth uses a pointer ['IDLE] that points to either `$COMPILE` or `$INTERPRET`. Testing the state is done by something like `: COMPILE? ( -- flag ) 'IDLE @ ['] $COMPILE =`. It's, of course, possible to change the eForth Outer Interpreter but the benefit should outweigh the cost of breaking properties that have a value for small Forth systems (e.g. compactness, extensibility). ,---------. | Replies | `---------´ ,------------------------------------------ | 2021-04-17 09:23:48 TG9541 replies: | comment - Note incompatability (double v single) with some older Forth's. | see: https://forth-standard.org/standard/core/num#reply-643 `------------------------------------------ As a maintainer of an old 8bit STC eForth variant I'm taking note of this discussion, and I'm of course thinking about options as using 32 bit math on a 8 or 16bit system is expensive. Before I take a decision, I'd like to clarify what "double" means on the background of the discussion "`S>D` in the standard, not double word set". I'd like to know what a double is in a system with 32 cells ( I'm reminded of the ambiguities of `int` and `long int` with respect to the native word width in the C language). ,------------------------------------------ | 2021-04-17 15:08:48 ruv replies: | requestClarification - Advantages of a Forth system with a STATE flag? | see: https://forth-standard.org/standard/core/STATE#reply-644 `------------------------------------------ > It's, of course, possible to change the eForth Outer Interpreter There is another option: just save the corresponding flag into `STATE` every time when you change `'IDLE`. So you can provide `STATE` word without changing the outer text interpreter. Also the standard doesn't require a system to use `STATE @` for its internal purposes. This method is exposed just for backward compatibility. > instead of just requiring a word that returns the state Certainly it's a better variant, but even having such a word, the systems are still required to support `STATE` for some time for backward compatibility. Meanwhile, I would propose to consider the following names for this word: ``` COMPILATION ( -- flag ) COMPILING ( -- flag ) ``` ,------------------------------------------ | 2021-04-17 16:14:14 TG9541 replies: | example - What is the intent, purpose or meaning of TO? | see: https://forth-standard.org/standard/core/TO#reply-645 `------------------------------------------ I was pointed to the win32forth doc which contains the following description: `TO` CORE EXT Interpretation: ( x "name" -- ) Skip leading spaces and parse name delimited by a space. Store x in name. An ambiguous condition exists if name was not defined by VALUE. Compilation: ( "name" -- ) Skip leading spaces and parse name delimited by a space. Append the run-time semantics given below to the current definition. An ambiguous condition exists if name was not defined by VALUE. Run-time: ( x -- ) Store x in name. Note: An ambiguous condition exists if either POSTPONE or [COMPILE] is applied to TO. See: 6.2.2405 VALUE, 13.6.1.2295 TO. ,------------------------------------------ | 2021-04-17 17:34:37 TG9541 replies: | requestClarification - Does the standard assume that DEFER was created with CREATE? | see: https://forth-standard.org/standard/core/DEFERStore#reply-646 `------------------------------------------ I've seen the part about examples being non-normative. I'm closing this now. Thanks for your work! ,------------------------------------------ | 2021-04-17 17:49:29 TG9541 replies: | requestClarification - Advantages of a Forth system with a STATE flag? | see: https://forth-standard.org/standard/core/STATE#reply-647 `------------------------------------------ @RUV thanks for your kine reply! I think I can make a kludge that hides the implementation details - something in the line of "`STATE` updating a variable when used". Of course that's risky but it has the advantage that it won't create an overhead unless an application uses `STATE`. By the way, `'IDLE` was a mistake - it should read `'EVAL`.