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


,------------------------------------------
| 2019-07-03 11:42:27  ruv  wrote:
| comment - What is a standard program
| see: https://forth-standard.org/standard/notation#contribution-89
`------------------------------------------
"Standard program" term is often mentioned in the discussions and it is used in the [specification of `TO` word](https://forth-standard.org/standard/core/TO). It seems there is a sense to add a definition for this term.


A possible variant:

**standard programme**: a _programme_ that is expressed in the _standard words_ only and does not contain the _ambiguous conditions_ (unspecified behavior).



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


,------------------------------------------
| 2019-07-03 06:32:28  AntonErtl  replies:
| requestClarification - The case of undefined interpretation semantics
| see: https://forth-standard.org/standard/tools/BracketDEFINED#reply-232
`------------------------------------------
1. On cmForth.  Note that e.g., Gforth 0.7 returns the xt of a word that produces an error.

   (The future) Gforth 1.0 defines the interpretation semantics of all words, and compile-only results in a warning in some cases.  FIND just produces the xt for the interpretation semantics without outputting a warning.

   I don't think it is worth the effort to put such a requirement in FIND at this time.  With FIND-NAME and NAME>INTERPRET, you can differentiate between these cases.

2. Yes

3. Yes, if a system implements [DEFINED] based on a FIND that returns 0 in interpret state for AGAIN, the following would not work as intended:

        [defined] again 0= [if] : again 0 postpone literal postpone until ; immediate [then]

   That would not be so great.  Does someone want to write a proposal for fixing this flaw in [DEFINED] and [UNDEFINED]?


,------------------------------------------
| 2019-07-03 06:38:33  AntonErtl  replies:
| requestClarification - How can the zero result be used in a Standard program?
| see: https://forth-standard.org/standard/tools/NAMEtoINTERPRET#reply-233
`------------------------------------------
For a standard program, this is usually a restriction rather than an entitlement: It has to cope with the possibility of NAME>INTERPRET returning 0.  Anyway, here is an example of how to deal with that: A user-defined text interpreter:

```
... parse-name 2dup find-name if nip nip
  state @ if
    name>compile
  else
    name>interpret dup 0= -14 and throw
  then
  execute
else
  ... deal with numbers
then
```


,------------------------------------------
| 2019-07-03 12:32:11  ruv  replies:
| comment - What is a standard program
| see: https://forth-standard.org/standard/notation#reply-234
`------------------------------------------
hot fix: read __program__ in place of __programme__.


,------------------------------------------
| 2019-07-03 14:44:17  ruv  replies:
| comment - Interpretation semantics
| see: https://forth-standard.org/standard/core/COMPILEComma#reply-235
`------------------------------------------
I could say that it is a mistake if a standard program contains an ambiguous condition (or unspecified behavior). The program just becomes non standard thereby.
Standard programs cannot contain the ambiguous conditions — by definition (recently [proposed](https://forth-standard.org/standard/notation#contribution-89) by me). 
Therefore, whatever a Forth system does in an ambiguous condition — it does not matter, a standard program shall never reach this condition.

In other words, the ambiguous conditions describe the things that standard programs should never do.

Regarding `COMPILE,` word, — a standard program shall not execute this word if there is no _current definition_ (assuming that we will have added the corresponding clause into the specification).


,------------------------------------------
| 2019-07-03 16:02:12  ruv  replies:
| requestClarification - The case of undefined interpretation semantics
| see: https://forth-standard.org/standard/tools/BracketDEFINED#reply-236
`------------------------------------------
In Forth-2012 standard we have the following important clause:
  attempting to obtain the execution token of a definition with undefined interpretation semantics is an _ambiguous condition_ (*).

I like this clause, — it allows to implement the definition with undefined interpretation semantics via recognizers in a Standard System. Also, `[DEFINED]` may return 0 for the corresponding names. And this system still be a Standard System.

Actually, I would to propagate the clause (*) to the definitions with dual semantics and to the definitions with special compilation semantics too.