Digest #61 2019-07-04
Contributions
"Standard program" term is often mentioned in the discussions and it is used in the specification of TO word. 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
requestClarification - The case of undefined interpretation semantics
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.
Yes
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]?
requestClarification - How can the zero result be used in a Standard program?
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
hot fix: read program in place of programme.
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 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).
requestClarification - The case of undefined interpretation semantics
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.