6.1.2500 [ left-bracket CORE

"[" is used to switch from compiling context to interpreter mode. This allows inlining constants or code into word definition : date-created [ 20210718 ] LITERAL ;
depending on threading model one could create some special words calling machine code instructions : my-special-op [ machine-code param + , ] ; so the code between "[" and "]" is executed during compile-time from user perspective. if "[" was not immediate - forth state could not be switched from compilation mode to interpreter mode. Compiler would compile a call to [ into the code.

The question is: Why are the interpretation semantics undefined? Is there any standard system where [ has no interpretation semantics or where they are different from the compilation semantics?

It seems, I have realized why [ was specified as immediate: since this word had "I" (immediate) attribute in Forth-83, and this property was just inherited for this word in Forth-94. But it's unnecessary even in the current wording.

@JeanJonethal writes:

if "[" was not immediate - forth state could not be switched from compilation mode to interpreter mode.

It's wrong. For example, take a look at the IF word — immediacy isn't specified for this word, and it is implemented as non immediate (in the standard notion, it can be tested) in many Forth systems; although, it may be implemented as immediate. See also A.6.1.1550: "POSTPONE allowed de-specification of immediacy or non-immediacy for all but a few Forth words whose behavior must be STATE-independent". And indeed, immediacy should not be specified for a word having a STATE-dependent behavior (or that is allowed to have a STATE-dependent behavior, such as a word having undefined interpretation semantics).

Moreover, immediacy cannot be tested by a standard program for a word with undefined interpretation semantics, since the execution token cannot be obtained for such a word. So there is no any sense to mention immediacy for [ even in the current wording.

@AntonErtl writes:

The question is: Why are the interpretation semantics undefined?

It's obvious: in a cmForth-like Forth system this word can be unfound in interpretation state, and it was actually defined only in the COMPILER wordlist in cmForth. Therefore, to support this model, interpretation semantics should be undefined for this word by the standard.

Is there any standard system where [ has no interpretation semantics or where they are different from the compilation semantics?

Strictly speaking, in real Forth systems "no interpretation semantics" is a nonsense. Since even if a Forth system raises an error in interpretation state for some word, then it is a behavior that constitutes the interpretation semantics for this word. But it's another topic.

In many real Forth systems the actual interpretation semantics for [ are to do nothing. But the compilation semantics for this word are to enter interpretation state. Hence, they are different. See more reasonings in my post "About POSTPONE semantics in edge cases" on ForthHub.

Read it in reverse, [ is the only word this Standard explicitly declares IMMEDIATE  and whose Interpretation semantics are undefined.

In this perspective [ is a most peculiar word that cannot be easily compared with other words with undefined interpretation semantics such as IF or others alike because [ is not STATE-dependant like them: in fact it is the opposite i.e. STATE is [-dependant since STATE is modified by  [  independantly from what the current (value of) STATE is.

AFAIK there is only one more word this Standard explicitly declares IMMEDIATE i.e. \  the comment till EOL.

Both [ and \ (if you want them to perform their duty and you aren't creating some special word) just cannot be compiled and the only way to accpmplish this is having them IMMEDIATE.

Having ] undefined interpretation semantics seems a bit misleading but it IMHO means that there is no reason or no useful effect to use it while not compiling.

Matteo

AFAIK there is only one more word this Standard explicitly declares IMMEDIATE i.e. \ the comment till EOL.

In the standard, if for some word the compilation semantics are equivalent to the interpretation semantics, then this word is declared as immediate. There a number of such words: [defined], [undefined], [if], [else], [then], (, .(, \.

Also, many other words may be actually implemented as immediate words. Namely, if the glossary entry for a word contains "Interpretation" section, then it is allowed and possible to implement this word as an immediate word (in the standard notion).

such as IF or others alike because [ is not STATE-dependant like them

It's incorrect (and slightly ambiguous).

If you imply execution semantics, — they are not specified for these words, and then this claim is incorrect.

In the standard, in one place where the term "STATE-independent behavior" is used (A.6.1.1550 FIND), it means that the compilation semantics for a word are equivalent to the interpretation semantics for the word.

In this sense your claim is incorrect too.

1. The standard allows IF to be STATE-independent. The interpretation semantics for IF are undefined by the standard, and so this word is allowed to be implemented in such a way that its interpretation semantics are equivalent to its compilation semantics (see A.3.4.3.2).

2. The standard allows [ to be STATE-dependent, since the interpretation semantics for this word are undefined by the standard.

On behalf of the committee.

The word [ is immediate because of a historical accident. If you wish to make a proposal, we invite you to do so.

The committee leans towards defining interpretation semantics.

In most Forth systems the implemented interpretation semantics for [ are to do nothing. Probably in some systems they are to throw an exception.

And I don't have any idea how a program can rely to the former implementation variant. Could anybody provide a program example that has a benefit due to interpreting the word [ in interpretation state?

I can only imagine a situation when a user in REPL accidentally uses [ in interpretation state, and one system just interprets it without any side effects, but another shows an error message.

So a question is: why is one variant preferred over another?