6.2.1175 DEFER! defer-store CORE EXT

( xt2 xt1 -- )

Set the word xt1 to execute xt2. An ambiguous condition exists if xt1 is not for a word defined by DEFER.

See:

Implementation:

: DEFER! ( xt2 xt1 -- )
   >BODY ! ;

Testing:

T{ DEFER defer3 -> }T

T{ ' * ' defer3 DEFER! -> }T
T{ 2 3 defer3 -> 6 }T

T{ ' + ' defer3 DEFER! -> }T
T{ 1 2 defer3 -> 3 }T

ContributeContributions

TG9541avatar of TG9541 [186] Does the standard assume that DEFER was created with CREATE? Request for clarification2021-04-14 17:41:19

The Implementation part of DEFER@ is as follows:

Implementation:
: DEFER@ ( xt1 -- xt2 )
   >BODY @ ;

This is surprising as >BODY states the following:

>BODY
( xt -- a-addr )

a-addr is the data-field address corresponding to xt. An ambiguous condition exists if xt is not for a word defined via CREATE.

This question is relevant for STM8 eForth, an STC system, since >BODY wouldn't work with anything created by DEFER.

AntonErtlavatar of AntonErtl

This reference implementation is designed to work with the reference implementation of DEFER, which uses CREATE. Actually the reference implementations of these two words and a few more were originally proposed as a unit.

Implementations (including reference implementations) usually have additional properties beyond the specified and intended behaviour, and this is an example.

Closed

ruvavatar of ruv

Does the standard assume that DEFER was created with CREATE?

A short answer: the standard does not require a system to implement DEFER via CREATE. A consequence is that a standard program cannot assume that >BODY is applied to xt of a word that is created with DEFER, or that DOES> can change its behavior.

TG9541avatar of TG9541

I've seen the part about examples being non-normative. I'm closing this now. Thanks for your work!

Closed
Reply New Version