?EXEC

I find places where ?EXEC is used. This gives an error because a word
if a word is executed while it never should.

Examples are CODE and END-CODE in an assembler, but does this make
sense?

: CODE ?EXEC .... ;
: END-CODE ?EXEC .... ;

By analogy I see I defined my classes like this:
: class ?EXEC ... ;
: end-class ?EXEC ... ;

I find it hard to wrap my head around this. In what kind of situation
would this error trigger?
I would be equally happy with some other realistic example.

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

Albert van der Horst wrote:
> I find places where ?EXEC is used. This gives an error because a word
> if a word is executed while it never should.
>
> Examples are CODE and END-CODE in an assembler, but does this make
> sense?
>
> : CODE ?EXEC .... ;
> : END-CODE ?EXEC .... ;
>
> By analogy I see I defined my classes like this:
> : class ?EXEC ... ;
> : end-class ?EXEC ... ;
>
> I find it hard to wrap my head around this. In what kind of situation
> would this error trigger?
> I would be equally happy with some other realistic example.

Possibly there is none.

?EXEC was a companion function to ?COMP. These were part
of the "compiler security" package introduced by Fig-Forth and
copied by just about everyone (except notably Forth Inc.)

Whether Forth needed the level compiler security provided by
Fig-Forth was questioned in the article "Compiler Security"
G.Shaw, FD 3/1.

I note in my own sources I use ?EXEC in CODE END-CODE
LABEL - which were all IMMEDIATE. I can't recall ever using or
needing this feature.

On Jun 15, 4:40*pm, Albert van der Horst <alb...@spenarnc.xs4all.nl>
wrote:
> I find places where ?EXEC is used. This gives an error because a word
> if a word is executed while it never should.

"because a word if a word is executed while it never should." ?

.... seems to be mangled. What is the actual condition that is supposed
to trigger the error? Ed notes that its a fig-Forthism, and its been
several decades since I knew the fig Forth model in any detail.

>
> Examples are CODE and END-CODE in an assembler, but does this make
> sense?
>
> : CODE ?EXEC .... ;
> : END-CODE ?EXEC .... ;
>
> By analogy I see I defined my classes like this:
> : class ?EXEC ... ;
> : end-class ?EXEC ... ;
>
> I find it hard to wrap my head around this. In what kind of situation
> would this error trigger?
> I would be equally happy with some other realistic example.

In article <b445b94c-64c5-4773-be56-ee8c75f24f4d@h10g2000yqn.googlegroups.com>,
BruceMcF <agila61@netscape.net> wrote:
>On Jun 15, 4:40=A0pm, Albert van der Horst <alb...@spenarnc.xs4all.nl>
>wrote:
>> I find places where ?EXEC is used. This gives an error because a word
>> if a word is executed while it never should.
>
>"because a word if a word is executed while it never should." ?
>
>... seems to be mangled. What is the actual condition that is supposed
>to trigger the error? Ed notes that its a fig-Forthism, and its been
>several decades since I knew the fig Forth model in any detail.

Sorry. I put too much trust in my spell checker ;-)
Maybe just this:
"
SEE ?EXEC

: ?EXEC
STATE @ 12 ?ERROR
;
"
?ERROR is THROW with some decoration.

>
>>
>> Examples are CODE and END-CODE in an assembler, but does this make
>> sense?
>>
>> : CODE ?EXEC .... ;
>> : END-CODE ?EXEC .... ;
>>
>> By analogy I see I defined my classes like this:
>> : class ?EXEC ... ;
>> : end-class ?EXEC ... ;
>>
>> I find it hard to wrap my head around this. In what kind of situation
>> would this error trigger?
>> I would be equally happy with some other realistic example.
>
>

I just discovered that having ?COMP in IF and DO is useful.

I had a bug in a class definition because I forgot that the build
code is run in interpret mode. Took me an hour to realize what
was going on. Maybe I should load the interpreted IF's and DO's
standard with the class tool, but certainly I will add the ?COMP.

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

Albert van der Horst wrote:
> ...
> I just discovered that having ?COMP in IF and DO is useful.
>
> I had a bug in a class definition because I forgot that the build
> code is run in interpret mode. Took me an hour to realize what
> was going on. Maybe I should load the interpreted IF's and DO's
> standard with the class tool, but certainly I will add the ?COMP.

How often do you make such errors

?COMP is a convenience that can alert one to silly errors
sooner, but like ?EXEC the times it is useful will be rare.
To this day SwiftForth has no ?COMP.

OTOH providing ?COMP is cheap and it turns out only 4
are necessary to cover all the standard structures IF ELSE
THEN AHEAD BEGIN WHILE REPEAT UNTIL DO LOOP
CASE etc.

Albert van der Horst <albert@spenarnc.xs4all.nl> writes:
>I just discovered that having ?COMP in IF and DO is useful.

No, it's the plague. It turns nicely working words into STATE-smart
crap. ?COMP (like all STATE-smart words) tests STATE at run-time,
whereas what is wanted is to have a check at parsing time (and that's
the same for all STATE-smart words).

If you want to protect against using IF and DO interpretively, add a
compile-only flag to the header, and let the text interpreter check
it. For more complicated cases (words that can be used
interpretively, but behave differently), there are a number of good
implementation approaches (checking STATE at run-time is not one of
them).

- 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:
>I find places where ?EXEC is used. This gives an error because a word
>if a word is executed while it never should.
>
>Examples are CODE and END-CODE in an assembler, but does this make
>sense?
>
>: CODE ?EXEC .... ;
>: END-CODE ?EXEC .... ;

Hardly. It makes a little more sense if CODE and END-CODE are
immediate. I guess the idea is to protect the porgrammer against

: foo
... \ missing ";"

code bar
...

And of course in fig-Forth also ":" was immediate and contained a
?EXEC.

For defining words we usually get an error when the name of the word
to be defined is seen; ok, the error is not as descriptive as the one
produced by ?EXEC, but programmers learn to interpret it pretty fast.

And the disadvantages are pretty bad: First, if you want to include
CODE (or ":") in another word, you have to use [COMPILE] or POSTPONE
(note that standard CODE and : don't need this). Worse, that word
becomes STATE-smart; if you tick it and then happen to EXECUTE the xt
in compile STATE, you get an error, pretty removed from the cause of
the whole thing.

Overall, ?EXEC is a bad idea, like ?COMP and STATE-smart words in
general.

- 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 16, 11:01*pm, Albert van der Horst <alb...@spenarnc.xs4all.nl>
wrote:
> In article <b445b94c-64c5-4773-be56-ee8c75f24...@h10g2000yqn.googlegroups..com>,
>
> BruceMcF *<agil...@netscape.net> wrote:
> >On Jun 15, 4:40=A0pm, Albert van der Horst <alb...@spenarnc.xs4all.nl>
> >wrote:
> >> I find places where ?EXEC is used. This gives an error because a word
> >> if a word is executed while it never should.
>
> >"because a word if a word is executed while it never should." ?
>
> >... seems to be mangled. What is the actual condition that is supposed
> >to trigger the error? Ed notes that its a fig-Forthism, and its been
> >several decades since I knew the fig Forth model in any detail.
>
> Sorry. I put too much trust in my spell checker ;-)
> Maybe just this:
> "
> SEE ?EXEC
>
> : ?EXEC
> STATE * @ * 12 ?ERROR
> ;
> "
> ?ERROR is THROW with some decoration.

Aha, so its just the opposite of ?COMP with its own distinctive error
return.

I think I'm with Anton. If I was trying to implement a small Forth in
some retro system or other, rather than ?COMP I'd have a compile-only
bit and blind the interpreter to compile-only words in interpret mode.

On 6/17/12 2:52 AM, Anton Ertl wrote:
> Albert van der Horst<albert@spenarnc.xs4all.nl> writes:
>> I find places where ?EXEC is used. This gives an error because a word
>> if a word is executed while it never should.
>>
>> Examples are CODE and END-CODE in an assembler, but does this make
>> sense?
>>
>> : CODE ?EXEC .... ;
>> : END-CODE ?EXEC .... ;
>
> Hardly. It makes a little more sense if CODE and END-CODE are
> immediate. I guess the idea is to protect the porgrammer against
>
> : foo
> ... \ missing ";"
>
> code bar
> ...
>
> And of course in fig-Forth also ":" was immediate and contained a
> ?EXEC.

Baffled. By what logic should CODE, END-CODE, and : be immediate?

....
> Overall, ?EXEC is a bad idea, like ?COMP and STATE-smart words in
> general.

Agreed. All of these fall in the category of cute tricks that you *can*
do in Forth, but are really a poor idea in serious production code.
Newbies in Forth like to explore "uncharted waters". That's ok, but it's
not how serious code is written.

Cheers,
Elizabeth

--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

In article <2012Jun17.142751@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>Albert van der Horst <albert@spenarnc.xs4all.nl> writes:
>>I just discovered that having ?COMP in IF and DO is useful.
>
>No, it's the plague. It turns nicely working words into STATE-smart
>crap. ?COMP (like all STATE-smart words) tests STATE at run-time,
>whereas what is wanted is to have a check at parsing time (and that's
>the same for all STATE-smart words).

In this case the problem happens at parsing time, so the check is
done at the right time, i.e. while interpreting. Think about it.
?EXEC can never be a proper error message. ?COMP can never hinder
postponing something. Has nothing to do with state smartness.

When was the last time you did
: aaap .... [ IF ] .... ;
while you could have done
: aaap .... IF .... ;

>
>If you want to protect against using IF and DO interpretively, add a
>compile-only flag to the header, and let the text interpreter check
>it. For more complicated cases (words that can be used
>interpretively, but behave differently), there are a number of good
>implementation approaches (checking STATE at run-time is not one of
>them).

I have a better solution: I can use IF and DO interpretively,
after I say WANT NEW-IF .

Making the text interpreter smarter is the opposite way from where
I want to go.
Remember, ciforth's interpreter doesn't know about numbers, only
prefixes. It is simpler and more flexible that way.

But ?LOADING and ?EXEC I have removed. So I have the luxury that
2 words may go in the kernel to replace them. Maybe I'll finally add
NIP . 68 of my 199 euler Forth files contain WANT NIP.


>
>- 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:
> On 6/17/12 2:52 AM, Anton Ertl wrote:
> > Albert van der Horst<albert@spenarnc.xs4all.nl> writes:
> >> I find places where ?EXEC is used. This gives an error because a word
> >> if a word is executed while it never should.
> >>
> >> Examples are CODE and END-CODE in an assembler, but does this make
> >> sense?
> >>
> >> : CODE ?EXEC .... ;
> >> : END-CODE ?EXEC .... ;
> >
> > Hardly. It makes a little more sense if CODE and END-CODE are
> > immediate. I guess the idea is to protect the porgrammer against
> >
> > : foo
> > ... \ missing ";"
> >
> > code bar
> > ...
> >
> > And of course in fig-Forth also ":" was immediate and contained a
> > ?EXEC.
>
> Baffled. By what logic should CODE, END-CODE, and : be immediate?

Presumably so that you don't attempt:

: foo ... code foo2 ... end-code ... ;

> ...
> > Overall, ?EXEC is a bad idea, like ?COMP and STATE-smart words in
> > general.
>
> Agreed. All of these fall in the category of cute tricks that you *can*
> do in Forth, but are really a poor idea in serious production code.
> Newbies in Forth like to explore "uncharted waters". That's ok, but it's
> not how serious code is written.

VFX is loaded with ?COMPs. Not "serious production code" ?

Until such time as someone can show an issue with using ?COMP
in IF ELSE THEN etc then how is it a problem? Similarly CODE is
non-portable so whether it's immediate or contains a ?EXEC affects
no-one but the user.

Most tools can be mis-used. We don't ban them because someone
has managed to cut their finger.

On 6/17/12 7:06 PM, Ed wrote:
> Elizabeth D. Rather wrote:
>> On 6/17/12 2:52 AM, Anton Ertl wrote:
>>> Albert van der Horst<albert@spenarnc.xs4all.nl> writes:
>>>> I find places where ?EXEC is used. This gives an error because a word
>>>> if a word is executed while it never should.
>>>>
>>>> Examples are CODE and END-CODE in an assembler, but does this make
>>>> sense?
>>>>
>>>> : CODE ?EXEC .... ;
>>>> : END-CODE ?EXEC .... ;
>>>
>>> Hardly. It makes a little more sense if CODE and END-CODE are
>>> immediate. I guess the idea is to protect the porgrammer against
>>>
>>> : foo
>>> ... \ missing ";"
>>>
>>> code bar
>>> ...
>>>
>>> And of course in fig-Forth also ":" was immediate and contained a
>>> ?EXEC.
>>
>> Baffled. By what logic should CODE, END-CODE, and : be immediate?
>
> Presumably so that you don't attempt:
>
> : foo ... code foo2 ... end-code ... ;

What's to prevent...

code foo ... : poo ... ; end-code ;

Since CODE isn't specified to set STATE, it's legal. Equally silly,
equally unlikely.

>> ...
>>> Overall, ?EXEC is a bad idea, like ?COMP and STATE-smart words in
>>> general.
>>
>> Agreed. All of these fall in the category of cute tricks that you *can*
>> do in Forth, but are really a poor idea in serious production code.
>> Newbies in Forth like to explore "uncharted waters". That's ok, but it's
>> not how serious code is written.
>
> VFX is loaded with ?COMPs. Not "serious production code" ?

Everybody gets to draw his/her own line as to what's too foolish to warn
against.

> Until such time as someone can show an issue with using ?COMP
> in IF ELSE THEN etc then how is it a problem? Similarly CODE is
> non-portable so whether it's immediate or contains a ?EXEC affects
> no-one but the user.
>
> Most tools can be mis-used. We don't ban them because someone
> has managed to cut their finger.

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.

Cheers,
Elizabeth

--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

In article <VqCdnXuTWa6dgUPSnZ2dnUVZ_smdnZ2d@supernews.com> ,
Elizabeth D. Rather <erather@forth.com> wrote:
>On 6/17/12 2:52 AM, Anton Ertl wrote:
>> Albert van der Horst<albert@spenarnc.xs4all.nl> writes:
>>> I find places where ?EXEC is used. This gives an error because a word
>>> if a word is executed while it never should.
>>>
>>> Examples are CODE and END-CODE in an assembler, but does this make
>>> sense?
>>>
>>> : CODE ?EXEC .... ;
>>> : END-CODE ?EXEC .... ;
>>
>> Hardly. It makes a little more sense if CODE and END-CODE are
>> immediate. I guess the idea is to protect the porgrammer against
>>
>> : foo
>> ... \ missing ";"
>>
>> code bar
>> ...
>>
>> And of course in fig-Forth also ":" was immediate and contained a
>> ?EXEC.
>
>Baffled. By what logic should CODE, END-CODE, and : be immediate?
>
>...
>> Overall, ?EXEC is a bad idea, like ?COMP and STATE-smart words in
>> general.
>
>Agreed. All of these fall in the category of cute tricks that you *can*
>do in Forth, but are really a poor idea in serious production code.
>Newbies in Forth like to explore "uncharted waters". That's ok, but it's
>not how serious code is written.

After the explanation of Anton Ertl I finally see how ?EXEC
could be -- marginally -- useful.

: test dothis dothat
X SWAP IF
qqq
THEN
DROP ;

: test2 ....

In this situation if you change the last line of test to
DROP
you will have `` : test2 '' compiled and this gives an
error of test2 not found/ Mysterious, but you learn to interpret
that message.
By making : IMMEDIATE it can signal this condition.
CODE aap ... \ END-CODE
CODE noot ... END-CODE
Same situation.

?COMP saves me from the following hazard:
_ _ \ #scores, #sides
class C
M: sides M; ,
M: maxscores M; DUP ,
M: scores SWAP CELLS + M;
HERE DUP >R OVER CELLS ALLOT R> SWAP CELLS ERASE
endclass

This defines a class with an integer field and an array of
integers field that is initialised to zero.
The building of the structure amounts to
: BUILD-C HERE >R , DUP ,
HERE DUP >R OVER CELLS ALLOT R> SWAP CELLS ERASE
;
This is compiled, but also interpreted immediately to
calculate the offsets.
I tend to forget that the following doesn't work:
_ _
class C
M: sides M; ,
M: scores SWAP CELLS + M;
0 DO 0 , LOOP
endclass

and it leads to mysterious errors.

If DO warned at compile time that would have been prevented.

Loading an interpreting DO facility is a solution.
>
>Cheers,
>Elizabeth
>

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

Albert van der Horst <albert@spenarnc.xs4all.nl> writes:
>In article <2012Jun17.142751@mips.complang.tuwien.ac.at>,
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>Albert van der Horst <albert@spenarnc.xs4all.nl> writes:
>>>I just discovered that having ?COMP in IF and DO is useful.
>>
>>No, it's the plague. It turns nicely working words into STATE-smart
>>crap. ?COMP (like all STATE-smart words) tests STATE at run-time,
>>whereas what is wanted is to have a check at parsing time (and that's
>>the same for all STATE-smart words).
>
>In this case the problem happens at parsing time, so the check is
>done at the right time, i.e. while interpreting. Think about it.
>?EXEC can never be a proper error message. ?COMP can never hinder
>postponing something. Has nothing to do with state smartness.

Try <http://www.complang.tuwien.ac.at/forth/postponetest.fs> and see
how IF and DO with ?COMP are broken.

>When was the last time you did
>: aaap .... [ IF ] .... ;
>while you could have done
>: aaap .... IF .... ;

In a compiler where the text interpreter checks for compile-only words
(like Gforth) the first version would fail because IF is compile-only
and thus can only be compiled.

However, the issue is not

: aaap ... [ IF ] ... ;

but

: baz ... [ 3 5 gen-foo s" bla" gen-bar ] ... ;

where GEN-FOO contains, e.g., a "POSTPONE IF".

Yes, the ?COMP does not hinder POSTPONEing the IF, it just fails when
GEN-FOO runs. And it has everything to do with STATE-smartness: It
checks STATE at run-time, like any other STATE-smart word.

And yes, I have written production code where a code generator is
invoked in interpret state.

>>If you want to protect against using IF and DO interpretively, add a
>>compile-only flag to the header, and let the text interpreter check
>>it. For more complicated cases (words that can be used
>>interpretively, but behave differently), there are a number of good
>>implementation approaches (checking STATE at run-time is not one of
>>them).
....
>Making the text interpreter smarter is the opposite way from where
>I want to go.

If you don't want to go there, then don't. Just live without
recognizing interpretive uses of IF and DO. But if you want to
recognize them, do it properly. STATE-smartness (including ?COMP) is
both broken and more complicated than not checking at all, i.e., it's
a lose-lose solution.

- 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/

Op 15 Jun 2012 20:40:13 GMT schreef Albert van der Horst:

> I find places where ?EXEC is used. This gives an error because a word
> if a word is executed while it never should.
>
> Examples are CODE and END-CODE in an assembler, but does this make
> sense?
>
>: CODE ?EXEC .... ;
>: END-CODE ?EXEC .... ;
>
> By analogy I see I defined my classes like this:
>: class ?EXEC ... ;
>: end-class ?EXEC ... ;
>
> I find it hard to wrap my head around this. In what kind of situation
> would this error trigger?
> I would be equally happy with some other realistic example.
>
> Groetjes Albert
>
>
> --

I've looked at the Forth assemblers in volume 3 of Forth Dimensions.
William F. Ragdale's for the 6502 in issue 5 has immediate CODE END-CODE
and even for IF, ELSE, BEGIN, etc. and uses ?EXEC
John J. Cassady's for the 8080 in issue 6 has only CODE and END-CODE made
immediate with ?EXEC

I don't use immediate words in assembler and just removed ?EXEC from the
MetaForth. I sense no difference.

--
Coos

CHForth, 16 bit DOS applications
http://home.hccnet.nl/j.j.haak/forth.html