,---------------.
| Contributions |
`---------------´


,------------------------------------------
| 2024-01-05 08:52:21  lmr  wrote:
| requestClarification - throw code for compiling outside a definition
| see: https://forth-standard.org/standard/core/COMPILEComma#contribution-328
`------------------------------------------
Based on previous comments it's quite clear that both `LITERAL` and `COMPILE,` should to check at runtime whether they are appending to an existing definition, or (as GForth puts it) "compiling outside a definition". Merely disallowing their usage in `@ STATE` zero is not enough. But I'm wondering, if the system detects an attempt to append to a non-existing definition, what would be the most appropriate error code? -14 (interpreting a compile-only word)? -9 (invalid address)?


,------------------------------------------
| 2024-01-05 17:07:09  lmr  wrote:
| requestClarification - are colon-defs supposed to be compiled in data space?
| see: https://forth-standard.org/standard/core/Colon#contribution-329
`------------------------------------------
This may be very basic, but: are colon-definitions supposed to be compiled in data space (addressable by `@`, `!` etc)? Can the thread of compiled XTs (or whatever the implementation uses) for a definition reside in some other address space, visible only to the inner interpreter or the equivalent? I suppose the answer is obvious, since presumably an implementation could compile everything to a primitive.


,---------.
| Replies |
`---------´


,------------------------------------------
| 2024-01-01 07:56:56  AntonErtl  replies:
| requestClarification - diff from CORE FIND?
| see: https://forth-standard.org/standard/search/FIND#reply-1164
`------------------------------------------
The difference is that the search order version contains the following words, but the core version does not:

> after searching all the word lists in the search order


,------------------------------------------
| 2024-01-01 09:50:56  AntonErtl  replies:
| proposal - CS-DROP (revised 2019-08-22)
| see: https://forth-standard.org/proposals/cs-drop-revised-2019-08-22-#reply-1165
`------------------------------------------
Concerning the interaction of the extension of `cs-pick` and the
introduction of `cs-drop` with [automatic scoping](https://gforth.org/manual/Where-are-locals-visible-by-name_003f.html) (a Gforth feature),
it does not pose any difficulties that were not there before.
However, these features may increase the probability that users run
into these (up-to-now extremely rare) difficulties.

Here's the case analysis for it:

For dests there is nothing new for `cs-pick`.  In the usual case when
the `begin` that produced the dest is reachable from above, `Cs-drop`
results in the same situation that one would have if one had written
the code without the `begin`.  In the case when the `begin` is
unreachable from above, it results in the same situation one would
have if the `begin` was immediately followed by `again` or `until`:
the locals visible after the `begin` are only those visible at the
latest place outside any control structure.


For origs, whatever `cs-pick`s and `cs-drop`s are used, eventually the
orig is resolved by a `then`, and the situation for automatic scoping
does not change compared to the case when the same code had been
written without `cs-pick` and `cs-drop`.

The reason why these words do not change the situation is because
automatic scoping does not work with control-flow stack items except
when they are resolved by `then`, `until`, or `again`, or when the
programmer uses `assume-live`.


,------------------------------------------
| 2024-01-05 09:27:20  lmr  replies:
| referenceImplementation - Implementing COMPILE, via EXECUTE
| see: https://forth-standard.org/standard/core/COMPILEComma#reply-1166
`------------------------------------------
> `: compile, ( xt -- )  postpone literal  postpone execute ; `
> It's not an efficient implementation, but a correct and portable one.

The `postpone execute` part above needs to append `execute`'s XT to the current definition, i.e. a `COMPILE,` itself