,---------------. | Contributions | `---------------´ ,------------------------------------------ | 2024-05-13 08:33:18 ruv wrote: | requestClarification - Is it possible to eliminate the need for `UNLOOP`? | see: https://forth-standard.org/standard/core/UNLOOP#contribution-339 `------------------------------------------ The need for the `UNLOOP` word can be eliminated in two different ways: 1. In compilation time. When the compilation semantics for `EXIT` are performed, the number of containing `DO ... LOOP` structures is known, so the corresponding number of an internal word `(UNLOOP)` can be compiled automatically before `EXIT`. 2. In run-time. When the `DO` run-time semantics are performed, an internal word `(UNLOOP-EXIT)` entry point can be placed on the return stack as a part of _loop-sys_; then, if `EXIT` run-time semantics are performed inside the loop, `(UNLOOP-EXIT)` takes control, removes other _loop-sys_ params and performs the run-time semantics of `EXIT`; if `EIXT` run-time are not performed inside the loop, `(UNLOOP-EXIT)` is removed by `LOOP` run-time semantics as a part of _loop-sys_. In any case, these approaches should be used by Forth systems to remove the local variables frame before exiting. If the `UNLOOP` word is not needed, the stack diagram for the `EXIT` run-time semantics would be: Run-time `EXIT`: _( R: i*loop-sys nest-sys -- )_ Do you think it is theoretically possible in the future? For backward compatibility, `UNLOOP` can be implemented as a synonym of `NOP`. #### Rationale - slightly simpler and less error-prone code (you cannot miss `UNLOOP` if you don't need it at all); - more consistent language (why we don't need an analog of `UNLOOP` to manually remove a local variables frame?); - don't do manually what the system can do automatically. ,---------. | Replies | `---------´ ,------------------------------------------ | 2024-03-30 18:46:59 AntonErtl replies: | requestClarification - How can the zero result be used in a Standard program? | see: https://forth-standard.org/standard/tools/NAMEtoINTERPRET#reply-1217 `------------------------------------------ Some systems (e.g., Gforth-0.7) implement words (e.g., `if`) without interpretation semantics; what should these systems do when the nt of `if` is passed to `name>interpret`? The standard says that it returns 0. If it did not say that, what else should it say for that case? If a system implements interpretation semantics for `if` (e.g., Gforth-1.0, which makes them the same as compilation semantics), `name>interpret` of course returns an xt for those interpretation semantics. So, as a program, you cannot use `name>interpret` to detect that the standard does not define the interpretation semantics, but you can use it to detect that the system at hand does not define interpretation semantics. What it does with that information is up to the program; in the text interpreter example above a `-14 throw` was performed, but, e.g., an implementation of `find` will probably not do that. ,------------------------------------------ | 2024-03-31 19:38:14 ruv replies: | requestClarification - How can the zero result be used in a Standard program? | see: https://forth-standard.org/standard/tools/NAMEtoINTERPRET#reply-1218 `------------------------------------------ > Some systems (e.g., Gforth-0.7) implement words (e.g., `if`) without interpretation semantics; > what should these systems do when the nt of `if` is passed to `name>interpret`? The standard says that it returns 0. The standard says "If _nt_ has no interpretation semantics, `NAME>INTERPRET` returns 0". This is an unclear formulation, since it's impossible for a Forth system not to have interpretation semantics for a word (see below); and if one means the standard, one should say "interpretation semantics are not defined by this standard". Anyway, the standard allows to return _0_ in this case, but it also allows to return an _xt_ of a system-specific behavior. > If it did not say that, what else should it say for that case? I think the standard could say that in this case `name>interpret` shall return an _xt_ for a system-defined behavior (the system anyway shows some behavior). An example of wording (based on my [proposal 1110](https://forth-standard.org/proposals/name-interpret-wording?hideDiff#reply-1110)): - _xt_ identifies the execution semantics of the word identified by _nt_. When this _xt_ is executed in interpretation state, the interpretation semantics for the word are performed. If interpretation semantics for the word are not defined by this standard, the system-defined interpretation semantics are performed. An ambiguous condition exists in any of the following conditions: - interpretation semantics for the word are not defined by this standard and xt is executed; - execution semantics of the word are not defined by this standard and xt is executed in compilation state; What does Gforth-0.7 do when its text interpreter encounters `if` in interpretation state? This behavior is the _implemented_ interpretation semantics for `if`. And `name>interpret` *may* return an _xt_ that shows this behavior in interpretation state, also it may return `[: -14 throw ;]` regardless what behavior is shown. And no standard program can have any problem due to this behavior of `name>interpret`. Right? > but you can use it to detect that the system at hand does not define interpretation semantics. I would say it does not define an *execution token* for the word (and for that semantics). Because some interpretation semantics are actually defined by the system anyway (for example, it shows an error message and does abort). > What it does with that information is up to the program; in the text interpreter example above a `-14 throw` was performed, > but, e.g., an implementation of `find` will probably not do that. `find` in interpretation state may return the same _xt_ that `name>interpret` returns. ,------------------------------------------ | 2024-05-13 08:35:38 ruv replies: | requestClarification - Is it possible to eliminate the need for `UNLOOP`? | see: https://forth-standard.org/standard/core/UNLOOP#reply-1219 `------------------------------------------ Correction: If the `UNLOOP` word is not needed, the stack diagram for the `EXIT` run-time semantics would be: Run-time `EXIT`: _( R: nest-sys i*loop-sys -- )_