Node:Combined words, Previous:Interpretation and Compilation Semantics, Up:Interpretation and Compilation Semantics
Gforth allows you to define combined words - words that have an
arbitrary combination of interpretation and compilation semantics.
interpret/compile:interp-xt comp-xt "name" -- gforth ``interpret/compile:''
This feature was introduced for implementing
recommend that you do not define such words, as cute as they may be:
they make it hard to get at both parts of the word in some contexts.
E.g., assume you want to get an execution token for the compilation
part. Instead, define two words, one that embodies the interpretation
part, and one that embodies the compilation part. Once you have done
that, you can define a combined word with
the convenience of your users.
You might try to use this feature to provide an optimizing
implementation of the default compilation semantics of a word. For
example, by defining:
:noname foo bar ; :noname POSTPONE foo POSTPONE bar ; interpret/compile: opti-foobar
as an optimizing version of:
: foobar foo bar ;
Unfortunately, this does not work correctly with
[compile] assumes that the compilation semantics of all
interpret/compile: words are non-default. I.e.,
opti-foobar would compile compilation semantics, whereas
[compile] foobar would compile interpretation semantics.
Some people try to use state-smart words to emulate the feature provided
interpret/compile: (words are state-smart if they check
STATE during execution). E.g., they would try to code
foobar like this:
: foobar STATE @ IF ( compilation state ) POSTPONE foo POSTPONE bar ELSE foo bar ENDIF ; immediate
Although this works if
foobar is only processed by the text
interpreter, it does not work in other contexts (like
' foobar will produce an execution token
for a state-smart word, not for the interpretation semantics of the
foobar; when you execute this execution token (directly
EXECUTE or indirectly through
COMPILE,) in compile
state, the result will not be what you expected (i.e., it will not
foo bar). State-smart words are a bad idea. Simply don't
It is also possible to write defining words that define words with
arbitrary combinations of interpretation and compilation semantics. In
general, they look like this:
: def-word create-interpret/compile code1 interpretation> code2 <interpretation compilation> code3 <compilation ;
For a word defined with
def-word, the interpretation
semantics are to push the address of the body of word and perform
code2, and the compilation semantics are to push the address of
the body of word and perform code3. E.g.,
can also be defined like this (except that the defined constants don't
behave correctly when
: constant ( n "name" -- ) create-interpret/compile , interpretation> ( -- n ) @ <interpretation compilation> ( compilation. -- ; run-time. -- n ) @ postpone literal <compilation ;
create-interpret/compile"name" -- gforth ``create-interpret/compile''
interpretation>compilation. -- orig colon-sys gforth ``interpretation>''
<interpretationcompilation. orig colon-sys -- gforth ``<interpretation''
compilation>compilation. -- orig colon-sys gforth ``compilation>''
<compilationcompilation. orig colon-sys -- gforth ``<compilation''
Words defined with
create-interpret/compile have an extended header structure that
differs from other words; however, unless you try to access them with
plain address arithmetic, you should not notice this. Words for
accessing the header structure usually know how to deal with this; e.g.,
>body also gives you the body of a word created
For a more detailed discussion of this topic, see
M. Anton Ertl,
State-smartness---Why it is Evil and How to Exorcise it, EuroForth '98.