Throw codes from to

[ruv]

Preamble

In the standard, the Table 9.1: THROW code assignments contains the line:

• -32 invalid name argument (e.g., TO name)

The term «name» refers to a parameter in the stack diagram, e.g. for TO:

• Interpretation: ( i*x "<spaces>name" -- )
• Compilation: ( "<spaces>name" -- )

This is the so-called parsed-text notation, in which:

• name: a token delimited by space, equivalent to «ccc<space>» or «ccc<eol>»

Side note: in the word name parse-name, «name» refers to a token delimited by space (a lexeme). But in the word names name>, find-name, find-name-in, name>string, name>compile, name>interpret, «name» refers to the name token (nt). This is an inconsistency in naming.

So, "name argument" is an immediate argument from the input source. For example, in the phrase «to xxx», "xxx" is an immediate argument.

Update: in some cases a name argument is not an immediate argument. For example, if a word is an ordinary word such as «'», «constant», and it's used in a definition body.

Question

The word to might detect the following problems with its immediate argument:
— a word with this name is not found in the search order;
— a word is found, but it is not created with value (or a such), i.e., "TO name" semantics are not defined for this word.

My question is: what throw code would be best for each of these cases?

The candidates are:

• -13 undefined word
• -32 invalid name argument (e.g., TO name)
• -21 unsupported operation (e.g., AT-XY on a too-dumb terminal)

What are your arguments in favor of using one option or another?

[ruv]

The word to might detect the following problems with its immediate argument:
— a word with this name is not found in the search order;
— a word is found, but it is not created with value (or a such), i.e., "TO name" semantics are not defined for this word.

My question is: what throw code would be best for each of these cases?

The candidates are:

• -13 undefined word
• -32 invalid name argument (e.g., TO name)
• -21 unsupported operation (e.g., AT-XY on a too-dumb terminal)

1. If the name argument to «to» is not found, «to» should throw error -13 ("undefined word"). More generally: if name argument to «to» is not recognized, «to» should throw error -13. In an even broader case: if the name argument to any word is not recognized, that word should throw error -13.

2. If the name argument to «to» is recognized but does not have "TO name Run-time" semantics, «to» should throw error -32.
More generally: if the name argument to a word is recognized but does not have the required semantics, the word should throw error -32.

3. Thus, «is», «action-of», «postpone» should align with these general conditions too.

Update: as well as «'» and «[']».

4. A recognizable syntax like «->foo» (that is equivalent to «to foo») also should throw error -32 if the required semantics are not defined for foo, and error -13 if foo is not recognized. Probably, the system can indicate the lexeme "foo" in the error message (instead of "->foo").

Factors

An interesting question is how «defer!» should behave when its xt argument does not have the corresponding semantics. Should it throw error -32, error -21, or something else? For example, with the word «>body», there is a special throw code -31 (">BODY used on non-CREATEd definition") in a similar situation. Perhaps we should introduce a new throw code for the general case where the required semantics are not defined for an object.

This is also related to the factors of «to» — «value!» and «compile-store-value».

However, there is an issue with introducing a separate throw code for cases where required semantics are not defined. This is because «to» must be implementable through its factors. For instance:

: to   '   state @ if compile-store-value exit then value! ; immediate
\ for simplicity, local variables are not processed here

In this implementation, «to» will throw the error codes of its factors. So, if «to» should throw -32 when required semantics are not defined for the name argument, then both «compile-store-value» and «value!» should throw -32 when required semantics are not defined for the xt argument.

We could make the implementation more complex:

: to   '   [: state @ if compile-store-value exit then value! ;] catch dup -21 = if drop -32 then throw ; immediate

This way, we could have different error codes for «to» and its factors.

But is it worth the complexity?
Personally, I don't think so. I believe the throw code -32 is sufficient for all cases. However, the description for this throw code should likely be updated.

[ruv]

I believe the throw code -32 is sufficient for all cases. However, the description for this throw code should likely be updated.

Some possible options:

• -32 invalid expression;
• -32 undefined semantics;

[ruv]

However, the description for this throw code should likely be updated.

Some possible options:

• -32 invalid expression;
• -32 undefined semantics;

-32 can be thought of as a special case of type mismatch, that is -12 ("argument type mismatch"). But if -32 is meant for arguments in the input source only (the name argument), it cannot be used by the factors of to, which only take arguments from the stack.

The description "undefined semantics for argument" looks appropriate in all use cases.
For example:

variable foo

' 123
123 to foo
123 ->foo
123 ' foo value!
: bar 123 [ ' foo compile-store-value ] ;

In all these cases, "undefined semantics for argument" seems clear. Doesn't it?

[forthy42]

Error messages should be helpful.

IMHO,

• -13 if the name is not recognized at all
• -32 if it is recognized, but not the expected type (a dictionary entry), e.g. a number instead
• -21 if it is the expected type, but doesn't support the operation (e.g. to only for value and variants, is only for defer).

If you don't go through a recognizer, you can skip the -32 option.

[ruv]

• -21 if it is the expected type, but doesn't support the operation (e.g. to only for value and variants, is only for defer).

Forth has subtyping. Therefore, "if is the expected type, but doesn't support the operation" effectively means it is an unexpected type.

So these arguments about -21 don't seem convincing to me yet.