?EXEC

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>cmFORTH did use the wordlists for independent interpretation and
>>>compilation semantics, but indeed not for IF and DO. There were
>>>compiling versions of a bunch of things, like this:
>>>
>>>FORTH : BINARY ( n) CREATE , DOES R> @ ?CODE @ DUP
>>> ... lots ... ;
>>>
>>>COMPILER A840 BINARY + AA40 BINARY XOR A640 BINARY OR
>>> AC40 BINARY - A240 BINARY AND A440 BINARY SWAP-
>>>
>>>FORTH
>>>
>>>... much later ...
>>>
>>>: SWAP SWAP ; : OVER OVER ;
>>>: DUP DUP ; : DROP DROP ;
>>>: XOR XOR ; : AND AND ;
>>>: OR OR ;
>>>: + + ; : - - ;
>>
>> That's just an unusual implementation of default compilation
>> semantics, but it's not really independent interpretation and
>> compilation semantics.
>
>I don't understand what you mean.

These are normal Forth words (words with default compilation
semantics). With "independent interpretation and compilation
semantics" I mean things like S", where the interpretation semantics
puts the string in a buffer, and the compilation semantics compiles it
as string literal.

Of course, the separate compilation wordlist is capable of
implementing both, but apparently Chuck Moore chose not to do the
"independent interpretation and compilation semantics" thing. And
given all the complications that follow from that, I think he was
right.

- 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 2012: http://www.euroforth.org/ef12/

Albert van der Horst <albert@spenarnc.xs4all.nl> writes:
[interpretation semantics for DO]

>It is just that my class
>extension doesn't work properly without it.

Why not? What's so bad about defining a :NONAME word and running it
(maybe with some code-memory management wrapped around that)?
Especially given that you claim that even a simple compile-only flag
(and the check for it in the text interpreter) adds too much
complexity for your taste.

- 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 2012: http://www.euroforth.org/ef12/

Albert van der Horst <albert@spenarnc.xs4all.nl> writes:
>In article <2012Jun19.175328@mips.complang.tuwien.ac.at>,
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>Albert van der Horst <albert@spenarnc.xs4all.nl> writes:
>>>So if I was wary about a program being standard w.r.t. to IF
>>> I could load a preamble.
>>>-----------
>>>: IF STATE @ 0=
>>> ABORT" NONPORTABLE: interpretation semantics of IF is undefined"
>>> POSTPONE IF ; IMMEDIATE
>>>-----------
>>>
>>>and it would only sift out nonportable programs.
>>
>>After this definition the system is non-standard and would fail for
>>some standard programs. That's because your redefined IF has
>>compilation semantics that fail in interpret state.
>
>Apparently I miss the point here. Can you give an example where
>such a preamble would spoil the cake?

: gen-foo ... postpone if ... ;
: bla ... [ 5 gen-foo s" hi" gen-bar ] ... ;

- 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 2012: http://www.euroforth.org/ef12/

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>>cmFORTH did use the wordlists for independent interpretation and
>>>>compilation semantics, but indeed not for IF and DO. There were
>>>>compiling versions of a bunch of things, like this:
>>>>
>>>>FORTH : BINARY ( n) CREATE , DOES R> @ ?CODE @ DUP
>>>> ... lots ... ;
>>>>
>>>>COMPILER A840 BINARY + AA40 BINARY XOR A640 BINARY OR
>>>> AC40 BINARY - A240 BINARY AND A440 BINARY SWAP-
>>>>
>>>>FORTH
>>>>
>>>>... much later ...
>>>>
>>>>: SWAP SWAP ; : OVER OVER ;
>>>>: DUP DUP ; : DROP DROP ;
>>>>: XOR XOR ; : AND AND ;
>>>>: OR OR ;
>>>>: + + ; : - - ;
>>>
>>> That's just an unusual implementation of default compilation
>>> semantics, but it's not really independent interpretation and
>>> compilation semantics.
>>
>>I don't understand what you mean.
>
> These are normal Forth words (words with default compilation
> semantics).

In what sense? The COMPILER versions lay down instructions, the FORTH
versions call them. They are different words, with different
semantics, i.e. they do different things.

> With "independent interpretation and compilation semantics" I mean
> things like S", where the interpretation semantics puts the string
> in a buffer, and the compilation semantics compiles it as string
> literal.

How is the above different? I really don't understand what point
you're making.

Andrew.

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>>>cmFORTH did use the wordlists for independent interpretation and
>>>>>compilation semantics, but indeed not for IF and DO. There were
>>>>>compiling versions of a bunch of things, like this:
>>>>>
>>>>>FORTH : BINARY ( n) CREATE , DOES R> @ ?CODE @ DUP
>>>>> ... lots ... ;
>>>>>
>>>>>COMPILER A840 BINARY + AA40 BINARY XOR A640 BINARY OR
>>>>> AC40 BINARY - A240 BINARY AND A440 BINARY SWAP-
>>>>>
>>>>>FORTH
>>>>>
>>>>>... much later ...
>>>>>
>>>>>: SWAP SWAP ; : OVER OVER ;
>>>>>: DUP DUP ; : DROP DROP ;
>>>>>: XOR XOR ; : AND AND ;
>>>>>: OR OR ;
>>>>>: + + ; : - - ;
>>>>
>>>> That's just an unusual implementation of default compilation
>>>> semantics, but it's not really independent interpretation and
>>>> compilation semantics.
>>>
>>>I don't understand what you mean.
>>
>> These are normal Forth words (words with default compilation
>> semantics).
>
>In what sense? The COMPILER versions lay down instructions, the FORTH
>versions call them. They are different words, with different
>semantics, i.e. they do different things.

Sure, the default compilation semantics of a normal Forth word are
different from the default interpretation semantics (the default
compilation semantics compiles the execution semantics, the default
interpretation semantics performs it; in a more conventional
implementation the default compilation semantics COMPILE,s the xt of
the word, whereas the default interpretation semantics EXECUTEs the
xt.

The point is that these words implement the default semantics. +
behaves like a normal Forth word; no immediacy, no other non-default
compilation semantics. This normality is also reflected in the
definition

: + + ;

He doesn't define compile-only words like IF or immediate words like (
like this, nor would that work for S" and TO.

>> With "independent interpretation and compilation semantics" I mean
>> things like S", where the interpretation semantics puts the string
>> in a buffer, and the compilation semantics compiles it as string
>> literal.
>
>How is the above different? I really don't understand what point
>you're making.

The definition of + etc. above is just an unusual *implementation* of
the default semantics. + behaves as specified in the standard (even
though cmForth does not aspire to being a standard system), and + in
the standard is a normal word (i.e., only default compilation and
interpretation semantics).

One difference is that

: S" S" ;

is not a valid implementation of the interpretation semantics of S".

If I still have not made myself clear: Implementation is not
semantics. Semantics is what is visible from the outside (black-box
view). Implementation is how it is done (white-box view). The same
semantics can (and often does) have several different implementations.
E.g.:

: 2* 2 * ;
: 2* 1 lshift ;
: 2* dup + ;

On a 2s-complement system all these definitions implement the same
semantics (those specified in the standard for 2*).

- 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 2012: http://www.euroforth.org/ef12/

On Jun 20, 7:09*am, an...@mips.complang.tuwien.ac.at (Anton Ertl)
wrote:
> Albert van der Horst <alb...@spenarnc.xs4all.nl> writes:
>
>
>
>
>
>
>
>
>
> >In article <2012Jun19.175...@mips.complang.tuwien.ac.at>,
> >Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
> >>Albert van der Horst <alb...@spenarnc.xs4all.nl> writes:
> >>>So if I was wary about a program being standard w.r.t. to IF
> >>> I could load a *preamble.
> >>>-----------
> >>>: IF * *STATE @ 0=
> >>> * *ABORT" NONPORTABLE: interpretation semantics of IF is undefined"
> >>> * *POSTPONE IF ; IMMEDIATE
> >>>-----------
>
> >>>and it would only sift out nonportable programs.
>
> >>After this definition the system is non-standard and would fail for
> >>some standard programs. *That's because your redefined IF has
> >>compilation semantics that fail in interpret state.
>
> >Apparently I miss the point here. Can you give an example where
> >such a preamble would spoil the cake?
>
> : gen-foo ... postpone if ... ;
> : bla ... [ 5 gen-foo s" hi" gen-bar ] ... ;

So if source is trying, while interpreting, to perform the compilation
semantics of a word that doesn't necessarily have interpretation
behavior, that will be problematic?

Or, IOW, its problematic for source code with an implementation
dependency on a word containing postponed compilation semantics
functioning in interpretation state.

BruceMcF <agila61@netscape.net> writes:
>On Jun 20, 7:09=A0am, an...@mips.complang.tuwien.ac.at (Anton Ertl)
>wrote:
>> Albert van der Horst <alb...@spenarnc.xs4all.nl> writes:
>> >Apparently I miss the point here. Can you give an example where
>> >such a preamble would spoil the cake?
>>
>> : gen-foo ... postpone if ... ;
>> : bla ... [ 5 gen-foo s" hi" gen-bar ] ... ;
>
>So if source is trying, while interpreting, to perform the compilation
>semantics of a word that doesn't necessarily have interpretation
>behavior, that will be problematic?

I am not sure what your question is, but the issue is about performing
compilation semantics in interpret state. An implementation of IF
containing ?COMP (or equivalent, like Albert's preamble) will fail
then, while it will likely work if the ?COMP is removed.

That's the general problem with STATE-smart words: they check STATE at
run-time instead of at parse time. It works when the word is
text-interpreted directly (because then the run-time is performed
right after parsing), but it can fail if the run-time is delayed by
ticking or POSTPONEing (or [COMPILE]ing).

- 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 2012: http://www.euroforth.org/ef12/

In article <2012Jun20.130929@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>Albert van der Horst <albert@spenarnc.xs4all.nl> writes:
>>In article <2012Jun19.175328@mips.complang.tuwien.ac.at>,
>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>Albert van der Horst <albert@spenarnc.xs4all.nl> writes:
>>>>So if I was wary about a program being standard w.r.t. to IF
>>>> I could load a preamble.
>>>>-----------
>>>>: IF STATE @ 0=
>>>> ABORT" NONPORTABLE: interpretation semantics of IF is undefined"
>>>> POSTPONE IF ; IMMEDIATE
>>>>-----------
>>>>
>>>>and it would only sift out nonportable programs.
>>>
>>>After this definition the system is non-standard and would fail for
>>>some standard programs. That's because your redefined IF has
>>>compilation semantics that fail in interpret state.
>>
>>Apparently I miss the point here. Can you give an example where
>>such a preamble would spoil the cake?
>
>: gen-foo ... postpone if ... ;
>: bla ... [ 5 gen-foo s" hi" gen-bar ] ... ;

I see. For the moment I think the following is best.

I leave ?COMP in but in the rare case that some one would do the
above:

- program doesn't compile
- double check: "Hey it is intentional"
- WANT NO-SECURITY NO-SECURITY

As far as I remember even the GNU c-compiler is only fully
compliant with the -pedantic option.
In Forth the equivalent is
REQUIRE pedantic

To answer your question in the other thread:
I must have either ?COMP or an interpreted IF DO ,

otherwise
"
1 \ size
class ARRAY
M: limit @ M; DUP ,
0 DO 0 , LOOP
endclass
"
goes wrong without a message and without an indication.

>
>- anton

Groetjes Albert

--
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

Elizabeth D. Rather wrote:
> ...
> I don't advocate banning ?COMP. I just think it's silly. And making CODE
> etc. IMMEDIATE just so you can issue an error message in case of blatant
> silliness is doubly silly.
>
> As I've said elsewhere, I support the "intelligent programmer,
> permissive compiler" theory of programming. I can think of several
> reasons for using : and END-CODE in definitions, somewhat fewer for
> CODE, but I see no advantage to making them immediate unless you fancy
> yourself a programming nanny, in which case maybe Forth is not for you.

And presumably most forth implementors including MPE by
implication!

?COMP ?EXEC was part of Fig's compiler security package.
Given compiler security is all about catching unlikely things,
it was not unreasonable.

If making CODE END-CODE immediate was a bad move,
then I'm sure those affected would like to hear about it, even
after all this time. Do you have practical examples to make
the case?

As regards ?COMP it is the more useful and has been used
for two things - to prevent inadvertent execution of conditionals
from corrupting memory, and/or to pinpoint errors early.

In SwiftForth inadvertent execution of BEGIN in immediate
mode results in an OK message. Is it "Ok" ? Most forth
implementations including commercials don't agree it is.

No, I don't fancy myself as a "programming nanny". In fact my
system uses less syntax checking than most. I could remove
the four ?COMPs currently present and my system would
still be protected. I don't mind spending the 35 bytes plus
header it costs for the additional warning ?COMP provides.
Who knows, even SwiftForth users might like it

On Tuesday, 19 June 2012 15:09:44 UTC+1, Anton Ertl wrote:
> Albert van der Horst <albert@spenarnc.xs4all.nl> writes:
> >I feel that adding interpreted use of IF and DO is much more useful
> >then other smartness.
>
> If you want to add interpretation semantics for IF and DO, then go
> ahead. But don't produce STATE-smart IF and DO; for simple cases they
> work as desired, but for more complex cases they sometimes fail.
> Instead, if you want that stuff, bite the bullet and implement one of
> the schemes for doing that properly.
>
> My feeling, though, is that in the balance it's a bad idea to have
> such words. Not only do you have to implement one of the schemes
> above, but you also have repercussions elsewhere (like the meaning of
> xts and how to reify the interpretation and compilation semantics).
>

It may be a bad idea, but it's even worse to have a bad idea, badly executed. Since people insist doing such things, shouldn't there be a clear way ofshowing their meaning without mixing up interpretation and compilation behaviour in the one definition?

The simplest way I can think of is:

COMPILES xt -- set most recent definition to perform xt
at compile-time

IMMEDIATE may (or may not) be defined as LATESTXT COMPILES

COMPILES may be implemented either by extending FIND when compiling to return the compiling xt and an immediate flag, or by a smart COMPILE, to perform the appropriate action for the given xt. In the latter case, IMMEDIATE should be defined so that immediate words return an immediate flag, but that is mainly of historical interest. Consider for example this definition of POSTPONE :

FIND DUP IF immediate? IF COMPILE, ELSE
postpone LITERAL ['] COMPILE, COMPILE, THEN
ELSE

will still work as expected with a smart compiler if IMMEDIATE is defined as above, whichever flag is returned.

When interpreting, the xt returned by FIND must represent interpretation behaviour, and the flag is irrelevant. When compiling, an immediate flag indicates that the xt represents compiling behaviour, otherwise it represents interpreting behaviour. ' and ['] always return the interpreting behaviour.

There is a simple, portable way to get an xt that represents the compiling behaviour of any particular word:

: 'COMP :NONAME POSTPONE POSTPONE POSTPONE ; ;

STATE-checking words return the appropriate behaviour, but only if the xt returned is finally executed in the appropriate state.


: THROWS CREATE , DOES> @ THROW ;

-14 THROWS COMP-ONLY
-29 THROWS CAN'T-NEST

: CODE interpretation behaviour ; compiles can't-nest

: compDO compilation behaviour of DO ;
: DO comp-only ; compiles compDO

Or, later

'comp DO
: DO interpretation-version ; compiles

In article <jru388$iqb$1@speranza.aioe.org>, Ed <invalid@nospam.com> wrote:
>Elizabeth D. Rather wrote:
>> ...
>> I don't advocate banning ?COMP. I just think it's silly. And making CODE
>> etc. IMMEDIATE just so you can issue an error message in case of blatant
>> silliness is doubly silly.
>>
>> As I've said elsewhere, I support the "intelligent programmer,
>> permissive compiler" theory of programming. I can think of several
>> reasons for using : and END-CODE in definitions, somewhat fewer for
>> CODE, but I see no advantage to making them immediate unless you fancy
>> yourself a programming nanny, in which case maybe Forth is not for you.
>
>And presumably most forth implementors including MPE by
>implication!
>
>?COMP ?EXEC was part of Fig's compiler security package.
>Given compiler security is all about catching unlikely things,
>it was not unreasonable.
>
>If making CODE END-CODE immediate was a bad move,
>then I'm sure those affected would like to hear about it, even
>after all this time. Do you have practical examples to make
>the case?
>
>As regards ?COMP it is the more useful and has been used
>for two things - to prevent inadvertent execution of conditionals
>from corrupting memory, and/or to pinpoint errors early.
>
>In SwiftForth inadvertent execution of BEGIN in immediate
>mode results in an OK message. Is it "Ok" ? Most forth
>implementations including commercials don't agree it is.
>
>No, I don't fancy myself as a "programming nanny". In fact my
>system uses less syntax checking than most. I could remove
>the four ?COMPs currently present and my system would
>still be protected. I don't mind spending the 35 bytes plus
>header it costs for the additional warning ?COMP provides.
>Who knows, even SwiftForth users might like it

I think this is a good presentation of the trade offs.
It helps me to decide what I want to do with ciforth.

For ciforth I want ?COMP in. It catches lots of typos.

Using ?EXEC and making defining words IMMEDIATE can prevent
a situation that is extremely puzzling to a novice:

: def1 ....
DROP \ note missing semicolon
: def2 ...
;
\ Point A
.....
much later
.....
: def3 ...... def2 .....
^^^^
Not found.

The problem is that an error is signalled at a much later time.
If the novice doesn't panic he discovers that at Point A
`` def2 '' is not defined. Then the bug is found soon enough.
The second time the novice (and even I myself) finds the
mistake immediately^H^H^H^H^H^H^H much faster.

On the other side the consequence is to always having to do
POSTPONE : .
One tends to forget that : is IMMEDIATE , because there
seems no good reason to do so, so this too leads to errors
(but those are signalled at the spot and easily corrected.)

Given that ciforth is simplistic and not very user
friendly to begin with, I'm not going to make all defining
words immediate and will not used ?EXEC.


--
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

On Jun 21, 10:00*am, Albert van der Horst <alb...@spenarnc.xs4all.nl>
wrote:
> On the other side the consequence is to always having to do
> POSTPONE : .

Which makes it impossible to run standard source that compiles : to
execute at runtime. Forth94 : *has* default compilation semantics, so
an implementation with ?EXEC in : is not a Forth94 implementation.

Albert van der Horst <albert@spenarnc.xs4all.nl> writes:
>Using ?EXEC and making defining words IMMEDIATE can prevent
>a situation that is extremely puzzling to a novice:
>
>: def1 ....
> DROP \ note missing semicolon
>: def2 ...
^^^ Not found
>;
>\ Point A
>....
>much later
>....
>: def3 ...... def2 .....
> ^^^^
> Not found.
>
>The problem is that an error is signalled at a much later time.

It's usually signaled right after the defining word. I have inserted
this "not found" message in the example above.

>On the other side the consequence is to always having to do
>POSTPONE : .

Better use [COMPILE] :. That works on standard systems, too.

- 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 2012: http://www.euroforth.org/ef12/

JennyB <jennybrien@googlemail.com> writes:
>On Tuesday, 19 June 2012 15:09:44 UTC+1, Anton Ertl wrote:
>> If you want to add interpretation semantics for IF and DO, then go
>> ahead. But don't produce STATE-smart IF and DO; for simple cases they
>> work as desired, but for more complex cases they sometimes fail.
>> Instead, if you want that stuff, bite the bullet and implement one of
>> the schemes for doing that properly.
>>=20
>> My feeling, though, is that in the balance it's a bad idea to have
>> such words. Not only do you have to implement one of the schemes
>> above, but you also have repercussions elsewhere (like the meaning of
>> xts and how to reify the interpretation and compilation semantics).
>>=20
>
>It may be a bad idea, but it's even worse to have a bad idea, badly execute=
>d. Since people insist doing such things, shouldn't there be a clear way of=
> showing their meaning without mixing up interpretation and compilation beh=
>aviour in the one definition?
>
>The simplest way I can think of is:
>
> COMPILES xt -- set most recent definition to perform xt=20
> at compile-time
>
>IMMEDIATE may (or may not) be defined as LATESTXT COMPILES=20
>
>COMPILES may be implemented either by extending FIND when compiling to retu=
>rn the compiling xt and an immediate flag

Yes, that's a possibility, but it's pretty ugly: basically FIND now
has STATE as additional parameter and may deliver completely different
results based in this parameter. I know that it's ugly because that's
what Gforth's FIND does.

It's better to have separate words for producing an xt for the
interpretation semantics and something (either an xt or xt1 xt2) for
the compilation semantics.

>or by a smart COMPILE, to perfor=
>m the appropriate action for the given xt.

That's a broken "COMPILE,", not a smart one. A properly working
"COMPILE," compiles the same semantics that EXECUTE performs. That
would not be the case if "COMPILE," performs the compilation semantics
(of, e.g., S") whereas EXECUTE performs the interpretation/execution
semantics.

- 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 2012: http://www.euroforth.org/ef12/

"Ed" <invalid@nospam.com> writes:
>If making CODE END-CODE immediate was a bad move,
>then I'm sure those affected would like to hear about it, even
>after all this time. Do you have practical examples to make
>the case?

I don't use CODE, but fig-Forth also made : immediate with ?EXEC.
This means that you cannot just use : inside a colon definition to get
a defining word. Instead, you have to [COMPILE] :. And that's what I
did in the first release of Gray. A bit later Marcel Hendrix ported
Gray to his Forth (not sure if it was iForth at the time); he saw the
[COMPILE] and converted it to POSTPONE. Since his : was not
immediate, this did not achieve what was intended ([COMPILE] would
have been ok).

>As regards ?COMP it is the more useful and has been used
>for two things - to prevent inadvertent execution of conditionals
>from corrupting memory, and/or to pinpoint errors early.

There are much better approaches for achieving this.

>I don't mind spending the 35 bytes plus
>header it costs for the additional warning ?COMP provides.

I think you can have a proper solution for similar cost.

- 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 2012: http://www.euroforth.org/ef12/