Digest #61 2019-07-04


[89] 2019-07-03 11:42:27 ruv wrote:

comment - What is a standard program

"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).


[r232] 2019-07-03 06:32:28 AntonErtl replies:

requestClarification - The case of undefined interpretation semantics

  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]?

[r233] 2019-07-03 06:38:33 AntonErtl replies:

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>interpret dup 0= -14 and throw
  ... deal with numbers

[r234] 2019-07-03 12:32:11 ruv replies:

comment - What is a standard program

hot fix: read program in place of programme.

[r235] 2019-07-03 14:44:17 ruv replies:

comment - Interpretation semantics

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).

[r236] 2019-07-03 16:02:12 ruv replies:

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.