Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #11543 > unrolled thread

Reformulation of "STATE @ IF"

Back to article view | Back to comp.lang.forth

Contents

  Reformulation of "STATE @ IF" "A. K." <akk@nospam.org> - 2012-04-23 19:01 +0200
    Re: Reformulation of "STATE @ IF" anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-04-23 17:18 +0000
      Re: Reformulation of "STATE @ IF" "A. K." <akk@nospam.org> - 2012-04-23 19:56 +0200
        Re: Reformulation of "STATE @ IF" "A. K." <akk@nospam.org> - 2012-04-23 20:20 +0200
        Re: Reformulation of "STATE @ IF" BruceMcF <agila61@netscape.net> - 2012-04-23 14:42 -0700
          Re: Reformulation of "STATE @ IF" "A. K." <akk@nospam.org> - 2012-04-24 07:57 +0200
            Re: Reformulation of "STATE @ IF" "Elizabeth D. Rather" <erather@forth.com> - 2012-04-23 22:06 -1000
              Re: Reformulation of "STATE @ IF" Hans Bezemer <the.beez.speaks@gmail.com> - 2012-04-26 08:42 +0200
                Re: Reformulation of "STATE @ IF" Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-04-26 03:55 -0500
            Re: Reformulation of "STATE @ IF" BruceMcF <agila61@netscape.net> - 2012-04-24 07:55 -0700
            Re: Reformulation of "STATE @ IF" BruceMcF <agila61@netscape.net> - 2012-04-24 08:00 -0700
          Re: Reformulation of "STATE @ IF" awegel@arcor.de (Alex Wegel) - 2012-04-25 14:32 +0200
        Re: Reformulation of "STATE @ IF" anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-04-24 10:26 +0000
          Re: Reformulation of "STATE @ IF" "A. K." <akk@nospam.org> - 2012-04-24 19:38 +0200
            Re: Reformulation of "STATE @ IF" BruceMcF <agila61@netscape.net> - 2012-04-24 11:25 -0700
              Re: Reformulation of "STATE @ IF" "A. K." <akk@nospam.org> - 2012-04-24 22:10 +0200
                Re: Reformulation of "STATE @ IF" BruceMcF <agila61@netscape.net> - 2012-04-24 16:02 -0700
                Re: Reformulation of "STATE @ IF" "Elizabeth D. Rather" <erather@forth.com> - 2012-04-24 13:54 -1000
                  Re: Reformulation of "STATE @ IF" "A. K." <akk@nospam.org> - 2012-04-25 06:58 +0200
                    Re: Reformulation of "STATE @ IF" "Elizabeth D. Rather" <erather@forth.com> - 2012-04-24 21:01 -1000
                    Re: Reformulation of "STATE @ IF" "Elizabeth D. Rather" <erather@forth.com> - 2012-04-24 21:40 -1000
                    Re: Reformulation of "STATE @ IF" BruceMcF <agila61@netscape.net> - 2012-04-25 05:56 -0700
          Re: Reformulation of "STATE @ IF" Alex McDonald <blog@rivadpm.com> - 2012-04-24 12:11 -0700
          Re: Reformulation of "STATE @ IF" Coos Haak <chforth@hccnet.nl> - 2012-04-24 22:40 +0200
            Re: Reformulation of "STATE @ IF" anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-04-25 13:03 +0000
              Re: Reformulation of "STATE @ IF" BruceMcF <agila61@netscape.net> - 2012-04-25 08:37 -0700
                Re: Reformulation of "STATE @ IF" anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-04-26 16:17 +0000
    Re: Reformulation of "STATE @ IF" "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-04-25 01:44 -0400
      Re: Reformulation of "STATE @ IF" "A. K." <akk@nospam.org> - 2012-04-25 08:33 +0200
        Re: Reformulation of "STATE @ IF" Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-04-25 04:09 -0500
          Re: Reformulation of "STATE @ IF" stephenXXX@mpeforth.com (Stephen Pelc) - 2012-04-25 13:15 +0000
            Re: Reformulation of "STATE @ IF" Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-04-25 10:52 -0500
              Re: Reformulation of "STATE @ IF" stephenXXX@mpeforth.com (Stephen Pelc) - 2012-04-25 17:50 +0000
                Re: Reformulation of "STATE @ IF" Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-04-26 04:06 -0500
                  Re: Reformulation of "STATE @ IF" Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-04-27 11:37 +0000
              Re: Reformulation of "STATE @ IF" "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-04-25 15:28 -0400
                Re: Reformulation of "STATE @ IF" "Elizabeth D. Rather" <erather@forth.com> - 2012-04-25 10:02 -1000
                Re: Reformulation of "STATE @ IF" Mark Wills <markrobertwills@yahoo.co.uk> - 2012-04-26 01:30 -0700
                  Re: Reformulation of "STATE @ IF" Coos Haak <chforth@hccnet.nl> - 2012-04-26 16:48 +0200
                  Re: Reformulation of "STATE @ IF" BruceMcF <agila61@netscape.net> - 2012-04-26 09:27 -0700
                  Re: Reformulation of "STATE @ IF" "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-04-26 16:42 -0400
                    Re: Reformulation of "STATE @ IF" Coos Haak <chforth@hccnet.nl> - 2012-04-27 00:46 +0200
                      Re: Reformulation of "STATE @ IF" "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-04-27 05:32 -0400
                        Re: Reformulation of "STATE @ IF" Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-04-27 05:35 -0500
                        Re: Reformulation of "STATE @ IF" BruceMcF <agila61@netscape.net> - 2012-04-27 04:00 -0700
                          Re: Reformulation of "STATE @ IF" "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-04-27 20:38 -0400
                            Re: Reformulation of "STATE @ IF" awegel@arcor.de (Alex Wegel) - 2012-04-28 03:02 +0200
                            Re: Reformulation of "STATE @ IF" BruceMcF <agila61@netscape.net> - 2012-04-27 18:12 -0700
                              Re: Reformulation of "STATE @ IF" anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-04-30 12:45 +0000
                                Re: Reformulation of "STATE @ IF" BruceMcF <agila61@netscape.net> - 2012-04-30 07:56 -0700
                                  Re: Reformulation of "STATE @ IF" anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-04-30 16:17 +0000
                              Re: Reformulation of "STATE @ IF" "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-05-02 15:51 -0400
                                Re: Reformulation of "STATE @ IF" BruceMcF <agila61@netscape.net> - 2012-05-02 13:15 -0700
                                Re: Reformulation of "STATE @ IF" Mark Wills <markrobertwills@yahoo.co.uk> - 2012-05-02 12:59 -0700
                                  Re: Reformulation of "STATE @ IF" BruceMcF <agila61@netscape.net> - 2012-05-02 13:54 -0700
                                    Re: Reformulation of "STATE @ IF" Mark Wills <markrobertwills@yahoo.co.uk> - 2012-05-02 14:25 -0700
                Re: Reformulation of "STATE @ IF" Mark Wills <markrobertwills@yahoo.co.uk> - 2012-04-26 01:43 -0700
                  Re: Reformulation of "STATE @ IF" Mark Wills <markrobertwills@yahoo.co.uk> - 2012-04-26 02:18 -0700
                    Re: Reformulation of "STATE @ IF" Coos Haak <chforth@hccnet.nl> - 2012-04-26 16:54 +0200
                      Re: Reformulation of "STATE @ IF" BruceMcF <agila61@netscape.net> - 2012-04-26 10:46 -0700
                        Re: Reformulation of "STATE @ IF" Mark Wills <markrobertwills@yahoo.co.uk> - 2012-04-26 12:21 -0700
                          Re: Reformulation of "STATE @ IF" "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-04-26 18:31 -0400
                            Re: Reformulation of "STATE @ IF" "Elizabeth D. Rather" <erather@forth.com> - 2012-04-26 14:32 -1000
                              Re: Reformulation of "STATE @ IF" BruceMcF <agila61@netscape.net> - 2012-04-27 01:50 -0700
                              Re: Reformulation of "STATE @ IF" anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-04-27 09:10 +0000
                                Re: Reformulation of "STATE @ IF" "Elizabeth D. Rather" <erather@forth.com> - 2012-04-27 09:47 -1000
                              Re: Reformulation of "STATE @ IF" "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-04-27 05:33 -0400
                                Re: Reformulation of "STATE @ IF" "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-04-27 15:06 -0400
                              Re: Reformulation of "STATE @ IF" JennyB <jennybrien@googlemail.com> - 2012-04-27 02:54 -0700
                                Re: Reformulation of "STATE @ IF" stephenXXX@mpeforth.com (Stephen Pelc) - 2012-04-27 11:30 +0000
                      Re: Reformulation of "STATE @ IF" Mark Wills <markrobertwills@yahoo.co.uk> - 2012-04-26 12:18 -0700
                        Re: Reformulation of "STATE @ IF" Coos Haak <chforth@hccnet.nl> - 2012-04-26 22:21 +0200
                Re: Reformulation of "STATE @ IF" Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-04-26 04:27 -0500
      Re: Reformulation of "STATE @ IF" Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-04-25 04:08 -0500
        Re: Reformulation of "STATE @ IF" "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-04-25 15:29 -0400
          Re: Reformulation of "STATE @ IF" "Elizabeth D. Rather" <erather@forth.com> - 2012-04-25 10:27 -1000
          Re: Reformulation of "STATE @ IF" Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-04-26 04:31 -0500
          Re: Reformulation of "STATE @ IF" anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-04-26 16:35 +0000
            Re: Reformulation of "STATE @ IF" Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-04-27 11:58 +0000

Page 1 of 4  [1] 2 3 4  Next page →

#11543 — 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.... ?????

[toc] | [next] | [standalone]

#11544

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

[toc] | [prev] | [next] | [standalone]

#11545

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.

[toc] | [prev] | [next] | [standalone]

#11546

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
:-)

[toc] | [prev] | [next] | [standalone]

#11552

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.

[toc] | [prev] | [next] | [standalone]

#11556

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

[toc] | [prev] | [next] | [standalone]

#11560

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

[toc] | [prev] | [next] | [standalone]

#11638

On Mon, 23 Apr 2012 22:06:22 -1000, "Elizabeth D. Rather" 
<erather@forth.com> wrote:
> 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.
Unless the TC thinks it's a good idea to do so. So we're stuck with 
the horror that is TO (which uses state) and his little brother IS 
and I have trouble explaining why ." in interpretation doesn't work 
and [char] is the way to inline a character while compiling. Point 
is: statesmart is easier for the casual programmer. Making it 
inconsistent is unforgivable. Note it doesn't concern me really. Due 
to it's architecture 4tH is consistent, whether you write ANS code or 
not.

Hans Bezemer

[toc] | [prev] | [next] | [standalone]

#11641

Hans Bezemer <the.beez.speaks@gmail.com> wrote:
> On Mon, 23 Apr 2012 22:06:22 -1000, "Elizabeth D. Rather" 
> <erather@forth.com> wrote:
>> 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.
>
> Unless the TC thinks it's a good idea to do so. So we're stuck with 
> the horror that is TO (which uses state) and his little brother IS

Well, TO doesn't really have to use STATE, as we discussed here a
while back, and a smart compiler can recognize TO and optimize it.  I
don't know why anyone thinks that IS should be state-smart; it doesn't
help.

> and I have trouble explaining why ." in interpretation doesn't work
> and [char] is the way to inline a character while compiling. Point
> is: statesmart is easier for the casual programmer.

And it's harder for long-term maintanance.  There's the conflict.

Andrew.

[toc] | [prev] | [next] | [standalone]

#11567

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.

[toc] | [prev] | [next] | [standalone]

#11569

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.

[toc] | [prev] | [next] | [standalone]

#11607

BruceMcF <agila61@netscape.net> 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:

I used this approach for a long time without problems.

[toc] | [prev] | [next] | [standalone]

#11562

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

[toc] | [prev] | [next] | [standalone]

#11577

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

[toc] | [prev] | [next] | [standalone]

#11578

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.

[toc] | [prev] | [next] | [standalone]

#11580

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".  ;-)

[toc] | [prev] | [next] | [standalone]

#11583

On Apr 24, 4:10 pm, "A. K." <a...@nospam.org> wrote:
> 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".  ;-)

It'd be called a standard because it is one, but yes, where FIND says
that it *may* return different xt's in different states, but does not
specify under what circumstances, then "under what circumstances" is
definitely implementation dependent.

That is, it also seems to be permitted to return the xt of the
interpretation semantics in either state, in which case the IMMEDIATE
specification could be argued to have a different interpretation.

[toc] | [prev] | [next] | [standalone]

#11584

On 4/24/12 10:10 AM, A. K. wrote:
> 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". ;-)
>

Well, obviously, since how you implement a dictionary and immediacy is 
inherently implementation-dependent, and deliberately so. The point 
everyone is trying to make is that the use of the word IMMEDIATE in that 
definition is meaningless, given the very explicit description of 
IMMEDIATE in the standard.

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

[toc] | [prev] | [next] | [standalone]

#11591

On 25.04.2012 01:54, Elizabeth D. Rather wrote:
> On 4/24/12 10:10 AM, A. K. wrote:
>> 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". ;-)
>>
>
> Well, obviously, since how you implement a dictionary and immediacy is
> inherently implementation-dependent, and deliberately so. The point
> everyone is trying to make is that the use of the word IMMEDIATE in that
> definition is meaningless, given the very explicit description of
> IMMEDIATE in the standard.
>
> Cheers,
> Elizabeth
>

Sure, it's nothing that shakes the world. But whether it can shake an 
application depends on the application -- and different Forths behave 
differently here, each of them claiming to be standard Forths. I 
wouldn't call it meaningless.

[toc] | [prev] | [next] | [standalone]

#11597

On 4/24/12 6:58 PM, A. K. wrote:
> On 25.04.2012 01:54, Elizabeth D. Rather wrote:
>> On 4/24/12 10:10 AM, A. K. wrote:
>>> 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". ;-)
>>>
>>
>> Well, obviously, since how you implement a dictionary and immediacy is
>> inherently implementation-dependent, and deliberately so. The point
>> everyone is trying to make is that the use of the word IMMEDIATE in that
>> definition is meaningless, given the very explicit description of
>> IMMEDIATE in the standard.
>>
>> Cheers,
>> Elizabeth
>>
>
> Sure, it's nothing that shakes the world. But whether it can shake an
> application depends on the application -- and different Forths behave
> differently here, each of them claiming to be standard Forths. I
> wouldn't call it meaningless.

Who called it meaningless?  Not me!  Folks who standardize a language 
can choose whether to mandate implementation details or not.  Forth83 
did; Forth94 and Forth 200x do not. There are pros and cons to such a 
decision.

If you mandate implementation details, you improve portability at the 
cost of limiting the ability of implementers to innovate. Forth83 could 
not run on 32-bit hardware efficiently. It couldn't allow 
compile-to-code or optimized code implementations. Forth94 allowed all 
those things. It then explicitly called out implementation-dependent and 
implementation-specified features (which differ in the amount of 
documentation required). Programmers who choose to write application 
code that is implementation-dependent can do so knowingly, and if they 
wish to be portable to different implementations they know exactly what 
features need to be dealt with explicitly in a "compatibility layer".

I would say it's not only far from meaningless, it's important.

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

[toc] | [prev] | [next] | [standalone]

Page 1 of 4  [1] 2 3 4  Next page →

Back to top | Article view | comp.lang.forth

csiph-web