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


,------------------------------------------
| 2019-07-02 10:29:22  JennyBrien  wrote:
| requestClarification - How can the zero result be used in a Standard program?
| see: https://forth-standard.org/standard/tools/NAMEtoINTERPRET#contribution-88
`------------------------------------------



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


,------------------------------------------
| 2019-06-27 07:25:47  AntonErtl  replies:
| comment - Interpretation semantics
| see: https://forth-standard.org/standard/core/COMPILEComma#reply-228
`------------------------------------------
I agree.

Appending something to the current definition when there is no current definition is obviously not a well-defined operation.  Explicitly making it an ambiguous condition would be a good idea.


,------------------------------------------
| 2019-06-27 07:49:44  AntonErtl  replies:
| requestClarification - The case of undefined interpretation semantics
| see: https://forth-standard.org/standard/tools/BracketDEFINED#reply-229
`------------------------------------------
1.  I think that, just as FIND may or may not return an xt, [DEFINED] may return true or false for this case; and I don't think that consistency between the choices for FIND and for [DEFINED] is required.  I.e., [DEFINED] is based on the standard FIND, not necessarily on the system's FIND.

2. Again, I don't think that consistency is required.  I also think that FIND should not throw in that case, but either return c-addr 0 or xt 1|-1.  I also think that all systems behave that way.

3. I think that the intention of the committee is that applying [DEFINED] to any name is valid.  I also think that all systems behave that way.

In any case, these are holes in the standard that should be fixed.




,------------------------------------------
| 2019-06-27 15:53:35  JennyBrien  replies:
| requestClarification - The case of undefined interpretation semantics
| see: https://forth-standard.org/standard/tools/BracketDEFINED#reply-230
`------------------------------------------
1. On which systems will `FIND` return 0 during interpretation for words with undefined interpretation?

   If a system has some way of distinguishing such words, say with a _compile-only_ flag, what is the expectation when warnings are set? 

   Shouldn't `FIND` distinguish between _not found_ and _found but compile-only_?

2.  Agreed. There is no need for either `FIND` or `[DEFINED]` to throw. Either they find a defined word, or they don't.

3. There is no reason why `[DEFINED]` shouldn't work on words with undefined interpretation. So, either:
   
     `FIND` , `'` and `[']` always return the execution token of the most recent match. If the definition has no interpretation semantics, then a Standard program 
      should not execute that xt unless compiling. `FIND` may return a different xt when compiling than when interpreting.

     or if these do not find compile-only words, define `[DEFINE]` etc. using FIND-NAME

     ``` : [DEFINED] parse-name find-name 0= ; IMMEDIATE ```


 


,------------------------------------------
| 2019-07-01 16:29:36  StephenPelc  replies:
| comment - Interpretation semantics
| see: https://forth-standard.org/standard/core/COMPILEComma#reply-231
`------------------------------------------
An ambiguous condition is not an error - it just indicates that different systems do different things. GForth is very strict. VFX is very tolerant - all words with names have FINDable XTs. This does not mean that executing the XT is useful or safe. It just means that an XT exists. We (MPE) use XTs for all sorts of functions like LOCATE and XREF tools. As a result of this ambiguity, words such as ' and ['] usually inherit their system's view of the world. For me, Forth is a dangerous language and should stay that way.