- ABORT
- ABORT"
- ABS
- ACCEPT
- ACTION-OF
- AGAIN
- ALIGN
- ALIGNED
- ALLOT
- AND
- BASE
- BEGIN
- BL
- BUFFER:
- [
- [CHAR]
- [COMPILE]
- [']
- CASE
- C,
- CELL+
- CELLS
- C@
- CHAR
- CHAR+
- CHARS
- COMPILE,
- CONSTANT
- COUNT
- CR
- CREATE
- C!
- :
- :NONAME
- ,
- C"
- DECIMAL
- DEFER
- DEFER@
- DEFER!
- DEPTH
- DO
- DOES>
- DROP
- DUP
- /
- /MOD
- .R
- .(
- ."
- ELSE
- EMIT
- ENDCASE
- ENDOF
- ENVIRONMENT?
- ERASE
- EVALUATE
- EXECUTE
- EXIT
- =
- FALSE
- FILL
- FIND
- FM/MOD
- @
- HERE
- HEX
- HOLD
- HOLDS
- I
- IF
- IMMEDIATE
- INVERT
- IS
- J
- KEY
- LEAVE
- LITERAL
- LOOP
- LSHIFT
- MARKER
- MAX
- MIN
- MOD
- MOVE
- M*
- -
- NEGATE
- NIP
- OF
- OR
- OVER
- 1-
- 1+
- PAD
- PARSE-NAME
- PARSE
- PICK
- POSTPONE
- +
- +LOOP
- +!
- QUIT
- RECURSE
- REFILL
- REPEAT
- RESTORE-INPUT
- R@
- ROLL
- ROT
- RSHIFT
- R>
- SAVE-INPUT
- SIGN
- SM/REM
- SOURCE-ID
- SOURCE
- SPACE
- SPACES
- STATE
- SWAP
- ;
- S\"
- S"
- S>D
- !
- THEN
- TO
- TRUE
- TUCK
- TYPE
- '
- *
- */
- */MOD
- 2DROP
- 2DUP
- 2/
- 2@
- 2OVER
- 2R@
- 2R>
- 2SWAP
- 2!
- 2*
- 2>R
- U.R
- UM/MOD
- UM*
- UNLOOP
- UNTIL
- UNUSED
- U.
- U<
- U>
- VALUE
- VARIABLE
- WHILE
- WITHIN
- WORD
- XOR
- 0=
- 0<
- 0>
- 0<>
- \
- .
- <
- >
- <>
- #>
- <#
- #
- #S
- (
- ?DO
- ?DUP
- >BODY
- >IN
- >NUMBER
- >R
6.2.2295 TO CORE EXT
Interpretation:
Skip leading spaces and parse name delimited by a space. Perform the "TO name run-time" semantics given in the definition for the defining word of name. An ambiguous condition exists if name was not defined by a word with "TO name run-time" semantics.
Compilation:
Skip leading spaces and parse name delimited by a space. Append the "TO name run-time" semantics given in the definition for the defining word of name to the current definition. An ambiguous condition exists if name was not defined by a word with "TO name run-time" semantics.
Note:
See:
Rationale:
x TO name
Some implementations of TO do not parse; instead they set a mode flag that is tested by the subsequent execution of name. Standard programs must use TO as if it parses. Therefore TO and name must be contiguous and on the same line in the source text.
Testing:
ContributeContributions
ruv
[72] Should TO be findable?Request for clarification2018-09-22 09:05:37
Since "an ambiguous condition exists if any of POSTPONE, [COMPILE], ' or ['] are applied to TO", does ambiguous condition exist if [DEFINED] is applied to TO ?
May a standard programme get xt of TO via SEARCH-WORDLIST? If yes, what semantics should this xt bring?
May TO word be absent in FORTH-WORDLIST in a standard Forth system that actually supports TO something?
AntonErtl
No ambiguous condition has been specified for [DEFINED] TO, and given that it does not return an xt, I don't see a reason for it.
Yes, a system can get an xt for TO through SEARCH-WORDLIST or FIND. For FIND, the specification is quite fuzzy about the returned xt (and see the proposal on clarifying FIND for that), for SEARCH-WORDLIST it isn't. Gforth therefore returns the xt corresponding to interpretation semantics from SEARCH-WORDLIST (and nobody has complained about that).
FORTH-WORDLIST is specified as containing all implemented standard words, and that includes TO.
StephenPelc
POSTPONE [COMPILE] and so on are ambiguous with respect to TO because it is unspecified how TO is implemented and how it works, e.g. it probably parses, but doesn't have to. In other words, even if you got an XT back, you would not know what to do with it, hence the code is not portable. [DEFINED] just wants to know if the word exists in the dictionary, so it only needs to return a flag.
Note that most systems permit ' ['] and so on to return an xt for any word in the system. At least one fails if the action of that xt is undefined by the standard.
ruv
[95] Ambiguous conditionsRequest for clarification2019-07-14 09:59:48
1. Why does an ambiguous condition exist if POSTPONE or [COMPILE] are applied to TO, despite the compilation semantics of TO is well defined?
I can guess that in some Forth system implementations it was difficult to correctly implement POSTPONE TO or [COMPILE] TO actions. But the committee felt that such implementations must be allowed in anyway.
2. In Forth-2012 another ambiguous condition was also mentioned: if ' or ['] are applied to TO (that was not mentioned explicitly in Forth-94).
Is this ambiguity is a consequence of the specification, or does it have roots outside the specification?
BerndPaysan
It all bogs down to how systems implement non-default compilation semantics (NDCS). Only one (a particular dual-xt approach) can work conforming to the standard. The TC however decided that the other implementations are ok, considering that there is no standard way to define dual-xt words and that this particular dual-xt approach maybe is not the “right” solution (debate is still open).
Implementations using a STATE-smart approach will fail with POSTPONE under some conditions (particularly, when you execute that word in interpretation mode, it's no longer performing the compilation semantics). Implementations using an intelligent COMPILE, (like VFX) will fail when you ' or ['], particularly when you COMPILE, that result, expecting to append its execution (=interpretation) semantics to the current definition, as specified by COMPILE,.
These limitations can probably go away when we find a consensus on how to deal with NDCS words.
AntonErtl
As Bernd Paysan writes, one guess is that they did this to allow STATE-smart implementations of TO. We certainly disallowed ticking it in Forth-2012 for that reason.
However, they did not apply the same restriction to S" (the other dual-semantics word in Forth-94); either they forgot it or that was not the reason why they added that restriction to TO. Another popular implementation approach for TO is to have it set a variable, and let the value perform either the "TO value" behaviour or just the "value" behaviour. There are two variations of this: doing that at run time, or at compile time (with IIRC a STATE-smart value). I currently cannot think of how disallowing POSTPONE TO would help with these kinds of implementations, but maybe there's a better explanation based on that.
TG9541
[188] What is the intent, purpose or meaning of TO?Example2021-04-17 06:23:37
The word interpretation and compilation semantic of the word is defined but I fail to understand the context of its usage without, at least, an example. In order to use or implement TO but as a human I first have to understand the intent, purpose or meaning of the word in the context of Forth.
Rationale: in the English language the word to has many idiomatic uses - coming from a Forth-79 background its purpose, meaning or intent isn't obvious and no reference to the documentation of modern implementation is offered.
TG9541
I was pointed to the win32forth doc which contains the following description:
TO CORE EXT
Interpretation: ( x "<spaces>name" -- )
Skip leading spaces and parse name delimited by a space. Store x in name. An ambiguous condition exists if name was not defined by VALUE.
Compilation: ( "<spaces>name" -- )
Skip leading spaces and parse name delimited by a space. Append the run-time semantics given below to the current definition. An ambiguous condition exists if name was not defined by VALUE.
Run-time: ( x -- )
Store x in name.
Note: An ambiguous condition exists if either POSTPONE or [COMPILE] is applied to TO.
See: 6.2.2405 VALUE, 13.6.1.2295 TO.
ruv
[360] A value-flavoured variable may be immediateSuggested Testcase2024-08-13 17:03:15
It turns out that in some implementations to behaves incorrectly when its argument is an immediate word.
t{ 0 value vfoo immediate -> }t
t{ : change-vfoo 1 to vfoo ; -> }t
t{ vfoo change-vfoo vfoo -> 0 1 }t
(hopefully, we will automatically render source codes in uppercase later)