Reformulation of "STATE @ IF"

I know the ambiguities of state-smart words. However I am wondering
whether there is some common practice (or even an alternative optimum?)
of how to replace the construct by other means, eg dual wordlists and or
dual execution tokens, and with another practical syntax.

F. ex. F83 contains:

: IS (S cfa --- )
STATE @ IF COMPILE (IS) ELSE ' >IS ! THEN ; IMMEDIATE

(the meanings of >IS and (IS) are of no great importance now)

How would one reformulate this? Perhaps similar to CREATE ... DOES>? Eg:
: IS
executes> ' >is ! compiles> compile (is) ; IMMEDIATE

But which subpart would then be affected by IMMEDIATE?
Etc etc.... ?????

"A. K." <akk@nospam.org> writes:
>I know the ambiguities of state-smart words. However I am wondering
>whether there is some common practice (or even an alternative optimum?)
>of how to replace the construct by other means, eg dual wordlists and or
>dual execution tokens, and with another practical syntax.

Common practice? Not really. You can find a paper on the topic at
http://www.complang.tuwien.ac.at/papers/ertl98.ps.gz

My recommendation is to avoid parsing words (the typical reason for
wanting such things).

>How would one reformulate this? Perhaps similar to CREATE ... DOES>? Eg:
>: IS
> executes> ' >is ! compiles> compile (is) ; IMMEDIATE
>
>But which subpart would then be affected by IMMEDIATE?

IMMEDIATE is a way to change the compilation semantics of the word,
but you already changed it with COMPILES>. So IMMEDIATE does not make
much sense here. Either it has no effect (then why did you write
IMMEDIATE) or it overwrites the compilation semantics with the
execution semantics (then why did you write the COMPILES> part?).

- 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 2011: http://www.euroforth.org/ef11/

On 23.04.2012 19:18, Anton Ertl wrote:
> "A. K."<akk@nospam.org> writes:
>> How would one reformulate this? Perhaps similar to CREATE ... DOES>? Eg:
>> : IS
>> executes> '>is ! compiles> compile (is) ; IMMEDIATE
>>
>> But which subpart would then be affected by IMMEDIATE?
>
> IMMEDIATE is a way to change the compilation semantics of the word,
> but you already changed it with COMPILES>. So IMMEDIATE does not make
> much sense here. Either it has no effect (then why did you write
> IMMEDIATE) or it overwrites the compilation semantics with the
> execution semantics (then why did you write the COMPILES> part?).

In a system with 1 dictionary entry for IF, IMMEDIATE would affect this
one dictionary entry for IF.

But in a system creating 2 dictionary entries for IF, the question seems
valid, although admittedly strange. However IMO at least the system
should be able to handle it intelligently.

On 23.04.2012 19:56, A. K. wrote:
> On 23.04.2012 19:18, Anton Ertl wrote:
>> "A. K."<akk@nospam.org> writes:
>>> How would one reformulate this? Perhaps similar to CREATE ... DOES>? Eg:
>>> : IS
>>> executes> '>is ! compiles> compile (is) ; IMMEDIATE
>>>
>>> But which subpart would then be affected by IMMEDIATE?
>>
>> IMMEDIATE is a way to change the compilation semantics of the word,
>> but you already changed it with COMPILES>. So IMMEDIATE does not make
>> much sense here. Either it has no effect (then why did you write
>> IMMEDIATE) or it overwrites the compilation semantics with the
>> execution semantics (then why did you write the COMPILES> part?).
>
> In a system with 1 dictionary entry for IF, IMMEDIATE would affect this
> one dictionary entry for IF.
>
> But in a system creating 2 dictionary entries for IF, the question seems
> valid, although admittedly strange. However IMO at least the system
> should be able to handle it intelligently.
>
oops, sorry, please replace IF by IS
:-)

On Apr 23, 1:56*pm, "A. K." <a...@nospam.org> wrote:
> On 23.04.2012 19:18, Anton Ertl wrote:
>
> > "A. K."<a...@nospam.org> *writes:
> >> How would one reformulate this? *Perhaps similar to CREATE ... DOES>? Eg:
> >> : IS
> >> * *executes> *'>is ! compiles> *compile (is) ; IMMEDIATE
>
> >> But which subpart would then be affected by IMMEDIATE?
>
> > IMMEDIATE is a way to change the compilation semantics of the word,
> > but you already changed it with COMPILES>. *So IMMEDIATE does not make
> > much sense here. *Either it has no effect (then why did you write
> > IMMEDIATE) or it overwrites the compilation semantics with the
> > execution semantics (then why did you write the COMPILES> *part?).
>
> In a system with 1 dictionary entry for IF, IMMEDIATE would affect this
> one dictionary entry for IF.

> But in a system creating 2 dictionary entries for IF, the question seems
> valid, although admittedly strange. However IMO at least the system
> should be able to handle it intelligently.

Another implementation approach would be a compilation-only dictionary
entry that is only found during compilation. Then you'd just define
the two parts separately, defining the interpret mode version first:

: IS ' >is ! ;
: IS compile (is) ; IMMEDIATE COMPILE-ONLY

The point about the following pattern:
: IS executes> ' >is ! compiles> compile (is) ;

.... is that an IMMEDIATE would be redundant at best ~ if "compiles>"
means anything sensible, it is specifying the compilation semantics,
and so no IMMEDIATE would be required.

On 23.04.2012 23:42, BruceMcF wrote:
> Another implementation approach would be a compilation-only dictionary
> entry that is only found during compilation. Then you'd just define
> the two parts separately, defining the interpret mode version first:
>
> : IS '>is ! ;
> : IS compile (is) ; IMMEDIATE COMPILE-ONLY

Pardon me, but this is "ugly" and feels "unforthy", at least to my
tender me. :-)
There should be a conciser syntax.

> The point about the following pattern:
> : IS executes> '>is ! compiles> compile (is) ;
>
> ... is that an IMMEDIATE would be redundant at best ~ if "compiles>"
> means anything sensible, it is specifying the compilation semantics,
> and so no IMMEDIATE would be required.

Yes true. And either "FIND et al" will have to ignore the immediate
flag, or IMMEDIATE must be made to have no effect on such words.

The other point is that you need a modified "FIND et al" that returns
either the compilation token OR the execution token depending on STATE.
This is against the current standard. And FIND also return an IMMEDIATE
flag... Quirky...

On 4/23/12 7:57 PM, A. K. wrote:
> On 23.04.2012 23:42, BruceMcF wrote:
>> Another implementation approach would be a compilation-only dictionary
>> entry that is only found during compilation. Then you'd just define
>> the two parts separately, defining the interpret mode version first:
>>
>> : IS '>is ! ;
>> : IS compile (is) ; IMMEDIATE COMPILE-ONLY
>
> Pardon me, but this is "ugly" and feels "unforthy", at least to my
> tender me. :-)
> There should be a conciser syntax.

I don't see anything wrong with STATE @ IF ... for those who insist on
doing this sort of thing despite all the good advice based on years of
experience: it's rarely a good idea.

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."
==================================================

"A. K." <akk@nospam.org> writes:
>On 23.04.2012 19:18, Anton Ertl wrote:
>> "A. K."<akk@nospam.org> writes:
>>> How would one reformulate this? Perhaps similar to CREATE ... DOES>? Eg:
>>> : IS
>>> executes> '>is ! compiles> compile (is) ; IMMEDIATE
>>>
>>> But which subpart would then be affected by IMMEDIATE?
>>
>> IMMEDIATE is a way to change the compilation semantics of the word,
>> but you already changed it with COMPILES>. So IMMEDIATE does not make
>> much sense here. Either it has no effect (then why did you write
>> IMMEDIATE) or it overwrites the compilation semantics with the
>> execution semantics (then why did you write the COMPILES> part?).
>
>In a system with 1 dictionary entry for IF, IMMEDIATE would affect this
>one dictionary entry for IF.
>
>But in a system creating 2 dictionary entries for IF, the question seems
>valid, although admittedly strange. However IMO at least the system
>should be able to handle it intelligently.

Which question? My statement is not about the implementation, but the
meaning (semantics) of IMMEDIATE and COMPILES>. Both change the
compilation semantics. It does not make sense to use them on the same
word, but if the programmer does, either behaviour of the system is
equally plausible; or the system migh produce an error message.

Let's see what Gforth does:

:noname cr ." interpretation semantics" ;
:noname cr ." compilation semantics" ;
interpret/compile: foo \ first without IMMEDIATE
foo \ prints "interpretation semantics"
] foo [ \ prints "compilation semantics"
immediate \ now with IMMEDIATE
foo \ prints "interpretation semantics"
] foo [ \ prints "compilation semantics"

So the IMMEDIATE has no effect here.

- 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 2011: http://www.euroforth.org/ef11/

On Apr 24, 1:57*am, "A. K." <a...@nospam.org> wrote:
> The other point is that you need a modified "FIND et al" that returns
> either the compilation token OR the execution token depending on STATE.
> This is against the current standard.

No, it is not: the current standard permits a different execution
token to be returned in a different state:
"For a given string, the values returned by FIND while compiling
may differ from those returned while not compiling."

What it does not do is to _specify_ whether one can and how one does
access special compilation semantics, when they are not the same as
taking the xt representing the interpretation semantics and either
executing or compiling it.

And lacking any standard way to get at special compilation semantics,
its likely to be common to ignore the standard permission to return a
different xt in different states:

> And FIND also return an IMMEDIATE
> flag... *Quirky...

In that case, the cleanest solution that is compatible with the
standard is to return the interpreter semantics in interpreter state
and the compilation semantics in compilation state, with neither
immediate ~ but "cleaner" and "clean" are not synonymous here.

On Apr 24, 1:57*am, "A. K." <a...@nospam.org> wrote:
> On 23.04.2012 23:42, BruceMcF wrote:

> > Another implementation approach would be a compilation-only dictionary
> > entry that is only found during compilation. Then you'd just define
> > the two parts separately, defining the interpret mode version first:
>
> > : IS '>is ! ;
> > : IS compile (is) ; IMMEDIATE COMPILE-ONLY
>
> Pardon me, but this is "ugly" and feels "unforthy", at least to my
> tender me. *:-)

> There should be a conciser syntax.

There is ...

: IS '>is ! ;
: IS compile (is) ; COMPILE-IMMEDIATE

.... but not so very much more concise. However, its cumbersome for
that unusual case since it is a syntax optimized for the more common
case, such as:

: IF ( c: -- orig ) '{?BRANCH) COMPILE, HERE 0 ,
; COMPILE-IMMEDIATE

.... where there is no interpreter semantics required, so in
interpretation state IF is simply not found.

On 24.04.2012 12:26, Anton Ertl wrote:
> Let's see what Gforth does:
>
> :noname cr ." interpretation semantics" ;
> :noname cr ." compilation semantics" ;
> interpret/compile: foo \ first without IMMEDIATE
> foo \ prints "interpretation semantics"
> ] foo [ \ prints "compilation semantics"
> immediate \ now with IMMEDIATE
> foo \ prints "interpretation semantics"
> ] foo [ \ prints "compilation semantics"
>
> So the IMMEDIATE has no effect here.
>
> - anton

Thanks, I verified gforth's behavior that just ignores IMMEDIATE here:

Gforth 0.7.0, Copyright (C) 1995-2008 Free Software Foundation, Inc.
Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
Type `bye' to exit
ok
:noname cr ." interp1" ; ok
:noname cr ." compil1" ; ok
interpret/compile: foo1 ok
:noname cr ." interp2" ; ok
:noname cr ." compil2" ; ok
interpret/compile: foo2 immediate ok
ok
foo1
interp1 ok
foo2
interp2 ok
: my1 foo1 ;
compil1 ok
: my2 foo2 ;
compil2 ok
my1 ok
my2 ok

Although IMO the IMMEDIATE command should NOT be ignored, i.e.

: my2 foo2 ; \ should produce:
interp2

On Apr 24, 1:38*pm, "A. K." <a...@nospam.org> wrote:
> On 24.04.2012 12:26, Anton Ertl wrote:
>
> > Let's see what Gforth does:
>
> > :noname cr ." interpretation semantics" ;
> > :noname cr ." compilation semantics" ;
> > interpret/compile: foo \ first without IMMEDIATE
> > foo * * * * * * * * * *\ prints "interpretation semantics"
> > ] foo [ * * * * * * * *\ prints "compilation semantics"
> > immediate * * * * * * *\ now with IMMEDIATE
> > foo * * * * * * * * * *\ prints "interpretation semantics"
> > ] foo [ * * * * * * * *\ prints "compilation semantics"
>
> > So the IMMEDIATE has no effect here.
>
> > - anton
>
> Thanks, I verified gforth's behavior that just ignores IMMEDIATE here:
>
> Gforth 0.7.0, Copyright (C) 1995-2008 Free Software Foundation, Inc.
> Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
> Type `bye' to exit
> * *ok
> :noname cr ." interp1" ; *ok
> :noname cr ." compil1" ; *ok
> interpret/compile: foo1 *ok
> :noname cr ." interp2" ; *ok
> :noname cr ." compil2" ; *ok
> interpret/compile: foo2 immediate *ok
> * *ok
> foo1
> interp1 ok
> foo2
> interp2 ok
> : my1 foo1 ;
> compil1 ok
> : my2 foo2 ;
> compil2 ok
> my1 *ok
> my2 *ok

> Although IMO the IMMEDIATE command should NOT be ignored, i.e.
>
> : my2 foo2 ; \ should produce:
> interp2

Its not necessarily being ignored: it may be redundant. The text
interpreter does:

"b) Search the dictionary name space (see 3.4.2). If a definition name
matching the string is found:

if interpreting, perform the interpretation semantics of the
definition (see 3.4.3.2), and continue at a);
if compiling, perform the compilation semantics of the definition
(see 3.4.3.3), and continue at a). "

3.4.2 does not specify whether a dual-xt word *will* find the
interpretation or compilation semantics when compiling, but the
definition of FIND specifies that a different xt *may be* return in
interpretation and compilation state, which implies that the execution
semantics *may be* different in the two states.

Since IMMEDIATE simply says it has the word perform the execution
semantics in compilation state, and the dual-xt system *does* perform
the compilation state execution semantics in compilation state, the
IMMEDIATE would be redundant but respected nonetheless.

On Apr 24, 11:26*am, an...@mips.complang.tuwien.ac.at (Anton Ertl)
wrote:
> "A. K." <a...@nospam.org> writes:
> >On 23.04.2012 19:18, Anton Ertl wrote:
> >> "A. K."<a...@nospam.org> *writes:
> >>> How would one reformulate this? *Perhaps similar to CREATE ... DOES>? Eg:
> >>> : IS
> >>> * *executes> *'>is ! compiles> *compile (is) ; IMMEDIATE
>
> >>> But which subpart would then be affected by IMMEDIATE?
>
> >> IMMEDIATE is a way to change the compilation semantics of the word,
> >> but you already changed it with COMPILES>. *So IMMEDIATE does not make
> >> much sense here. *Either it has no effect (then why did you write
> >> IMMEDIATE) or it overwrites the compilation semantics with the
> >> execution semantics (then why did you write the COMPILES> *part?).
>
> >In a system with 1 dictionary entry for IF, IMMEDIATE would affect this
> >one dictionary entry for IF.
>
> >But in a system creating 2 dictionary entries for IF, the question seems
> >valid, although admittedly strange. However IMO at least the system
> >should be able to handle it intelligently.
>
> Which question? *My statement is not about the implementation, but the
> meaning (semantics) of IMMEDIATE and COMPILES>. *Both change the
> compilation semantics. *It does not make sense to use them on the same
> word, but if the programmer does, either behaviour of the system is
> equally plausible; or the system migh produce an error message.
>
> Let's see what Gforth does:
>
> :noname cr ." interpretation semantics" ;
> :noname cr ." compilation semantics" ;
> interpret/compile: foo \ first without IMMEDIATE
> foo * * * * * * * * * *\ prints "interpretation semantics"
> ] foo [ * * * * * * * *\ prints "compilation semantics"
> immediate * * * * * * *\ now with IMMEDIATE
> foo * * * * * * * * * *\ prints "interpretation semantics"
> ] foo [ * * * * * * * *\ prints "compilation semantics"
>
> So the IMMEDIATE has no effect here.

Dual XT W32F returns;

STC Experimental Version: 0.05.01 Build: 535
: foo cr ." interpretation semantics"
compilation> drop
cr ." compilation semantics" ; ok
foo
interpretation semantics ok
] foo [
compilation semantics ok
immediate \ now with IMMEDIATE ok
foo
interpretation semantics ok
] foo [ \ note difference
interpretation semantics ok




>
> - 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 2011:http://www.euroforth.org/ef11/

On 24.04.2012 20:25, BruceMcF wrote:

> 3.4.2 does not specify whether a dual-xt word *will* find the
> interpretation or compilation semantics when compiling, but the
> definition of FIND specifies that a different xt *may be* return in
> interpretation and compilation state, which implies that the execution
> semantics *may be* different in the two states.
>
> Since IMMEDIATE simply says it has the word perform the execution
> semantics in compilation state, and the dual-xt system *does* perform
> the compilation state execution semantics in compilation state, the
> IMMEDIATE would be redundant but respected nonetheless.

It seems that with those many "maybe"s we are ending again at the
classical fringe of a so-called standard that it is
"implementation-dependent". ;-)

Op Tue, 24 Apr 2012 10:26:33 GMT schreef Anton Ertl:

> "A. K." <akk@nospam.org> writes:
>>On 23.04.2012 19:18, Anton Ertl wrote:
>>> "A. K."<akk@nospam.org> writes:
>>>> How would one reformulate this? Perhaps similar to CREATE ... DOES>? Eg:
>>>> : IS
>>>> executes> '>is ! compiles> compile (is) ; IMMEDIATE
>>>>
>>>> But which subpart would then be affected by IMMEDIATE?
>>>
>>> IMMEDIATE is a way to change the compilation semantics of the word,
>>> but you already changed it with COMPILES>. So IMMEDIATE does not make
>>> much sense here. Either it has no effect (then why did you write
>>> IMMEDIATE) or it overwrites the compilation semantics with the
>>> execution semantics (then why did you write the COMPILES> part?).
>>
>>In a system with 1 dictionary entry for IF, IMMEDIATE would affect this
>>one dictionary entry for IF.
>>
>>But in a system creating 2 dictionary entries for IF, the question seems
>>valid, although admittedly strange. However IMO at least the system
>>should be able to handle it intelligently.
>
> Which question? My statement is not about the implementation, but the
> meaning (semantics) of IMMEDIATE and COMPILES>. Both change the
> compilation semantics. It does not make sense to use them on the same
> word, but if the programmer does, either behaviour of the system is
> equally plausible; or the system migh produce an error message.
>
> Let's see what Gforth does:
>
>:noname cr ." interpretation semantics" ;
>:noname cr ." compilation semantics" ;
> interpret/compile: foo \ first without IMMEDIATE
> foo \ prints "interpretation semantics"
> ] foo [ \ prints "compilation semantics"
> immediate \ now with IMMEDIATE
> foo \ prints "interpretation semantics"
> ] foo [ \ prints "compilation semantics"
>
> So the IMMEDIATE has no effect here.
>
Why would it, interpret/compile: create IMMEDIATE definitions, at least in
Gforth version 0.7.0. IMMEDIATE sets bits, the result would be different if
it toggled the bits.

> - anton


--
Coos

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