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 4 of 4 — ← Prev page 1 2 3 [4]

#11660

On Apr 26, 6:46 pm, BruceMcF <agil...@netscape.net> wrote:
> On Apr 26, 10:54 am, Coos Haak <chfo...@hccnet.nl> wrote:
>
> > Op Thu, 26 Apr 2012 02:18:05 -0700 (PDT) schreef Mark Wills:
>
> > <snip>> Rod, my earlier code was misleading - sorry. In my system ['] wasn't
> > > immediate (though it still worked).
>
> > Prove it, ['] has to be immediate, otherwise it could not find the next
> > word during compiling.
>
> I think the trick there is likely to be that when the word it is
> compiled in executes, it fetches the content of the following cell to
> the stack.
>
> That's cute, but I think the test of whether "it works" would be to
> use ['] on an immediate word, eg:
>    ... ['] [DEFINED] ...
>
> ... and see if you actually got the xt of [DEFINED] ... maybe:
>    : test ['] [DEFINED] EXIT ABORT ;
>
> ... might test that boundary condition: if ['] doesn't work correctly,
> its possible that the definition may fail to compile because it is not
> well structured code.

That's exactly right, Bruce. And yes, it didn't work on immediate
words! I only noticed when I read the comments in my source code. For
each core word, I have the text of the Forth 83 standard as the
preamble as comments in my source. I noticed that the standard says it
is an immediate word, but my code (actually a single bit in the
dictionary) didn't reflect that.

Mark

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

#11665

"Mark Wills" <markrobertwills@yahoo.co.uk> wrote in message
news:050b8f57-6b49-4283-aa01-d3f411599ece@f37g2000yqc.googlegroups.com...
On Apr 26, 6:46 pm, BruceMcF <agil...@netscape.net> wrote:
> On Apr 26, 10:54 am, Coos Haak <chfo...@hccnet.nl> wrote:
> > Op Thu, 26 Apr 2012 02:18:05 -0700 (PDT) schreef Mark Wills:
...

> > > > <snip>
> > > > Rod, my earlier code was misleading - sorry. In my system [']
> > > > wasn't immediate (though it still worked).
>
> > > Prove it, ['] has to be immediate, otherwise it could not find the
> > > next word during compiling.
>
> > I think the trick there is likely to be that when the word it is
> > compiled in executes, it fetches the content of the following cell to
> > the stack.
> >
> > That's cute, but I think the test of whether "it works" would be to
> > use ['] on an immediate word, eg:
> > ... ['] [DEFINED] ...
> >
> > ... and see if you actually got the xt of [DEFINED] ... maybe:
> > : test ['] [DEFINED] EXIT ABORT ;
> >
> > ... might test that boundary condition: if ['] doesn't work correctly,
> > its possible that the definition may fail to compile because it is not
> > well structured code.
>
> That's exactly right, Bruce. And yes, it didn't work on immediate
> words! I only noticed when I read the comments in my source code. For
> each core word, I have the text of the Forth 83 standard as the
> preamble as comments in my source. I noticed that the standard says it
> is an immediate word, but my code (actually a single bit in the
> dictionary) didn't reflect that.
>

Wasn't it you who recently fixed another word not marked with the correct
immediacy?  It'll only take you a few minutes to check them.

My Forth, so far, has these words marked as immediate:

; ( [ IF THEN BEGIN AGAIN UNTIL AHEAD LITERAL [COMPILE]
['] ELSE WHILE REPEAT DO ?DO LOOP +LOOP LEAVE [CHAR]
ASCII S" ." .( POSTPONE RECURSE \ TO IS 2LITERAL 2CONSTANT

and also the special fig-Forth word null 'X' that escapes from INTERPRET.

You can (re)read this post for what fig-Forth marks as immediate:
http://groups.google.com/group/comp.lang.forth/msg/69f0fa5a8d5a4447


Rod Pemberton

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

#11669

On 4/26/12 12:31 PM, Rod Pemberton wrote:
...
> My Forth, so far, has these words marked as immediate:
>
> ; ( [ IF THEN BEGIN AGAIN UNTIL AHEAD LITERAL [COMPILE]
> ['] ELSE WHILE REPEAT DO ?DO LOOP +LOOP LEAVE [CHAR]
> ASCII S" ." .( POSTPONE RECURSE \ TO IS 2LITERAL 2CONSTANT

IMO IS should not be IMMEDIATE, assuming you're using it to change 
DEFERs per common practice. I note that the description of IS in 
Forth200x specifies Compilation Semantics, but fail to understand why.

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]

#11671

On Apr 26, 8:32 pm, "Elizabeth D. Rather" <erat...@forth.com> wrote:
> IMO IS should not be IMMEDIATE, assuming you're using it to change
> DEFERs per common practice. I note that the description of IS in
> Forth200x specifies Compilation Semantics, but fail to understand why.

It seems from the Proposal that during the RfD stage, there were
systems that did it that way. The state smartedness can be avoided by
using DEFER! ...
   DEFER Beep
   : Set-Beep ' ['] Beep DEFER! ;
...
   : MyBeep ... ;

   Set-Beep MyBeep

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

#11672

"Elizabeth D. Rather" <erather@forth.com> writes:
>IMO IS should not be IMMEDIATE, assuming you're using it to change 
>DEFERs per common practice. I note that the description of IS in 
>Forth200x specifies Compilation Semantics, but fail to understand why.

defer foo
: bar is foo ;
' + bar

Here IS in many implementations parses FOO during compilation.  If we
want to allow this implementation approach, we need to specify
parsing compilation semantics.

Why not define IS and [IS]?  I would have preferred that, but the more
common practice was to let IS behave like TO.  However, the proposal
also includes DEFER! for when you need to do something where the
hidden complexity of IS gets in the way.

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

#11698

On 4/26/12 11:10 PM, Anton Ertl wrote:
> "Elizabeth D. Rather"<erather@forth.com>  writes:
>> IMO IS should not be IMMEDIATE, assuming you're using it to change
>> DEFERs per common practice. I note that the description of IS in
>> Forth200x specifies Compilation Semantics, but fail to understand why.
>
> defer foo
> : bar is foo ;
> ' + bar
>
> Here IS in many implementations parses FOO during compilation.  If we
> want to allow this implementation approach, we need to specify
> parsing compilation semantics.
>
> Why not define IS and [IS]?  I would have preferred that, but the more
> common practice was to let IS behave like TO.  However, the proposal
> also includes DEFER! for when you need to do something where the
> hidden complexity of IS gets in the way.

Thanks. That's what I get for posting late at night when not thinking 
clearly.

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]

#11675

"Elizabeth D. Rather" <erather@forth.com> wrote in message
news:2fWdnehCC7ukdATSnZ2dnUVZ_r2dnZ2d@supernews.com...
> On 4/26/12 12:31 PM, Rod Pemberton wrote:
...

> > My Forth, so far, has these words marked as immediate:
> >
> > ; ( [ IF THEN BEGIN AGAIN UNTIL AHEAD LITERAL [COMPILE]
> > ['] ELSE WHILE REPEAT DO ?DO LOOP +LOOP LEAVE [CHAR]
> > ASCII S" ." .( POSTPONE RECURSE \ TO IS 2LITERAL 2CONSTANT
>
> IMO IS should not be IMMEDIATE, assuming you're using it to change
> DEFERs per common practice. I note that the description of IS in
> Forth200x specifies Compilation Semantics, but fail to understand why.
>

As I noted elsewhere recently, the definition of IS in the c.l.f. archives
for IS (used with DEFER) and TO (used with VALUE) are *identical*.  So, I
don't understand why IS would be non-IMMEDIATE but TO should be IMMEDIATE.

The example below works for gForth, Win32Forth, bigForth.  How would that
work if IS is not IMMEDIATE?

DEFER PARITY
: ?EVEN 2 MOD 0= IF ." EVEN" THEN ;
: ?ODD 2 MOD 0<> IF ." ODD" THEN ;
: EVEN ['] ?EVEN IS PARITY ;
: ODD ['] ?ODD IS PARITY ;
: T 5 0 DO I PARITY LOOP

ODD T
EVEN T


Rod Pemberton

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

#11697

"Rod Pemberton" <do_not_have@notemailnot.cmm> wrote in message
news:jndp4h$i07$1@speranza.aioe.org...
> "Elizabeth D. Rather" <erather@forth.com> wrote in message
> news:2fWdnehCC7ukdATSnZ2dnUVZ_r2dnZ2d@supernews.com...
> > On 4/26/12 12:31 PM, Rod Pemberton wrote:
...

> > > My Forth, so far, has these words marked as immediate:
> > >
> > > ; ( [ IF THEN BEGIN AGAIN UNTIL AHEAD LITERAL [COMPILE]
> > > ['] ELSE WHILE REPEAT DO ?DO LOOP +LOOP LEAVE [CHAR]
> > > ASCII S" ." .( POSTPONE RECURSE \ TO IS 2LITERAL 2CONSTANT
> >
> > IMO IS should not be IMMEDIATE, assuming you're using it to change
> > DEFERs per common practice. I note that the description of IS in
> > Forth200x specifies Compilation Semantics, but fail to understand why.
> >
>
> As I noted elsewhere recently, the definition of IS in the c.l.f. archives
> for IS (used with DEFER) and TO (used with VALUE) are *identical*.  So, I
> don't understand why IS would be non-IMMEDIATE but TO should be IMMEDIATE.
>
> The example below works for gForth, Win32Forth, bigForth.  How would that
> work if IS is not IMMEDIATE?
>
> [example]

Oh, it seems Anton answered that ...  We were just discussing it, so sorry I
missed that.  You're wanting state-aware IS to be non-state-aware IS and
compile-time [IS] .  Just put a message in the specification that [IS] must
be defined in preparation for the next specification where IS won't be
state-aware ...  Say it's acceptable for both for now.  It's just a matter
of someone in charge making the decision as to which type of IS , or both
types, that a system can support now and in the future.  If done quickly, it
could "prevent" another state-aware tragedy, if such a thing existed.


Rod Pemberton

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

#11676

Any word that parses at compile time /must/ be IMMEDIATE because that's currently the only way to provide other compilation semantics. If you mean that a word containing IS should be able to take the xt to be set as a runtime parameter, then I agree.

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

#11681

On Fri, 27 Apr 2012 02:54:04 -0700 (PDT), JennyB
<jennybrien@googlemail.com> wrote:

>Any word that parses at compile time /must/ be IMMEDIATE because that's
>currently the only way to provide other compilation semantics.

Not quite. It's the only standard way. IMMEDIATE is actually not good
enough because it imposes that the compilation and interpretation
behaviours are the same. This is often not what is needed.

Until a Forth 202x team gets to grips with compilation, the
current position of a variety of notations to separate
interpretation and compilation behaviours will remain.

Stephen

-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

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

#11661

On Apr 26, 3:54 pm, Coos Haak <chfo...@hccnet.nl> wrote:
> Op Thu, 26 Apr 2012 02:18:05 -0700 (PDT) schreef Mark Wills:
>
> <snip>> Rod, my earlier code was misleading - sorry. In my system ['] wasn't
> > immediate (though it still worked).
>
> Prove it, ['] has to be immediate, otherwise it could not find the next
> word during compiling.
>
> --
> Coos
>
> CHForth, 16 bit DOS applicationshttp://home.hccnet.nl/j.j.haak/forth.html

Sure. As it *was* written, ['] was just a normal word that got
compiled into the definition. The word following ['] also got compiled
into the definition (by the compiler). At run time, ['] would execute,
look at the next cell in memory, and push its value to the stack, then
skip over it. It was as simple as:

INCT STACK ; create a cell space on the stack
MOV *PC+,*STACK ; move cfa of the cell the pc is pointing to to the
stack

The post increment on the PC neatly skips over the word.

Very neat. Trouble is, it doesn't work for immediate words, and I only
actually noticed this morning. I've now changed it to the more
standard BL WORD FIND yadda yadda...

Mark

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

#11662

Op Thu, 26 Apr 2012 12:18:32 -0700 (PDT) schreef Mark Wills:

> On Apr 26, 3:54 pm, Coos Haak <chfo...@hccnet.nl> wrote:
>> Op Thu, 26 Apr 2012 02:18:05 -0700 (PDT) schreef Mark Wills:
>>
>> <snip>> Rod, my earlier code was misleading - sorry. In my system ['] wasn't
>>> immediate (though it still worked).
>>
>> Prove it, ['] has to be immediate, otherwise it could not find the next
>> word during compiling.
>>
>> --
>> Coos
>>
>> CHForth, 16 bit DOS applicationshttp://home.hccnet.nl/j.j.haak/forth.html
> 
> Sure. As it *was* written, ['] was just a normal word that got
> compiled into the definition. The word following ['] also got compiled
> into the definition (by the compiler). At run time, ['] would execute,
> look at the next cell in memory, and push its value to the stack, then
> skip over it. It was as simple as:
> 
> INCT STACK ; create a cell space on the stack
> MOV *PC+,*STACK ; move cfa of the cell the pc is pointing to to the
> stack
> 
> The post increment on the PC neatly skips over the word.
> 
> Very neat. Trouble is, it doesn't work for immediate words, and I only
> actually noticed this morning. I've now changed it to the more
> standard BL WORD FIND yadda yadda...
> 
> Mark

Thanks, I understand now. It's a bit like the word COMPILE in pre-ANS 
Forth.

-- 
Coos

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

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

#11645

Rod Pemberton <do_not_have@notemailnot.cmm> wrote:
> "Andrew Haley" <andrew29@littlepinkcloud.invalid> wrote in message
> news:nfydnXXFXaBUgAXSnZ2dnUVZ_vednZ2d@supernews.com...
> ...
> 
>> [...] in general, state-smartness makes
>> programs harder to understand, [...]
> 
> That claim comes up now and again.  I don't understand that claim at all.
> Can someone explain that?
> 
> AISI, state-aware words work the *exactly* same way interactively as when
> compiled.  How is that difficult to understand?  That seems *ideal* to me.
> The word has zero ambiguity.

No, that's not true.  They *seem* to work interactively the same way
as they do when compiled but things go wrong when you try to re-use
them as factors in other words.

> In fig-Forth, ' (tick) had one behavior, be it compiled or
> interactive.  What's wrong with that?  Why did Forth need to
> separate state-aware ' (tick) into interactive ' (tick) and compile
> ['] ?

You are writing a compiling word that ticks a word from the input
stream and EXECUTEs it.  The obvious way to do that is

  : now   ' execute ;  immediate

And, in Standard Forth, this works:

: now ' execute ; immediate  ok
: hello ." hello" cr ;  ok 
: z now hello ; hello
 ok

If ' is state-smart this doesn't work.  Simply POSTPONEing ' doesn't
help:

: ' ' state @ if postpone literal then ;
: now   postpone ' execute ;
: z now >>>hello<<< ;
Backtrace:
$7FCA8C53C158 execute

' is such a useful factor for so many things that burying it in a
state-smart word really is the wrong thing to do.

> With non-state-aware words, you have to remember that a word doesn't
> work *as expected* when compiled and you have to use another word.

No, the problem is that it *appears* to work as expected until it
doesn't.

>> and that state-smart words are hard to use as factors.
> 
> Yes, I understand that.  You can't easily re-use parts of a
> state-aware word.  But, does that really justify creating the syntax
> malarky and code obfuscation due to the multiple words for
> non-state-awareness?

Factoring is the central principle of Forth.  Anything that prevents
factoring is therefore to be avoided like the plague.

More examples in Anton's _state -- Why it is Evil and How to Exorcise
it_ at http://www.dec.bournemouth.ac.uk/forth/euro/ef98/ertl98.pdf

Andrew.

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

#11603

Rod Pemberton <do_not_have@notemailnot.cmm> wrote:
> "A. K." <akk@nospam.org> wrote in message
> news:4f958ae9$0$7610$9b4e6d93@newsspool1.arcor-online.net...
>> 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.
>>
> 
> Ok, I reread the thread, but I'm not following ...  None of the replies seem
> to have anything to do with your initial question, AIUI.
> 
> Wasn't this ("Reformulation of 'STATE @ IF'") already solved with ' (tick)?
> 
> Tick was state-smart in fig-Forth, but was then made state-dumb for
> later forths.  It was split into ' (tick) and ['] .  Other
> state-smart words were also broken into or implemented as an
> interpret version and a "compile-time" version.  The compile-time
> versions use brackets around the name [ ] .  Later on, they merged
> COMPILE and [COMPILE] into state-aware POSTPONE .

POSTPONE isn't state-aware.

> Given the [] notation for compile-time versions of words.  I'd split IS into
> IS and [IS] .  That will eliminate the STATE @ IF ... ELSE ... THEN
> construct. 

Exactly.  Then all this pain will just go away.

> I saw an old discussion in c.l.f. that claimed "POSTPONE TO" is not valid
> for ANS Forth.

'sright.

Andrew.

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

#11630

"Andrew Haley" <andrew29@littlepinkcloud.invalid> wrote in message
news:Evqdnco6j4dqIwrSnZ2dnUVZ_j6dnZ2d@supernews.com...
> Rod Pemberton <do_not_have@notemailnot.cmm> wrote:
...

> > Later on, they merged
> > COMPILE and [COMPILE] into state-aware POSTPONE .
>
> POSTPONE isn't state-aware.
>

It's true that POSTPONE is not explicitly aware of STATE.  But, it is
state-aware.  It's aware of words marked IMMEDIATE.  IMMEDIATE is used to
change the behavior of words when used with other words that change STATE.
POSTPONE has to be aware of which words are IMMEDIATE in order to change the
way they are compiled for when those compiled words are used in STATE-aware
situations.  If POSTPONE wasn't state-aware, as you've stated, it wouldn't
have to check for immediacy at all.  I.e., COMPILE and [COMPILE] aren't
state-aware.

> > I saw an old discussion in c.l.f. that claimed "POSTPONE TO" is not
> > valid for ANS Forth.
>
> 'sright.

Why?  I don't see why not.  It works for my ITC Forth ...  Why is TO any
different when used with POSTPONE than other words?


Rod Pemberton

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

#11632

On 4/25/12 9:29 AM, Rod Pemberton wrote:
> "Andrew Haley"<andrew29@littlepinkcloud.invalid>  wrote in message
> news:Evqdnco6j4dqIwrSnZ2dnUVZ_j6dnZ2d@supernews.com...
>> Rod Pemberton<do_not_have@notemailnot.cmm>  wrote:
> ...
>
>>> Later on, they merged
>>> COMPILE and [COMPILE] into state-aware POSTPONE .
>>
>> POSTPONE isn't state-aware.
>>
>
> It's true that POSTPONE is not explicitly aware of STATE.  But, it is
> state-aware.  It's aware of words marked IMMEDIATE.  IMMEDIATE is used to
> change the behavior of words when used with other words that change STATE.
> POSTPONE has to be aware of which words are IMMEDIATE in order to change the
> way they are compiled for when those compiled words are used in STATE-aware
> situations.  If POSTPONE wasn't state-aware, as you've stated, it wouldn't
> have to check for immediacy at all.  I.e., COMPILE and [COMPILE] aren't
> state-aware.

Being "state aware" means the word itself behaves differently in 
compilation mode than in interpret mode. POSTPONE is definitely not 
state-aware. Checking the IMMEDIATE bit in a word that is being 
postponed is part of its definition, but doesn't mean it's state-aware.

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]

#11646

Rod Pemberton <do_not_have@notemailnot.cmm> wrote:
> "Andrew Haley" <andrew29@littlepinkcloud.invalid> wrote in message
> news:Evqdnco6j4dqIwrSnZ2dnUVZ_j6dnZ2d@supernews.com...
>> Rod Pemberton <do_not_have@notemailnot.cmm> wrote:
> ...
> 
>> > Later on, they merged
>> > COMPILE and [COMPILE] into state-aware POSTPONE .
>>
>> POSTPONE isn't state-aware.
> 
> It's true that POSTPONE is not explicitly aware of STATE.  But, it
> is state-aware.  It's aware of words marked IMMEDIATE.

In which case it is IMMEDIATE-aware; it is certainly not state-aware.

>> > I saw an old discussion in c.l.f. that claimed "POSTPONE TO" is not
>> > valid for ANS Forth.
>>
>> 'sright.
> 
> Why?  I don't see why not.  It works for my ITC Forth ...  Why is TO
> any different when used with POSTPONE than other words?

Because there are some useful implementation techniques that don't
permit it.  It often will work when POSTPONEd, but it's not necessary
for an implementer to support it.

Andrew.

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

#11656

"Rod Pemberton" <do_not_have@notemailnot.cmm> writes:
>Why?  I don't see why not.  It works for my ITC Forth ...  Why is TO any
>different when used with POSTPONE than other words?

The standard does not explain, but my guess is that it's there to
allow STATE-smart implementations of TO.  Otherwise, on such a system
you get the wrong result when you perform the compilation semantics of
TO (what you get with POSTPONE) in interpretation state.  E.g,:

: [to] postpone to ; immediate
0 value foo
: bar [ [to] foo ] ;
5 bar
foo . \ prints 5

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

#11683

In article <2012Apr26.183554@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>"Rod Pemberton" <do_not_have@notemailnot.cmm> writes:
>>Why?  I don't see why not.  It works for my ITC Forth ...  Why is TO any
>>different when used with POSTPONE than other words?
>
>The standard does not explain, but my guess is that it's there to
>allow STATE-smart implementations of TO.  Otherwise, on such a system
>you get the wrong result when you perform the compilation semantics of
>TO (what you get with POSTPONE) in interpretation state.  E.g,:
>
>: [to] postpone to ; immediate
>0 value foo
>: bar [ [to] foo ] ;
>5 bar
>foo . \ prints 5

This is the background of the rule "TO parses the following word".

A nasty situation could occur when TO is used in implementing other
data structures like arrays

1234 TO 17 TABLE
17 TABLE .
1234 OK

Now of course if you do that you also want
VALUE INDEX

17 TO INDEX

1234 TO INDEX TABLE
This goes terribly wrong, the 1234 goes into INDEX

The correct way would be
        1234 INDEX TO TABLE
which is much worse than the straightforward
        1234   INDEX @ TABLE    !

(Diehards went on to stack the state of the TO message:
        1234 TO [[ INDEX ]] TABLE
)

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

[toc] | [prev] | [standalone]

Page 4 of 4 — ← Prev page 1 2 3 [4]

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

csiph-web