6.10.11 Deferred Words ¶

The defining word Defer allows you to define a word by name without defining its behaviour; the definition of its behaviour is deferred. Here are two situation where this can be useful:

• Where you want to allow the behaviour of a word to be altered later, and for all precompiled references to the word to change when its behaviour is changed.
• For mutual recursion; See Calls and returns.

In the following example, foo always invokes the version of greet that prints “Good morning” whilst bar always invokes the version that prints “Hello”. There is no way of getting foo to use the later version without re-ordering the source code and recompiling it.

: greet ." Good morning" ;
: foo ... greet ... ;
: greet ." Hello" ;
: bar ... greet ... ;

This problem can be solved by defining greet as a Deferred word. The behaviour of a Deferred word can be defined and redefined at any time by using IS to associate the xt of a previously-defined word with it. The previous example becomes:

Defer greet ( -- )
: foo ... greet ... ;
: bar ... greet ... ;
: greet1 ( -- ) ." Good morning" ;
: greet2 ( -- ) ." Hello" ;
' greet2 IS greet  \ make greet behave like greet2

Programming style note:

You should write a stack comment for every deferred word, and put only XTs into deferred words that conform to this stack effect. Otherwise it’s too difficult to use the deferred word.

A deferred word can be used to improve the statistics-gathering example from User-defined Defining Words; rather than edit the application’s source code to change every : to a my:, do this:

: real: : ;     \ retain access to the original
defer :         \ redefine as a deferred word
' my: IS :      \ use special version of :
\
\ load application here
\
' real: IS :    \ go back to the original

One thing to note is that IS has special compilation semantics, such that it parses the name at compile time (like TO):

: set-greet ( xt -- )
  IS greet ;

' greet1 set-greet

In situations where IS does not fit, use defer! instead.

A deferred word can only inherit execution semantics from the xt (because that is all that an xt can represent – for more discussion of this see Tokens for Words); by default it will have default interpretation and compilation semantics deriving from this execution semantics. However, you can change the interpretation and compilation semantics of the deferred word in the usual ways:

: bar .... ; immediate
Defer fred immediate
Defer jim

' bar IS jim  \ jim has default semantics
' bar IS fred \ fred is immediate

Defer ( "name" –  ) core-ext “Defer”

Define a deferred word name; its execution semantics can be set with defer! or is (and they have to, before first executing name.

defer! ( xt xt-deferred –  ) core-ext “defer-store”

Changes the deferred word xt-deferred to execute xt.

IS ( value "name" –  ) core-ext “IS”

changes the deferred word name to execute value

defer@ ( xt-deferred – xt  ) core-ext “new-defer-fetch”

xt represents the word currently associated with the deferred word xt-deferred.

action-of ( interpretation "name" – xt; compilation "name" – ; run-time – xt  ) core-ext “action-of”

Xt is the XT that is currently assigned to name.

Definitions of these Forth-2012 words in Forth-94 are provided in compat/defer.fs. In addition, Gforth provides:

defers ( compilation "name" – ; run-time ... – ...  ) gforth-0.2 “defers”

Compiles the present contents of the deferred word name into the current definition. I.e., this produces static binding as if name was not deferred.

wrap-xt ( xt1 xt2 xt: xt3 – ...  ) gforth-1.0 “wrap-xt”

Set deferred word xt2 to xt1 and execute xt3. Restore afterwards.

preserve ( "name" –  ) gforth-1.0 “preserve”

emit code that reverts a deferred word to the state at compilation