Poll: Behavior of [compile]

[Ruvim]

If your Forth system provides the "[COMPILE]" word,
what does the following tests print?

Test 1

:NONAME 1 . [COMPILE] EXIT 2 . ; EXECUTE

Test 2

: EXIT ." (EXIT) " POSTPONE EXIT ; IMMEDIATE
:NONAME 1 . [COMPILE] EXIT 2 . ; EXECUTE



--
Ruvim

[Anton Ertl]

I tried it on Gforth (0.7.2 and 0.7.9_20210415), iForth, SwiftForth,
and VFX, and they all printed:

Test1: 1
Test2: 1 (EXIT) 2

And this is as specified in the standard.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2020: https://euro.theforth.net/2020

[Ruvim]

On 2021-04-22 19:09, Anton Ertl wrote:
> Ruvim <ruvim...@gmail.com> writes:
>> If your Forth system provides the "[COMPILE]" word,
>> what does the following tests print?
>>
>> Test 1
>>
>> :NONAME 1 . [COMPILE] EXIT 2 . ; EXECUTE
>>
>> Test 2
>>
>> : EXIT ." (EXIT) " POSTPONE EXIT ; IMMEDIATE
>> :NONAME 1 . [COMPILE] EXIT 2 . ; EXECUTE
>
> I tried it on Gforth (0.7.2 and 0.7.9_20210415), iForth, SwiftForth,
> and VFX, and they all printed:
>
> Test1: 1
> Test2: 1 (EXIT) 2
>
> And this is as specified in the standard.

Yes.

But the problem is that if you redefine EXIT, you are forced to redefine
[COMPILE] too in some cumbersome way. It's also true for any word that
has default compilation semantics and undefined interpretation semantics
by the Forth-94 standard. This class of words is very arguable, since
there is no a standard way to redefine a word of this class and keep its
class.


I also checked SP-Forth 4.21, lxf\ntf 2017, minForth 3.4, ikForth 20.04,
VFX Forth 5.11, — the results:

Test1: 1 2
Test2: 1 (EXIT) 2



So, a rule of thumb:

1. As a system implementer, remove the already obsolescent [COMPILE]
word from your system to don't support a bad practice (and especially if
your provide a non-standard implementation).

2. As a user, if you redefine any non ordinal word, also redefine
[COMPILE] (it it exists) to just throw an exception.

[defined] [compile] [if]
: [compile] 1 abort" [compile] is not supported" ; immediate
[then]


--
Ruvim

[Ruvim]

On 2021-04-22 22:03, Ruvim wrote:
> On 2021-04-22 19:09, Anton Ertl wrote:
>> Ruvim <ruvim...@gmail.com> writes:

[...]

> So, a rule of thumb:
>
>  1. As a system implementer, remove the already obsolescent [COMPILE]
> word from your system to don't support a bad practice (and especially if
> your provide a non-standard implementation).
>
>  2. As a user, if you redefine any non ordinal word, also redefine
> [COMPILE] (it it exists) to just throw an exception.

Typo: if you redefine any non ordinary word

[minf...@arcor.de]

The current standard notes that [COMPILE] "is obsolescent and a concession
to existing implementations".

Extract from the existing Forth-79 standard:
[COMPILE] I,C,179 "bracket-compile"
Used in a colon-definition in the form:
[COMPILE] <name>
Forces compilation of the following word. This allows
compilation of an IMMEDIATE word when it would otherwise be
executed.

IOW the current standard 6.2.2530 changed the definition of [COMPILE].
It cannot be ruling, the situation is ambiguous.

[dxforth]

DX-Forth

Test 1: 1
Test 2: 1 (EXIT) Error: compilation only

[dxforth]

ANS may have re-worded the definition. To 'change' a definition and
declare it 'obsolete' is anachronistic. I have difficultly understanding
what ANS is talking about at the best of times.

[Anton Ertl]

Looks like is it a discerning test for one of the corner cases of the
standard. The VFX version I tested is 4.72, so VFX shows a regression
here.

>So, a rule of thumb:
>
> 1. As a system implementer, remove the already obsolescent [COMPILE]
>word from your system to don't support a bad practice (and especially if
>your provide a non-standard implementation).

Yes, a good solution.

> 2. As a user, if you redefine any non ordinal word, also redefine
>[COMPILE] (it it exists) to just throw an exception.
>
> [defined] [compile] [if]
> : [compile] 1 abort" [compile] is not supported" ; immediate
> [then]

That's a way to do it, (another is to redefine [compile] to
special-case the redefined word), but given that a number of systems
have implemented broken [COMPILE]s without users reporting problems
(probably because nobody uses [COMPILE] EXIT and the like), another
way is to just document that word X has been redefined in a way that
[COMPILE] does no longer work correctly with it.

[minf...@arcor.de]

It is even "worse". Forth-94 broke current practice here.

Forth-79 and Forth-83 stated that [COMPILE] __forces__ compilation of the following
word.

Forth-94 took away that __forces__ and changed it into some 'appending semantics'.
But [COMPILE] is not just another POSTPONE.

But 'so what'. There is no standard Forth reference implementation and
the test suite does not cover this case. You can roll your own.

[Ruvim]

On 2021-04-23 07:16, dxforth wrote:
> On 23/04/2021 06:53, minf...@arcor.de wrote:

[...]

>>
>> The current standard notes that [COMPILE] "is obsolescent and a
>> concession to existing implementations"
>>

>> Extract from the existing Forth-79 standard:
>> [COMPILE]                                I,C,179  "bracket-compile"
>>       Used in a colon-definition in the form:
>>            [COMPILE] <name>
>>       Forces  compilation  of  the  following  word.    This  allows
>>       compilation  of  an IMMEDIATE word when it would otherwise  be
>>       executed.

It looks like the problem was in Forth-83 too, where EXIT also cannot be
redefined transparently.

In Forth-83, EXIT was a non immediate word for compilation only. But
after redefinition it becomes an immediate word, e.g.:

: EXIT COMPILE X COMPILE EXIT ; IMMEDIATE


So before redefinition
COMPILE EXIT

is equivalent to

[COMPILE] EXIT

after redefinition.

>>
>> IOW the current standard 6.2.2530 changed the definition of [COMPILE].
>> It cannot be ruling, the situation is ambiguous. >
> ANS may have re-worded the definition.  To 'change' a definition and
> declare it 'obsolete' is anachronistic.

In Forth-94 it is not obsolescent. It is obsolescent in Forth-2012
(actually since 2014).
See also: http://www.forth200x.org/meetings/2014-notes

> I have difficultly understanding
> what ANS is talking about at the best of times.
>

--
Ruvim

[Anton Ertl]

Forth-94 changed almost all words to have unknown immediacy, and
defined [COMPILE] in a way that is appropriate for that setting and
compatible with existing uses of [COMPILE]. I don't remember many
discussions about [COMPILE] apart from those from people like Ruvim
and me who pointed out corner cases, so the Forth-94 definition of
[COMPILE] seems to be good enough. And as you point out, Forth-2012
has made [COMPILE] obsolescent (and it's CORE EXT and therefore
optional anyway).

[dxforth]

On 23/04/2021 16:53, Ruvim wrote:
> On 2021-04-23 07:16, dxforth wrote:
>> On 23/04/2021 06:53, minf...@arcor.de wrote:
> [...]
>>>
>>> The current standard notes that [COMPILE] "is obsolescent and a
>>> concession to existing implementations"
>>>
>>> Extract from the existing Forth-79 standard:
>>> [COMPILE]                                I,C,179  "bracket-compile"
>>>       Used in a colon-definition in the form:
>>>            [COMPILE] <name>
>>>       Forces  compilation  of  the  following  word.    This  allows
>>>       compilation  of  an IMMEDIATE word when it would otherwise  be
>>>       executed.
>
>
> It looks like the problem was in Forth-83 too, where EXIT also cannot be
> redefined transparently.
>
> In Forth-83, EXIT was a non immediate word for compilation only. But
> after redefinition it becomes an immediate word, e.g.:
>
> : EXIT COMPILE X COMPILE EXIT ; IMMEDIATE
>
>
> So before redefinition
> COMPILE EXIT
>
> is equivalent to
>
> [COMPILE] EXIT
>
> after redefinition.

Overloading EXIT is a mistake I won't make again :)

>
>
>
>>>
>>> IOW the current standard 6.2.2530 changed the definition of [COMPILE].
>>> It cannot be ruling, the situation is ambiguous. >
>> ANS may have re-worded the definition.  To 'change' a definition and
>> declare it 'obsolete' is anachronistic.
>
> In Forth-94 it is not obsolescent. It is obsolescent in Forth-2012
> (actually since 2014).
> See also: http://www.forth200x.org/meetings/2014-notes

My bad. ANS promoted POSTPONE to Core and demoted '83 [COMPILE] to CORE EXT.

[Stephen Pelc]

On Thu, 22 Apr 2021 18:47:44 +0300, Ruvim <ruvim...@gmail.com>
wrote:

>If your Forth system provides the "[COMPILE]" word,
>what does the following tests print?

VFX Forth for Windows x86
© MicroProcessor Engineering Ltd, 1998-2020

Version: 5.11 [build 3793]
Build date: 21 October 2020

Free dictionary = 7472078 bytes [7296kb]


:NONAME 1 . [COMPILE] EXIT 2 . ; EXECUTE 1 2 ok

: EXIT ." (EXIT) " POSTPONE EXIT ; IMMEDIATE

EXIT is redefined ok
:NONAME 1 . [COMPILE] EXIT 2 . ; EXECUTE 1 (EXIT) 2 ok

Stephen


--
Stephen Pelc, ste...@vfxforth.com <<< NEW
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, +44 (0)78 0390 3612, +34 649 662 974
web: http://www.mpeforth.com - free VFX Forth downloads

[Ruvim]

If you implement a profiler, a stack balance checker, a tracer, or
something alike, you probably need to redefine EXIT. And such a module
should be transparent for other libraries or programs.

But if, by any chance, a standard program uses [COMPILE] EXIT —
preloading of your module will produce a deep strange bug.

OTOH, if a program uses the phrase [COMPILE] EXIT — this program
probably assumes non-default compilation semantics for EXIT (and then
it's a non standard program), since otherwise such use doesn't have much
sense.

So I suggest to tight the specification for [COMPILE] and allow to apply
this word to the only words that have non default compilation semantics.
Rationale: standard programs almost never apply [COMPILE] to the words
with default compilation semantics.

Or even better, let's exclude this word from the standard, and then a
standard program cannot use [COMPILE] anymore at all.

>>>> IOW the current standard 6.2.2530 changed the definition of [COMPILE].
>>>> It cannot be ruling, the situation is ambiguous.
>>> ANS may have re-worded the definition.  To 'change' a definition and
>>> declare it 'obsolete' is anachronistic.
>>
>> In Forth-94 it is not obsolescent. It is obsolescent in Forth-2012
>> (actually since 2014).
>> See also: http://www.forth200x.org/meetings/2014-notes
>
> My bad.  ANS promoted POSTPONE to Core and demoted '83 [COMPILE] to CORE
> EXT.

--
Ruvim

[Stephen Pelc]

On Thu, 22 Apr 2021 23:50:05 -0700 (PDT), "minf...@arcor.de"
<minf...@arcor.de> wrote:

>> I have difficultly understanding
>> what ANS is talking about at the best of times.
>
>It is even "worse". Forth-94 broke current practice here.
>
>Forth-79 and Forth-83 stated that [COMPILE] __forces__ compilation of the following
>word.
>
>Forth-94 took away that __forces__ and changed it into some 'appending semantics'.
>But [COMPILE] is not just another POSTPONE.
>
>But 'so what'. There is no standard Forth reference implementation and
>the test suite does not cover this case. You can roll your own.

Actually, it's mostly the fault of native code compilers and
"non-default compilation semantics" issues. Forth-200x declared
[COMPILE] obsolescent maainly because nobody really cared any
more. During my attempts to understand the ANS description of
compilation in Forth, [COMPILE] became useful again by enabling
systems to distinguish between normal, immediate and NDCS words.

IMHO resolution of [COMPILE] needs to wait until we sort out
the NDCS issues. For example, at present all IMMEDIATE words
are NDCS, but, depending on implementation, not all NDCS words
are immediate. See the VFX Forth source code (with all
distributions) for the details. In addition, one of my
EuroForth papers discusses the thinking:
https://www.mpeforth.com/resource-links/downloads/

[none albert]

The use case here is "someone tries to debug EXIT uses".

[COMPILE] is obsolent so there must be a better way to do
that.


>--
>Ruvim

Groetjes Albert
--
"in our communism country Viet Nam, people are forced to be
alive and in the western country like US, people are free to
die from Covid 19 lol" duc ha
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[Stephen Pelc]

On Fri, 23 Apr 2021 12:50:42 +0300, Ruvim <ruvim...@gmail.com>
wrote:

>OTOH, if a program uses the phrase [COMPILE] EXIT — this program
>probably assumes non-default compilation semantics for EXIT (and then
>it's a non standard program), since otherwise such use doesn't have much
>sense.
>
>So I suggest to tight the specification for [COMPILE] and allow to apply
>this word to the only words that have non default compilation semantics.
>Rationale: standard programs almost never apply [COMPILE] to the words
>with default compilation semantics.
>
>Or even better, let's exclude this word from the standard, and then a
>standard program cannot use [COMPILE] anymore at all.

A sound idea, but now you have to propose the words needed to deal
with NDCS words (non default compilation semantics). This needs to be
done before [COMPILE] can be withdrawn again.

Redefining the meaning of a word without changing its name is a recipe

for disaster.

[Anton Ertl]

Ruvim <ruvim...@gmail.com> writes:
>Or even better, let's exclude this word from the standard, and then a
>standard program cannot use [COMPILE] anymore at all.

Forth-2012 already declares [COMPILE] obsolescent, which means that we
plan to destandardize this word in the next standard. But you could
propose destandardizing the obsolescent words now, rather than waiting
for us to do it at the last moment, like we did with the obsolescent
Forth-94 words for Forth-2012.

[Ruvim]

On 2021-04-23 13:06, Stephen Pelc wrote:
> On Fri, 23 Apr 2021 12:50:42 +0300, Ruvim <ruvim...@gmail.com>
> wrote:
>
>> OTOH, if a program uses the phrase [COMPILE] EXIT — this program
>> probably assumes non-default compilation semantics for EXIT (and then
>> it's a non standard program), since otherwise such use doesn't have much
>> sense.
>>
>> So I suggest to tight the specification for [COMPILE] and allow to apply
>> this word to the only words that have non default compilation semantics.
>> Rationale: standard programs almost never apply [COMPILE] to the words
>> with default compilation semantics.
>>
>> Or even better, let's exclude this word from the standard, and then a
>> standard program cannot use [COMPILE] anymore at all.
>
> A sound idea, but now you have to propose the words needed to deal
> with NDCS words (non default compilation semantics). This needs to be
> done before [COMPILE] can be withdrawn again.

POSTPONE is a valid replacement for [COMPILE] — they behave identically
for NDCS words.

What do we need else?

>
> Redefining the meaning of a word without changing its name is a recipe
> for disaster.

Certainly!

Just to clarify, making the specification for a word more tight doesn't
change meaning of the word.

And when EXIT is redefined in my examples — the meaning of EXIT is not
changed too.



--
Ruvim

[Ruvim]

On 2021-04-23 12:55, Stephen Pelc wrote:

> Forth-200x declared [COMPILE] obsolescent maainly because nobody
> really cared any more.
>
> During my attempts to understand the ANS description of
> compilation in Forth, [COMPILE] became useful again by enabling
> systems to distinguish between normal, immediate and NDCS words.

Could you please elaborate on how can [COMPILE] be useful to distinguish
these kinds of words?

> IMHO resolution of [COMPILE] needs to wait until we sort out
> the NDCS issues.


> For example, at present all IMMEDIATE words are NDCS,
> but, depending on implementation, not all NDCS words
> are immediate.

True. But why it's an issue?

From the point of view of a standard program these differences are
mostly invisible. We have some edge cases but they are very rare in
practice and actually ambiguous.


--
Ruvim

[Anton Ertl]

ste...@mpeforth.com (Stephen Pelc) writes:
>A sound idea, but now you have to propose the words needed to deal
>with NDCS words (non default compilation semantics). This needs to be
>done before [COMPILE] can be withdrawn again.

[COMPILE] does nothing for NDCS words that POSTPONE does not do, too:

|[COMPILE]
|
|Interpretation: Interpretation semantics for this word are undefined.
|
|Compilation: ( "<spaces>name" -- )
|
|Skip leading space delimiters. Parse name delimited by a space. Find
|name. If name has other than default compilation semantics, append
|them to the current definition [...]
|
|POSTPONE
|
|Interpretation: Interpretation semantics for this word are undefined.
|
|Compilation: ( "<spaces>name" -- )
|
|Skip leading space delimiters. Parse name delimited by a space. Find
|name. Append the compilation semantics of name to the current
|definition.

POSTPONE has been in the standard, it does not need to be proposed.
[COMPILE] was never withdrawn, so it cannot be withdrawn *again*. It
is obsolescent since Forth-2012, however.

If you think that [COMPILE] has helped you to understand NDCS words,
it apparently has misled you, because Ruvim's test shows that while
VFX 4.72 implements [COMPILE] EXIT correctly, VFX 5.11 does not.

>Redefining the meaning of a word without changing its name is a recipe
>
>for disaster.

Sure, but what is the relevance of that for the present discussion?

[dxforth]

On 23/04/2021 21:16, Ruvim wrote:
> ...

> And when EXIT is redefined in my examples — the meaning of EXIT is not
> changed too.

Only the behaviour and characteristics have changed.

[NN]

In test1, during compilation, [compile] compiles the exit. During execution,
the exit , halts the word hence 2 is not printed

In test2 , during compilation [compile] is compiling the redefined exit.
redefined exit prints (exit) and compiles exit using postpone. its marked
immediate because we want it to execute during compilation.
so when the anonymous word is executed, it prints 1 and then (exit) but
because exit is the last word it just exiting itself and not the definition where
it was called. So when it returns 2 gets printed.

Is this correct ?

[dxforth]

IMO test2 is ambiguous - compiling while in interpret mode.

[dxforth]

Come to think of it, so is test1.

[P Falth]

In the standard EXIT has default compilation semantics.
[COMPILE] for a word with default compilation semantics just compiles a call to that words

In a compliant system Test1 is equivalent of

:NONAME 1 . EXIT 2 . ; EXECUTE

The definition will exit before 2 . is reached
In my systems (and many others) EXIT is immediate
In that case [COMPILE] will do as POSTPONE and compile a call to EXIT
When the :noname definition is executed EXIT will compile its payload
in a non existing definition, probably at here.

In TEST2 a new immediate EXIT is created. The POSTPONE EXIT will place
a call to EXIT in the code and when that is later executed will compile the
EXIT payload into the non existing definition.

These examples show the short comings of both [COMPILE] and EXIT

With [COMPILE] you need to know if the word following is immediate or not

Many systems define EXIT as an immediate word which is non standard

Both my systems fail this test. I am not going to fix that. I might consider
removing [COMPILE]. I never use it. POSTPONE does all that is needed.

BR
Peter

[NN]

On Saturday, 24 April 2021 at 07:07:04 UTC+1, P Falth wrote:
> On Saturday, 24 April 2021 at 00:19:49 UTC+2, NN wrote:
> > On Thursday, 22 April 2021 at 16:47:47 UTC+1, Ruvim wrote:
> > > If your Forth system provides the "[COMPILE]" word,
> > > what does the following tests print?
> > >
> > > Test 1
> > >
> > > :NONAME 1 . [COMPILE] EXIT 2 . ; EXECUTE
> > >
> > > Test 2
> > >
> > > : EXIT ." (EXIT) " POSTPONE EXIT ; IMMEDIATE
> > > :NONAME 1 . [COMPILE] EXIT 2 . ; EXECUTE
> > >
> > >
> > >
> > > --
> > > Ruvim
> > In test1, during compilation, [compile] compiles the exit. During execution,
> > the exit , halts the word hence 2 is not printed
> >
> > In test2 , during compilation [compile] is compiling the redefined exit.
> > redefined exit prints (exit) and compiles exit using postpone. its marked
> > immediate because we want it to execute during compilation.
> > so when the anonymous word is executed, it prints 1 and then (exit) but
> > because exit is the last word it just exiting itself and not the definition where

> > it was called. So when it returns 2 gets printed. : test postpone exit ; immediate ok
:noname 1 . test 2 . ; execute 1 ok

> >
> > Is this correct ?
> In the standard EXIT has default compilation semantics.
> [COMPILE] for a word with default compilation semantics just compiles a call to that words
>
> In a compliant system Test1 is equivalent of
>
> :NONAME 1 . EXIT 2 . ; EXECUTE
>
> The definition will exit before 2 . is reached
> In my systems (and many others) EXIT is immediate
> In that case [COMPILE] will do as POSTPONE and compile a call to EXIT
> When the :noname definition is executed EXIT will compile its payload
> in a non existing definition, probably at here.
>
> In TEST2 a new immediate EXIT is created. The POSTPONE EXIT will place
> a call to EXIT in the code and when that is later executed will compile the
> EXIT payload into the non existing definition.
>
> These examples show the short comings of both [COMPILE] and EXIT
>
> With [COMPILE] you need to know if the word following is immediate or not
>
> Many systems define EXIT as an immediate word which is non standard
>
> Both my systems fail this test. I am not going to fix that. I might consider
> removing [COMPILE]. I never use it. POSTPONE does all that is needed.
>
> BR
> Peter

Thank you Peter


So when I did :-

:noname 1 . [compile] exit 2 . ; execute 1 ok
:noname 1 . postpone exit 2 . ; execute 1 2 ok

postpone is compiling into a non-existant definition at the time I run it...

So in order to get same behaviour I need to introduce a new definition and remove the [compile]

: test ." (test) " postpone exit ; immediate ok
:noname 1 . test 2 . ; execute (test) 1 ok


And in test2 , the [compile] is not necessary

: exit ." (exit1) " postpone exit ." (exit2) " ; immediate redefined EXIT with exit ok
:noname 1 . [compile] exit 2 . ; execute 1 (exit1) (exit2) 2 ok

Hence 1 and 2 get printed

But upon removing the [compile]

:noname 1 . exit 2 . ; execute (exit1) (exit2) 1 ok

And (exit1) (exit2) get printed when the noname definition is being compiled which
is why the 1 is after and not before.

Waiting for the next curve ball :)

[dxforth]

On 24/04/2021 16:07, P Falth wrote:
> ...

> Many systems define EXIT as an immediate word which is non standard

That doesn't sound right. Unlike '79 and '83 which required EXIT to
be non-immediate, ANS was all about accommodation. ANS would have been
aware of the 'many systems' for whom an immediate EXIT was a necessity.
Excluding them wasn't in their best interest.

Win32Forth: a 32 Bit Forth for Windows 95/98/ME/NT4/W2K/XP/VISTA/W7/W8/W10
Version: 6.15.05 Build: 2

\ Test1

:NONAME 1 . [COMPILE] EXIT 2 . ; EXECUTE

^^^^
Warning(-4101): EXIT is a system word in an application word 1
^^^^^^^
Error(-14): EXECUTE is compilation only

[Stephen Pelc]

On Fri, 23 Apr 2021 15:48:35 +0300, Ruvim <ruvim...@gmail.com>
wrote:

>Could you please elaborate on how can [COMPILE] be useful to distinguish
>these kinds of words?

It's more that if one can distinguish betwee these words, e.g.
using NDCS? (xt -- flag) and IMMEDIATE? (xt -- flag), then one
can handle them correctly. It then becomes possible to implement
S" and friends correctly and without complexity or state-smart
words.

>> For example, at present all IMMEDIATE words are NDCS,
>> but, depending on implementation, not all NDCS words
>> are immediate.
>
>True. But why it's an issue?

S" S/" and friends.

> From the point of view of a standard program these differences are
>mostly invisible. We have some edge cases but they are very rare in
>practice and actually ambiguous.

There are people who like counting the number of angels dancing on
the head of a pin ... I'm not one of them.

[Stephen Pelc]

On Sat, 24 Apr 2021 13:14:07 GMT, ste...@mpeforth.com (Stephen Pelc)
wrote:

>>True. But why it's an issue?
>
>S" S/" and friends.
>

Extending the point about S" S\" and friends. From time to time one
wants more type of quoted words and may want them to be interpretable
like S". Similarly, interpreted control structures have been proposed
from time to time. These all fell because with the tools of the time,
they had to be state-smart.

With proper tools for NDCS words, these words can be written in
standard-compliant form.

Anything that extends Forth's ability to write new notations is
a good thing IMHO.

Stephen


--
Stephen Pelc, ste...@vfxforth.com

[Ruvim]

On 2021-04-24 01:19, NN wrote:
> On Thursday, 22 April 2021 at 16:47:47 UTC+1, Ruvim wrote:
>> If your Forth system provides the "[COMPILE]" word,
>> what does the following tests print?
>>
>> Test 1
>>
>> :NONAME 1 . [COMPILE] EXIT 2 . ; EXECUTE
>>
>> Test 2
>>
>> : EXIT ." (EXIT) " POSTPONE EXIT ; IMMEDIATE
>> :NONAME 1 . [COMPILE] EXIT 2 . ; EXECUTE
>>
>>
>>
>> --
>> Ruvim
>
>
>
> In test1, during compilation, [compile] compiles the exit. During execution,
> the exit , halts the word hence 2 is not printed

Correct.

> In test2 , during compilation [compile] is compiling the redefined exit.
> redefined exit prints (exit) and compiles exit using postpone. its marked
> immediate because we want it to execute during compilation.
> so when the anonymous word is executed, it prints 1 and then (exit)

> but because exit is the last word it just exiting itself

This step is incorrect. It prints "(EXIT)" and then performs the
execution semantics of the original EXIT, i.e. it appends the execution
semantics of the original EXIT to the current definition.

The current definition is absent at that moment, so this action is
ambiguous. Also this action is ambiguous since the compilation semantics
are performed in interpretation state (if POSTPONE does not guarantee
compilation state during performing compilation semantics).

Many systems just generate the corresponding code in the current
position of code space. Some systems raise an error. Any from these is
allowed by the standard.

> and not the definition where
> it was called. So when it returns 2 gets printed.

So it generates some code, and then prints 2.

>
> Is this correct ?



--
Ruvim

[Ruvim]

My conclusion is that EXIT may be implemented as an immediate word,
since a standard program cannot detect that it's an immediate word.

Nether xt from Tick (if any), nor xt from FIND cannot be considered as
the execution token for EXIT since interpretation semantics are not
defined for EXIT.

So from a user point of view, it's a problem solely of [COMPILE]

>
> Both my systems fail this test. I am not going to fix that. I might consider
> removing [COMPILE]. I never use it. POSTPONE does all that is needed.

--
Ruvim

[P Falth]

I think FIND should be able to return an xt and flag in compilation mode.
And from the flag you can see if it is immediate or not.

But I agree with your conclusion an immediate EXIT should be OK as in
practical use the behavior is the same. And the standard has been inclusive
of different implementation techniques.

BR
Peter

[minf...@arcor.de]

It would be better to get rid of UNLOOP than to finetune EXIT for rare esoteric use cases.

[Ruvim]

On 2021-04-24 21:54, P Falth wrote:
> On Saturday, 24 April 2021 at 18:49:15 UTC+2, Ruvim wrote:
>> On 2021-04-24 09:07, P Falth wrote:

[...]

>>> Many systems define EXIT as an immediate word which is non standard
>> My conclusion is that EXIT may be implemented as an immediate word,
>> since a standard program cannot detect that it's an immediate word.
>>
>> Nether xt from Tick (if any), nor xt from FIND cannot be considered as

typo: neither one *can* be considered as ...

>> the execution token for EXIT since interpretation semantics are not
>> defined for EXIT.


> I think FIND should be able to return an xt and flag in compilation mode.
> And from the flag you can see if it is immediate or not.

First of all, the specification for FIND has a number of flaws (we try
to make it better). And it's a known issue that actually this flag
doesn't mean immediacy in the standard notion in all the cases. The
standard notion of immediacy is:

| immediate word: A Forth word whose compilation
| semantics are to perform its execution semantics.

It means that if you know the execution token xt of an immediate word,
you can perform compilation semantics for this word by applying EXECUTE
to this xt in compilation state. And nothing more.

(NB: by Anton's interpretation, to perform these compilation semantics
you can apply EXECUTE to this xt in interpretation state as well as in
compilation state, but the results may be different.)



Definitely, if a word is immediate, then FIND returns flag=1. But the
opposite is not true: flag=1 does not mean that the word is immediate.


FIND is allowed to return 1 in compilation state for any word (e.g. for
DUP), to implement optimization. Hence, if flag=1 in compilation state,
then xt does not mean the execution token for this word (e.g. xt of DUP).

Hence, flag=1 for EXIT in compilation state doesn't mean that EXIT is
immediate, and the returned xt cannot be used as the execution token of
EXIT.



The next step.

The standard doesn't prohibit to implement any word as an immediate
word, if this implementation meets the specification for this word.

So if a glossary entry doesn't say that a word is immediate, it doesn't
mean that the word is certainly not immediate. This word may still be an
immediate word. E.g. TO can be implemented as in immediate word.



Fortunately, implementing EXIT as an immediate word meets the
specification for EXIT.

Since interpretation semantics are undefined for EXIT, a program is not
allowed to apply Tick to EXIT or use FIND to get execution token of EXIT.

So even if FIND returns some xt for EXIT in interpretation state, a
program cannot use this xt as the execution token of EXIT, regardless of
the flag.

So nothing prohibit us to implement EXIT as an immediate word.

> But I agree with your conclusion an immediate EXIT should be OK as in
> practical use the behavior is the same.

It should be OK, and it is actually OK.

> And the standard has been inclusive of different implementation techniques.

True.


--
Ruvim

[Ruvim]

On 2021-04-24 19:38, Ruvim wrote:
> On 2021-04-24 01:19, NN wrote:
>> On Thursday, 22 April 2021 at 16:47:47 UTC+1, Ruvim wrote:
>>> If your Forth system provides the "[COMPILE]" word,
>>> what does the following tests print?
>>>
>>> Test 1
>>>
>>> :NONAME 1 . [COMPILE] EXIT 2 . ; EXECUTE
>>>
>>> Test 2
>>>
>>> : EXIT ." (EXIT) " POSTPONE EXIT ; IMMEDIATE
>>> :NONAME 1 . [COMPILE] EXIT 2 . ; EXECUTE
>>>
>>
>>

>> In test1, during compilation, [compile] compiles the exit. During
>> execution,
>> the exit , halts the word hence 2 is not printed
>
> Correct.
>
>> In test2 , during compilation [compile] is compiling the redefined exit.
>> redefined exit prints (exit) and compiles exit using postpone. its marked
>> immediate because we want it to execute during compilation.
>> so when the anonymous word is executed, it prints 1 and then (exit)
>
>> but because exit is the last word it just exiting itself
>
> This step is incorrect. It prints "(EXIT)" and then performs the
> execution semantics of the original EXIT,

typo: it performs _compilation_ semantics of the original EXIT,

> i.e. it appends the execution
> semantics of the original EXIT to the current definition.
>
> The current definition is absent at that moment, so this action is
> ambiguous. Also this action is ambiguous since the compilation semantics
> are performed in interpretation state (if POSTPONE does not guarantee
> compilation state during performing compilation semantics).
>
> Many systems just generate the corresponding code in the current
> position of code space. Some systems raise an error. Any from these is
> allowed by the standard.
>

--
Ruvim

[Ruvim]

On 2021-04-24 19:35, Stephen Pelc wrote:
> On Sat, 24 Apr 2021 13:14:07 GMT, ste...@mpeforth.com (Stephen Pelc)
> wrote:
>
>>> True. But why it's an issue?
>>
>> S" S/" and friends.
>>
>
> Extending the point about S" S\" and friends. From time to time one
> wants more type of quoted words and may want them to be interpretable
> like S". Similarly, interpreted control structures have been proposed
> from time to time. These all fell because with the tools of the time,
> they had to be state-smart.

Could you provide an example of such a tool?


In any case, I have another view on this.


If you implement some tool (i.e. a word) with "state-smart" property,
you don't have any problem just because of this property, when you use
this word directly — i.e., when this word is encountered by the Forth
text interpreter.

You can only face a problem when you apply Tick or POSTPONE to this
word. Most probably, POSTPONE.

The reason is that you expect that POSTPONE guarantees compilation state
when the appended compilation semantics are performed. But your POSTPONE
doesn't guarantee that.

And the standard doesn't guarantees that. And according to the
clarifications, you may perform compilation semantics only in
compilation state (even if these semantics are a part of execution
semantics by means of POSTPONE).


So why not to just implement POSTPONE in such a way in your system to
meet the expectation?

>
> With proper tools for NDCS words, these words can be written in
> standard-compliant form.

Yet another tool for NDCS words is Recognizer API.

It provides you a way to create a word that POSTPONE or Tick are not
applicable to at all.

>
> Anything that extends Forth's ability to write new notations is
> a good thing IMHO.

--
Ruvim

[dxforth]

On 25/04/2021 04:54, P Falth wrote:
> ...

> But I agree with your conclusion an immediate EXIT should be OK as in
> practical use the behavior is the same. And the standard has been inclusive
> of different implementation techniques.

'Practical use' for me is having assembler access a non-immediate EXIT.
The paper ANS used to cover over differences between systems is cracking.
Calls for a word to identify immediacy another quickly applied band-aid.
One could draw parallels between a seaworthy ship and a model sitting in
a glass bottle.

[Anton Ertl]

Ruvim <ruvim...@gmail.com> writes:
>If you implement some tool (i.e. a word) with "state-smart" property,
>you don't have any problem just because of this property, when you use
>this word directly — i.e., when this word is encountered by the Forth
>text interpreter.

The implementor of a state-smart word has no problem. The users of a
state-smart word sometimes have problems.

>You can only face a problem when you apply Tick or POSTPONE to this
>word. Most probably, POSTPONE.

Also with tick and [COMPILE].
<http://www.complang.tuwien.ac.at/forth/dpans-html/a0007.htm> mentions
tick and [COMPILE].

>The reason is that you expect that POSTPONE guarantees compilation state
>when the appended compilation semantics are performed. But your POSTPONE
>doesn't guarantee that.
>
>And the standard doesn't guarantees that. And according to the
>clarifications, you may perform compilation semantics only in
>compilation state (even if these semantics are a part of execution
>semantics by means of POSTPONE).

Which clarifications?

I have certainly performed compilation semantics in interpret state,
and I have seen code posted by others that performs compilation
semantics in interpret state. There is no good reason to disallow it.

>So why not to just implement POSTPONE in such a way in your system to
>meet the expectation?

No common practice (actually no practice that I am aware of). Does
not solve the ticking problem. And we have better ways that solve
both ticking and POSTPONEing of S". Those that don't want to adopt
these ways typically think that the problems of state-smart S" are of
no practical concern and don't merit any effort at solving them (and
apparently not even the effort of proposing that ticking and
POSTPONEing S" become non-standard).

>Yet another tool for NDCS words is Recognizer API.
>
>It provides you a way to create a word that POSTPONE or Tick are not
>applicable to at all.

Actually the recognizer proposal is designed to allow POSTPONEing (but
not ticking) recognized things. In particular, you can

POSTPONE "bla"

whereas you cannot

POSTPONE S" bla"

[minf...@arcor.de]

I think that nails it down. S" is just okay enough for simple string handling.
For more intense text stream processing, dynamic strings are nearly a must
have. So postoning S" et al are more of academic interest.

[dxforth]

This from J. Noble's FTRAN program:

: C"
postpone s" func postpone literal postpone pack ; immediate

I guess one could call that 'academic' :)

[Stephen Pelc]

On Sun, 25 Apr 2021 02:16:45 +0300, Ruvim <ruvim...@gmail.com>
wrote:

>> Extending the point about S" S\" and friends. From time to time one
>> wants more type of quoted words and may want them to be interpretable
>> like S". Similarly, interpreted control structures have been proposed
>> from time to time. These all fell because with the tools of the time,
>> they had to be state-smart.
>
>Could you provide an example of such a tool?

: S" \ Comp: "ccc<quote>" -- ; Run: -- c-addr u
\ *G Describe a string. Text is taken up to the next double-quote
\ ** character. The address and length of the string are returned.
[char] " parse >syspad \ SFP058
;
ndcs: ( -- ) discard-sinline compile (s") ", ;

: DO \ Run: n1|u1 n2|u2 -- ; R: -- loop-sys ; 6.1.1240
\ *G Begin a *\fo{DO ... LOOP} construct. Takes the end-value and
\ ** start-value from the stack.
NoInterp ;
ndcs: ( -- ) s_do, 3 ;

If you want an interpreted version of DO replace NOINTERP by the
required code.

[Hugh Aguilar]

On Saturday, April 24, 2021 at 2:08:45 PM UTC-7, Ruvim wrote:
> On 2021-04-24 21:54, P Falth wrote:
> > On Saturday, 24 April 2021 at 18:49:15 UTC+2, Ruvim wrote:
> >> On 2021-04-24 09:07, P Falth wrote:
> [...]
> >>> Many systems define EXIT as an immediate word which is non standard
> >> My conclusion is that EXIT may be implemented as an immediate word,
> >> since a standard program cannot detect that it's an immediate word.

ANS-Forth fails to define whether standard words are immediate or not.
All of the standard words are ambiguous because they can be one way or the other!
[COMPILE] is for immediate words, so it should not be in ANS-Forth because
the words may be immediate or non-immediate, so [COMPILE] may or may not work.

> So nothing prohibit us to implement EXIT as an immediate word.

Congratulations!!! You have just invented the disamiguifiers!
Here is EXIT as an immediate word (does not matter if it was immediate or
non-immediate out-of-the-box, it is not ambiguous now):

: exit
state @ 0= abort" *** no interpretation semantics for: EXIT ***"
postpone exit
; immediate

Note that this is different from the disambiguifier for IF provided earlier:

: if
state @ 0= if cr ." WARNING: *** no interpretation semantics for: IF ***" cr then
postpone if
; immediate

The difference is that the EXIT disambiguifier aborts when used in interpretation mode
and the IF disambiguifier just gives a warning --- this is because IF could be reasonably
used inside of [ ] brackets but EXIT can not.

[Hugh Aguilar]

On Saturday, April 24, 2021 at 9:35:26 AM UTC-7, Stephen Pelc wrote:
> With proper tools for NDCS words, these words can be written in
> standard-compliant form.

Stephen Pelc doesn't know how to program in ANS-Forth.

This is why he blathers on about NDCS and calls it "standard-compliant."
This is not ANS-Forth. Stephen Pelc doesn't know how to program in ANS-Forth.
This is just some idiotic nonsense that Stephen Pelc is making up,
and everything that he makes up he claims is "standard-compliant" by fiat.

[dxforth]

On 25/04/2021 18:32, Anton Ertl wrote:
> ...

> The implementor of a state-smart word has no problem. The users of a
> state-smart word sometimes have problems.

As opposed to every user having a problem with S" because ANS couldn't
get those who claimed to support a standard to agree on one behaviour.
What did those who replaced state-smart with dual-xt imagine would
happen - that everybody would roll over and things would be hunky-dory?
How far away is Forth Inc from rolling over? Next year, next decade?
When your 'standard' and Forth has all the time in the world, it hardly
matters.

[Ruvim]

On 2021-04-25 11:32, Anton Ertl wrote:
> Ruvim <ruvim...@gmail.com> writes:
>> If you implement some tool (i.e. a word) with "state-smart" property,
>> you don't have any problem just because of this property, when you use
>> this word directly — i.e., when this word is encountered by the Forth
>> text interpreter.
>
> The implementor of a state-smart word has no problem. The users of a
> state-smart word sometimes have problems.
>
>> You can only face a problem when you apply Tick or POSTPONE to this
>> word. Most probably, POSTPONE.
>
> Also with tick and [COMPILE].

After the recent discussion about [COMPILE], I suggest to forget the
[COMPILE] word and never mention this word as an argument anymore :-)

> <http://www.complang.tuwien.ac.at/forth/dpans-html/a0007.htm> mentions
> tick and [COMPILE].

This A0007 clarification shows (proves) that a standard *ordinary* word
(a word with default interpretation semantics and default compilation
semantics) cannot be implemented as in immediate word.

It's true, and nobody suggest such a thing for ordinary words.


But we talks about words that are *not ordinary*. So A0007 is not
relevant to our case.


Among non ordinary words, Tick is applicable to the only words that are
known to be immediate (the exception concerning S" is debated), and it
works as expected. So we don't have any problem with Tick, I think.

>> The reason is that you expect that POSTPONE guarantees compilation state
>> when the appended compilation semantics are performed. But your POSTPONE
>> doesn't guarantee that.
>>
>> And the standard doesn't guarantees that. And according to the
>> clarifications, you may perform compilation semantics only in
>> compilation state (even if these semantics are a part of execution
>> semantics by means of POSTPONE).
>
> Which clarifications?

You should know, it was discussed many times. It's the official reply to
RFI by Philip Preston, Q99-027 [1,2]


The question was concerning correctness of the following propositions:

1. It is an ambiguous condition for a program to perform compilation
semantics in the interpretation state.

2. It is an ambiguous condition for a program to append semantics to the
current definition in the interpretation state.

TC Reply to Q99-027
The answer to question (1.) is Yes.
The answer to question (2.) is Yes.


The grounds for this decision are clear to me now.

The model of a standard Forth system is an abstraction over many
different implementations (see also the section C.4 of the standard,
concerning "inclusive nature of the standard").

Therefore the standard allows such implementations of some standard
words, and such implementations of immediate user defined words, that
it's just impossible to perform compilation semantics in interpretation
state in some cases.

And hence, a standard program, to work on any allowed implementation,
should fit all of them in the same time.


For example, the standard allows to implement "COMPILE," as the following

: compile, ( xt -- )
state @ if xt, exit then -14 throw ;

\ -14 "interpreting a compile-only word"

It's obvious that in such a system even the default compilation
semantics cannot be performed in interpretation state.

> I have certainly performed compilation semantics in interpret state,
> and I have seen code posted by others that performs compilation
> semantics in interpret state.

And what?

It works as expected in some conditions, and doesn't work in other
conditions. And it's why it's ambiguous. And some examples when it
doesn't work as expected were shown by me too.

> There is no good reason to disallow it.

It was always disallowed for a standard program since Forth-94.

But I think, we can allow it (and standardize) in some cases, by
eliminating ambiguity (and with guarantee of the same results).

>> So why not to just implement POSTPONE in such a way in your system to
>> meet the expectation?
>
> No common practice (actually no practice that I am aware of).

If some approach can be only implemented when it has common practice,
nothing new will be ever implemented.

OTOH, I implement POSTPONE in this way.

> Does not solve the ticking problem.

> And we have better ways

> that solve both ticking and POSTPONEing of S".

I don't see any problem with S"

See my point concerning expected and actual behaviour of POSTPONE

Concerning ticking S" — I proved that your interpretation is incorrect
(at lest, you didn't answer anything yet).

> Those that don't want to adopt these ways typically think that
> the problems of state-smart S" are of no practical concern and
> don't merit any effort at solving them



> (and apparently not even the effort of proposing that ticking and
> POSTPONEing S" become non-standard).

You know, there is a proposal that makes ticking S" non-standard via
introducing a general rule.



Concerning applying POSTPONE to S" — my point is that is should remain
standard, and the current exclusions re POSTPONE should be removed.
POSTPONE should be applicable to any word with defined compilation
semantics.

>> Yet another tool for NDCS words is Recognizer API.
>>
>> It provides you a way to create a word that POSTPONE or Tick are not
>> applicable to at all.
>
> Actually the recognizer proposal is designed to allow POSTPONEing (but
> not ticking) recognized things. In particular, you can
>
> POSTPONE "bla"
>
> whereas you cannot
>
> POSTPONE S" bla"

But you can

POSTPONE S"

It impossible to make POSTPONE applicable to both 'S"' and 'S" bla"'





[1] http://forth.sourceforge.net/standard/dpans/a99-027.htm

[2]
https://groups.google.com/forum/message/raw?msg=comp.lang.forth/RmsDuen7YkY/xDvW74uzi30J


--
Ruvim

[none albert]

In article <s664n9$b7i$1...@dont-email.me>, Ruvim <ruvim...@gmail.com> wrote:
>On 2021-04-25 11:32, Anton Ertl wrote:
>> Ruvim <ruvim...@gmail.com> writes:
>>> If you implement some tool (i.e. a word) with "state-smart" property,
>>> you don't have any problem just because of this property, when you use
>>> this word directly — i.e., when this word is encountered by the Forth
>>> text interpreter.
>>
>> The implementor of a state-smart word has no problem. The users of a
>> state-smart word sometimes have problems.
>>
>>> You can only face a problem when you apply Tick or POSTPONE to this
>>> word. Most probably, POSTPONE.
>>
>> Also with tick and [COMPILE].
>
>After the recent discussion about [COMPILE], I suggest to forget the
>[COMPILE] word and never mention this word as an argument anymore :-)
>
>
>> <http://www.complang.tuwien.ac.at/forth/dpans-html/a0007.htm> mentions
>> tick and [COMPILE].
>
>This A0007 clarification shows (proves) that a standard *ordinary* word
>(a word with default interpretation semantics and default compilation
>semantics) cannot be implemented as in immediate word.
>
>It's true, and nobody suggest such a thing for ordinary words.

I'm puzzled. I consider .S an ordinary word. Now suppose I want to
have a .S' that prints the stack during compilation , so
'S. ALIAS .S' IMMEDIATE
: test .S' 1 2 3 ;
shows that nothing is on the data stack during compilation.

Now what is strange, cannot be implemented, not ordinary,
whatever about .S' ?
(Unless you define ordinary as "not immediate" ).

>
>--
>Ruvim
Groetjes Albert
--
"in our communism country Viet Nam, people are forced to be
alive and in the western country like US, people are free to
die from Covid 19 lol" duc ha
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[Mark Wills]

On Thursday, April 22, 2021 at 5:12:51 PM UTC+1, Anton Ertl wrote:
> Ruvim <ruvim...@gmail.com> writes:

> >If your Forth system provides the "[COMPILE]" word,
> >what does the following tests print?
> >
> >Test 1
> >
> > :NONAME 1 . [COMPILE] EXIT 2 . ; EXECUTE
> >
> >Test 2
> >
> > : EXIT ." (EXIT) " POSTPONE EXIT ; IMMEDIATE
> > :NONAME 1 . [COMPILE] EXIT 2 . ; EXECUTE

> I tried it on Gforth (0.7.2 and 0.7.9_20210415), iForth, SwiftForth,
> and VFX, and they all printed:
>
> Test1: 1
> Test2: 1 (EXIT) 2
>
> And this is as specified in the standard.

>
> - anton
> --
> M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
> comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
> New standard: http://www.forth200x.org/forth200x.html
> EuroForth 2020: https://euro.theforth.net/2020

Same for TurboForth on the vintage TI-99/4A (FWIW).

[Ruvim]

On 2021-04-26 14:48, albert wrote:
> In article <s664n9$b7i$1...@dont-email.me>, Ruvim <ruvim...@gmail.com> wrote:
>> On 2021-04-25 11:32, Anton Ertl wrote:
>>> <http://www.complang.tuwien.ac.at/forth/dpans-html/a0007.htm> mentions
>>> tick and [COMPILE].
>>
>> This A0007 clarification shows (proves) that a standard *ordinary* word
>> (a word with default interpretation semantics and default compilation
>> semantics) cannot be implemented as in immediate word.
>>
>> It's true, and nobody suggest such a thing for ordinary words.
>
> I'm puzzled. I consider .S an ordinary word. Now suppose I want to
> have a .S' that prints the stack during compilation , so
> 'S. ALIAS .S' IMMEDIATE
> : test .S' 1 2 3 ;
> shows that nothing is on the data stack during compilation.
>
> Now what is strange, cannot be implemented, not ordinary,
> whatever about .S' ?

Nothing.

The words S. and .S' are just not equivalent.

If two words are operationally equivalent, you can replace one by
another in *any* correct program, and the result will be the same.


Concerning these two words, they have the same execution semantics, the
same interpretation semantics, but the different compilation semantics.



--
Ruvim

[dxforth]

But what exactly has it done? If it has silently compiled in
interpret mode, it is 'standard' only to the extent ANS doesn't
compel systems to issue -14 THROW. They may carry on as if
nothing illegal occurred.

Does TurboForth implement POSTPONE via COMPILE ? If so, adding
?COMP to COMPILE provides the missing error check. As a bonus,
attempting to use POSTPONE or COMPILE in immediate mode won't
crash the system as typically occurred in legacy systems (F83,
LMI PC/FORTH etc).

[dxforth]

Examples of IF used in interpretation mode?

[Mark Wills]

I had to check the source as it's been a while - but yes - it uses COMPILE internally.

[Hugh Aguilar]

POSTPONE uses FIND to obtain the xt and the flag indicating if the word is
immediate or non-immediate, in which case it uses [COMPILE] or COMPILE
respectively --- this was commonly done in Forth-83 --- ANS-Forth just standardized
the name POSTPONE that varied from implementation to implementation previously.