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

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

Test of COMPILE,

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

Contents

  Test of COMPILE, Krishna Myneni <krishna.myneni@ccreweb.org> - 2011-11-26 08:20 -0800
    Re: Test of COMPILE, Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-11-26 11:36 -0600
      Re: Test of COMPILE, Krishna Myneni <krishna.myneni@ccreweb.org> - 2011-11-26 09:44 -0800
      Re: Test of COMPILE, Krishna Myneni <krishna.myneni@ccreweb.org> - 2011-11-26 12:14 -0800
        Re: Test of COMPILE, Alex McDonald <blog@rivadpm.com> - 2011-11-26 15:08 -0800
          Re: Test of COMPILE, Krishna Myneni <krishna.myneni@ccreweb.org> - 2011-11-26 16:03 -0800
            Re: Test of COMPILE, Krishna Myneni <krishna.myneni@ccreweb.org> - 2011-11-26 16:12 -0800
            Re: Test of COMPILE, "Elizabeth D. Rather" <erather@forth.com> - 2011-11-26 17:10 -1000
              Re: Test of COMPILE, Krishna Myneni <krishna.myneni@ccreweb.org> - 2011-11-26 19:33 -0800
                Re: Test of COMPILE, "Elizabeth D. Rather" <erather@forth.com> - 2011-11-26 18:28 -1000
                Re: Test of COMPILE, anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-11-27 14:02 +0000
                  Re: Test of COMPILE, Krishna Myneni <krishna.myneni@ccreweb.org> - 2011-11-27 08:42 -0800
                Re: Test of COMPILE, BruceMcF <agila61@netscape.net> - 2011-11-27 09:08 -0800
            Re: Test of COMPILE, Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-11-27 04:21 -0600
    Re: Test of COMPILE, mhx@iae.nl (Marcel Hendrix) - 2011-11-26 18:41 +0200
      Re: Test of COMPILE, Krishna Myneni <krishna.myneni@ccreweb.org> - 2011-11-26 09:51 -0800
        Re: Test of COMPILE, Bernd Paysan <bernd.paysan@gmx.de> - 2011-11-26 21:31 +0100
          Re: Test of COMPILE, Krishna Myneni <krishna.myneni@ccreweb.org> - 2011-11-26 14:09 -0800
        Re: Test of COMPILE, anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-11-27 14:17 +0000
      Re: Test of COMPILE, Alex McDonald <blog@rivadpm.com> - 2011-11-26 10:01 -0800
        Re: Test of COMPILE, mhx@iae.nl (Marcel Hendrix) - 2011-11-26 20:25 +0200
          Re: Test of COMPILE, Alex McDonald <blog@rivadpm.com> - 2011-11-26 15:04 -0800
        Re: Test of COMPILE, Krishna Myneni <krishna.myneni@ccreweb.org> - 2011-11-26 11:23 -0800
          Re: Test of COMPILE, Alex McDonald <blog@rivadpm.com> - 2011-11-26 14:48 -0800
            Re: Test of COMPILE, Krishna Myneni <krishna.myneni@ccreweb.org> - 2011-11-26 16:00 -0800
              Re: Test of COMPILE, Coos Haak <chforth@hccnet.nl> - 2011-11-27 02:09 +0100
                Re: Test of COMPILE, Krishna Myneni <krishna.myneni@ccreweb.org> - 2011-11-26 18:11 -0800
                  Re: Test of COMPILE, Gerry <gerry@jackson9000.fsnet.co.uk> - 2011-11-27 00:09 -0800
                    Re: Test of COMPILE, Mark Wills <forthfreak@gmail.com> - 2011-11-27 00:47 -0800
                      Re: Test of COMPILE, mhx@iae.nl (Marcel Hendrix) - 2011-11-27 10:48 +0200
                        Re: Test of COMPILE, Mark Wills <forthfreak@gmail.com> - 2011-11-27 05:24 -0800
                    Re: Test of COMPILE, Albert van der Horst <albert@spenarnc.xs4all.nl> - 2011-11-27 21:08 +0000
                      Re: Test of COMPILE, Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2011-11-27 21:18 +0000
                      Re: Test of COMPILE, BruceMcF <agila61@netscape.net> - 2011-11-27 16:58 -0800
                        Re: Test of COMPILE, anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-11-28 12:03 +0000
                    Re: Test of COMPILE, Krishna Myneni <krishna.myneni@ccreweb.org> - 2011-11-27 15:00 -0800
                      Re: Test of COMPILE, Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2011-11-28 11:39 +0000
                        Re: Test of COMPILE, Alex McDonald <blog@rivadpm.com> - 2011-11-28 04:52 -0800
                          Re: Test of COMPILE, Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2011-11-28 18:05 +0000
                            Re: Test of COMPILE, Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-11-28 12:45 -0600
                              Re: Test of COMPILE, Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2011-11-28 20:17 +0000
                                Re: Test of COMPILE, Alex McDonald <blog@rivadpm.com> - 2011-11-28 14:22 -0800
                                  Re: Test of COMPILE, Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2011-11-29 08:08 +0000
                                Re: Test of COMPILE, Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-11-29 04:49 -0600
                                  Re: Test of COMPILE, Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2011-11-29 16:00 +0000
                                    Re: Test of COMPILE, Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-11-30 10:45 -0600
                                      Re: Test of COMPILE, Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2011-12-01 08:58 +0000
                                  Re: Test of COMPILE, BruceMcF <agila61@netscape.net> - 2011-12-01 09:46 -0800
                                    Re: Test of COMPILE, Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-01 12:00 -0600
                              Re: Test of COMPILE, BruceMcF <agila61@netscape.net> - 2011-11-28 12:29 -0800
                                Re: Test of COMPILE, Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-11-29 04:53 -0600
                                  Re: Test of COMPILE, anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-11-29 11:04 +0000
                                    Re: Test of COMPILE, Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-11-29 05:42 -0600
                                      Re: Test of COMPILE, anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-11-29 15:46 +0000
                                        Re: Test of COMPILE, Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-11-29 09:59 -0600
                                        Re: Test of COMPILE, "Elizabeth D. Rather" <erather@forth.com> - 2011-11-29 08:55 -1000
                                        Re: Test of COMPILE, "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-11-30 05:58 -0500
                                          Re: Test of COMPILE, Alex McDonald <blog@rivadpm.com> - 2011-11-30 03:07 -0800
                                          Re: Test of COMPILE, BruceMcF <agila61@netscape.net> - 2011-11-30 07:54 -0800
                                      Re: Test of COMPILE, Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2011-11-29 15:50 +0000
                                        Re: Test of COMPILE, Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-11-29 10:01 -0600
                                        Re: Test of COMPILE, Tarkin <tarkin000@gmail.com> - 2011-11-29 13:07 -0800
                                  Re: Test of COMPILE, BruceMcF <agila61@netscape.net> - 2011-11-29 17:04 -0800
                                    Re: Test of COMPILE, "Elizabeth D. Rather" <erather@forth.com> - 2011-11-29 15:52 -1000
                                      Re: Test of COMPILE, BruceMcF <agila61@netscape.net> - 2011-11-29 21:29 -0800
                                        Re: Test of COMPILE, "Elizabeth D. Rather" <erather@forth.com> - 2011-11-29 19:52 -1000
                                          Re: Test of COMPILE, BruceMcF <agila61@netscape.net> - 2011-11-30 07:49 -0800
                                            Re: Test of COMPILE, Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-11-30 10:19 -0600
                                              Re: Test of COMPILE, BruceMcF <agila61@netscape.net> - 2011-11-30 12:19 -0800
                                                Re: Test of COMPILE, Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-11-30 14:31 -0600
                                                  Re: Test of COMPILE, BruceMcF <agila61@netscape.net> - 2011-12-01 10:36 -0800
                                                    Re: Test of COMPILE, Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-01 13:08 -0600
                                                      Re: Test of COMPILE, BruceMcF <agila61@netscape.net> - 2011-12-01 22:04 -0800
                        Re: Test of COMPILE, Krishna Myneni <krishna.myneni@ccreweb.org> - 2011-11-28 05:05 -0800
                      Re: Test of COMPILE, Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-11-28 06:25 -0600
                Re: Test of COMPILE, mhx@iae.nl (Marcel Hendrix) - 2011-11-27 08:01 +0200
                  Re: Test of COMPILE, Coos Haak <chforth@hccnet.nl> - 2011-11-27 14:09 +0100

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

#7502

Alex McDonald <blog@rivadpm.com> writes Re: Test of COMPILE,
[..]
> My compiler optimizes the whole lot away in the first case, 
[..]

I guess you have in some way made sure that the Forth code 
executed between [ and ], if it affects the definition in
progress, has no other way then to go through COMPILE, . 

For iForth I can not prove this because code and data are 
in the same memory area and therefore [ $C9 C, ] is a
counterexample. Even if the areas were separated, there'd 
be kernel words to write to code space, (e.g. the assembler) 
making optimization impossible. 

Although AFAIR it is not allowed to manipulate code space 
when the definition is not yet finished, that is theory, 
and I felt sure existing programs were doing this.

It might be a good idea to simply not support such practices
anymore.

-marcel

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

#7511

On Nov 26, 6:25 pm, m...@iae.nl (Marcel Hendrix) wrote:
> Alex McDonald <b...@rivadpm.com> writes Re: Test of COMPILE,
> [..]> My compiler optimizes the whole lot away in the first case,
>
> [..]
>
> I guess you have in some way made sure that the Forth code
> executed between [ and ], if it affects the definition in
> progress, has no other way then to go through COMPILE, .

There are no standard words that can affect the definition in
progress, since it's not being built in the area pointed at by HERE --
with the exception of COMPILE, CODE : and :NONAME. LITERAL is not
allowed in interpret mode.

: test 1 2 3 [ : test2 10 ; ] 4 ;

TEST is undefined, since TEST2 has usurped it. The compiler carries on
quite happily, wasting code space, and TEST2 ends up as valid and
executable code preceded and followed by the wreckage of TEST.

>
> For iForth I can not prove this because code and data are
> in the same memory area and therefore [ $C9 C, ] is a
> counterexample. Even if the areas were separated, there'd
> be kernel words to write to code space, (e.g. the assembler)
> making optimization impossible.
>
> Although AFAIR it is not allowed to manipulate code space
> when the definition is not yet finished, that is theory,
> and I felt sure existing programs were doing this.

It's not deliberate in my compiler, just a side effect of separate
code, data and header areas.

>
> It might be a good idea to simply not support such practices
> anymore.
>
> -marcel

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

#7503

On Nov 26, 12:01 pm, Alex McDonald <b...@rivadpm.com> wrote:
> On Nov 26, 4:41 pm, m...@iae.nl (Marcel Hendrix) wrote:
>
>
>
>
>
>
>
>
>
> > Krishna Myneni <krishna.myn...@ccreweb.org> wrote Re: Test of COMPILE,
> > [..]> 2 constant two  ok
> > > : test [ ' two compile, 3 ] - 1 = ;
> > [..]
> > > Gforth fails to load the definition of TEST
>
> > [..]
>
> > Don't you mean
>
> > 2 constant two
> > : test [ ' two compile, 3 ] literal 1- = ;
>
> > Accepted by Win32Forth, VfxForth, SwiftForth and gForth.
>
> > iForth rejects it because the interpretation semantics of
> > COMPILE, are undefined. After : COMPILE, COMPILE, ; it
> > `works` to.
>
> > All compilers accept ...
>
> > : test [ ' two compile, -12 allot 3 ] literal 1- = ;
>
> > ... with various interesting results. E.g. VfxForth seems not
> > to notice the -12 allot at all, SwiftForth exits silently and
> > gForth gives a good error report (It has head damage but not
> > critical).
>
> > -marcel
>
> My compiler optimizes the whole lot away in the first case, and does
> what's asked of it in the second case. That's because the headers and
> the code are maintained in separate sections from data at HERE.
>
> STC Experimental Version: 0.05.01 Build: 439
> 2 constant two  ok
> : test [ ' two compile, 3 ] literal 1- = ;   ok
> test . -1  ok
> see test
> : test ( ? -- ? )               \ std call compiles
>                                 \ len=9 type=20
>                                 \ in (console)
> ( $424114 ' test )              mov   $-4 [ebp], eax         \ 8945FC
> ( $424117 ' test+$3 )           or    eax, # $-1             \ 83C8FF
> ( $42411A ' test+$6 )           sub   ebp, # $4              \ 83ED04
> ( $42411D ' test+$9 )           ret   near                   \ C3
> ( end ) ok
>
> here . 8414048  ok
> : test [ ' two compile, -12 allot 3 ] literal 1- = ;
>       ^
> Warning -4100 test is redefined  ok
> here . 8414036  ok
> test . -1  ok

What does your compiler do with the following?

--

\ Test compilecomma
\
: ?passed ( flag -- ) IF ." Passed." ELSE ." Failed!"  THEN ;

: test1 [ ' true compile, ] ;
cr .( test1 ... ) test1 ?passed

2 constant two
: test2 [ ' two compile, ] 1- ;
cr .( test2 ... ) test2 ?passed

: test3 [ ' two compile, 3 ] - 1 = ;
cr .( test3 ... ) test3 ?passed

: test4a compile, ; immediate
: test4 [ ' true ] test4a ;
cr .( test4 ... ) test4 ?passed

--
Krishna

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

#7510

On Nov 26, 7:23 pm, Krishna Myneni <krishna.myn...@ccreweb.org> wrote:
> On Nov 26, 12:01 pm, Alex McDonald <b...@rivadpm.com> wrote:
>
>
>
>
>
>
>
>
>
> > On Nov 26, 4:41 pm, m...@iae.nl (Marcel Hendrix) wrote:
>
> > > Krishna Myneni <krishna.myn...@ccreweb.org> wrote Re: Test of COMPILE,
> > > [..]> 2 constant two  ok
> > > > : test [ ' two compile, 3 ] - 1 = ;
> > > [..]
> > > > Gforth fails to load the definition of TEST
>
> > > [..]
>
> > > Don't you mean
>
> > > 2 constant two
> > > : test [ ' two compile, 3 ] literal 1- = ;
>
> > > Accepted by Win32Forth, VfxForth, SwiftForth and gForth.
>
> > > iForth rejects it because the interpretation semantics of
> > > COMPILE, are undefined. After : COMPILE, COMPILE, ; it
> > > `works` to.
>
> > > All compilers accept ...
>
> > > : test [ ' two compile, -12 allot 3 ] literal 1- = ;
>
> > > ... with various interesting results. E.g. VfxForth seems not
> > > to notice the -12 allot at all, SwiftForth exits silently and
> > > gForth gives a good error report (It has head damage but not
> > > critical).
>
> > > -marcel
>
> > My compiler optimizes the whole lot away in the first case, and does
> > what's asked of it in the second case. That's because the headers and
> > the code are maintained in separate sections from data at HERE.
>
> > STC Experimental Version: 0.05.01 Build: 439
> > 2 constant two  ok
> > : test [ ' two compile, 3 ] literal 1- = ;   ok
> > test . -1  ok
> > see test
> > : test ( ? -- ? )               \ std call compiles
> >                                 \ len=9 type=20
> >                                 \ in (console)
> > ( $424114 ' test )              mov   $-4 [ebp], eax         \ 8945FC
> > ( $424117 ' test+$3 )           or    eax, # $-1             \ 83C8FF
> > ( $42411A ' test+$6 )           sub   ebp, # $4              \ 83ED04
> > ( $42411D ' test+$9 )           ret   near                   \ C3
> > ( end ) ok
>
> > here . 8414048  ok
> > : test [ ' two compile, -12 allot 3 ] literal 1- = ;
> >       ^
> > Warning -4100 test is redefined  ok
> > here . 8414036  ok
> > test . -1  ok
>
> What does your compiler do with the following?
>
> --
>
> \ Test compilecomma
> \
> : ?passed ( flag -- ) IF ." Passed." ELSE ." Failed!"  THEN ;
>
> : test1 [ ' true compile, ] ;
> cr .( test1 ... ) test1 ?passed
>
> 2 constant two
> : test2 [ ' two compile, ] 1- ;
> cr .( test2 ... ) test2 ?passed
>
> : test3 [ ' two compile, 3 ] - 1 = ;
> cr .( test3 ... ) test3 ?passed
>
> : test4a compile, ; immediate
> : test4 [ ' true ] test4a ;
> cr .( test4 ... ) test4 ?passed
>
> --
> Krishna

STC Experimental Version: 0.05.01 Build: 440
\ Test compilecomma  ok
\  ok
: ?passed ( flag -- ) IF ." Passed." ELSE ." Failed!"  THEN ;  ok
 ok
: test1 [ ' true compile, ] ;  ok
cr .( test1 ... ) test1 ?passed
test1 ... Passed. ok
 ok
2 constant two  ok
: test2 [ ' two compile, ] 1- ;  ok
cr .( test2 ... ) test2 ?passed
test2 ... Passed. ok
 ok
: test3 [ ' two compile, 3 ] - 1 = ;
                                   ^
Error -320 ; stack changed
: test4a compile, ; immediate  ok
: test4 [ ' true ] test4a ;  ok
cr .( test4 ... ) test4 ?passed
test4 ... Passed. ok

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

#7514

On Nov 26, 4:48 pm, Alex McDonald <b...@rivadpm.com> wrote:
> On Nov 26, 7:23 pm, Krishna Myneni <krishna.myn...@ccreweb.org> wrote:
>
>
>
> > On Nov 26, 12:01 pm, Alex McDonald <b...@rivadpm.com> wrote:
>
> > > On Nov 26, 4:41 pm, m...@iae.nl (Marcel Hendrix) wrote:
>
> > > > Krishna Myneni <krishna.myn...@ccreweb.org> wrote Re: Test of COMPILE,
> > > > [..]> 2 constant two  ok
> > > > > : test [ ' two compile, 3 ] - 1 = ;
> > > > [..]
> > > > > Gforth fails to load the definition of TEST
>
> > > > [..]
>
> > > > Don't you mean
>
> > > > 2 constant two
> > > > : test [ ' two compile, 3 ] literal 1- = ;
>
> > > > Accepted by Win32Forth, VfxForth, SwiftForth and gForth.
>
> > > > iForth rejects it because the interpretation semantics of
> > > > COMPILE, are undefined. After : COMPILE, COMPILE, ; it
> > > > `works` to.
>
> > > > All compilers accept ...
>
> > > > : test [ ' two compile, -12 allot 3 ] literal 1- = ;
>
> > > > ... with various interesting results. E.g. VfxForth seems not
> > > > to notice the -12 allot at all, SwiftForth exits silently and
> > > > gForth gives a good error report (It has head damage but not
> > > > critical).
>
> > > > -marcel
>
> > > My compiler optimizes the whole lot away in the first case, and does
> > > what's asked of it in the second case. That's because the headers and
> > > the code are maintained in separate sections from data at HERE.
>
> > > STC Experimental Version: 0.05.01 Build: 439
> > > 2 constant two  ok
> > > : test [ ' two compile, 3 ] literal 1- = ;   ok
> > > test . -1  ok
> > > see test
> > > : test ( ? -- ? )               \ std call compiles
> > >                                 \ len=9 type=20
> > >                                 \ in (console)
> > > ( $424114 ' test )              mov   $-4 [ebp], eax         \ 8945FC
> > > ( $424117 ' test+$3 )           or    eax, # $-1             \ 83C8FF
> > > ( $42411A ' test+$6 )           sub   ebp, # $4              \ 83ED04
> > > ( $42411D ' test+$9 )           ret   near                   \ C3
> > > ( end ) ok
>
> > > here . 8414048  ok
> > > : test [ ' two compile, -12 allot 3 ] literal 1- = ;
> > >       ^
> > > Warning -4100 test is redefined  ok
> > > here . 8414036  ok
> > > test . -1  ok
>
> > What does your compiler do with the following?
>
> > --
>
> > \ Test compilecomma
> > \
> > : ?passed ( flag -- ) IF ." Passed." ELSE ." Failed!"  THEN ;
>
> > : test1 [ ' true compile, ] ;
> > cr .( test1 ... ) test1 ?passed
>
> > 2 constant two
> > : test2 [ ' two compile, ] 1- ;
> > cr .( test2 ... ) test2 ?passed
>
> > : test3 [ ' two compile, 3 ] - 1 = ;
> > cr .( test3 ... ) test3 ?passed
>
> > : test4a compile, ; immediate
> > : test4 [ ' true ] test4a ;
> > cr .( test4 ... ) test4 ?passed
>
> > --
> > Krishna
>
> STC Experimental Version: 0.05.01 Build: 440
> \ Test compilecomma  ok
> \  ok
> : ?passed ( flag -- ) IF ." Passed." ELSE ." Failed!"  THEN ;  ok
>  ok
> : test1 [ ' true compile, ] ;  ok
> cr .( test1 ... ) test1 ?passed
> test1 ... Passed. ok
>  ok
> 2 constant two  ok
> : test2 [ ' two compile, ] 1- ;  ok
> cr .( test2 ... ) test2 ?passed
> test2 ... Passed. ok
>  ok
> : test3 [ ' two compile, 3 ] - 1 = ;
>                                    ^
> Error -320 ; stack changed
> : test4a compile, ; immediate  ok
> : test4 [ ' true ] test4a ;  ok
> cr .( test4 ... ) test4 ?passed
> test4 ... Passed. ok

Thanks for running the tests. It looks as though most Forth systems
support interpretation semantics for COMPILE, with consistent
behavior. Even in iForth, it appears to be trivial to redefine
COMPILE, to obtain the same behavior in interpretation state.

The one test that fails to compile, above, also seems to be pretty
consistent in failing across various Forth systems, with the exception
of my system. Although, I don't understand yet what it is about the
Forth-94 standard which precludes a colon definition from placing
something on the stack between ":" and ";".

Krishna

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

#7517

Op Sat, 26 Nov 2011 16:00:00 -0800 (PST) schreef Krishna Myneni:

<snip>
> The one test that fails to compile, above, also seems to be pretty
> consistent in failing across various Forth systems, with the exception
> of my system. Although, I don't understand yet what it is about the
> Forth-94 standard which precludes a colon definition from placing
> something on the stack between ":" and ";".
> 
> Krishna

: aap [ 3 ] ;
fails on all the Forths I tested, because of the presence of !CSP and ?CSP
or something like that.
I think this behavior is also helpful to signal unfinished control
structures:

: noot if else ;

-- 
Coos

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

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

#7518

On Nov 26, 7:09 pm, Coos Haak <chfo...@hccnet.nl> wrote:
> Op Sat, 26 Nov 2011 16:00:00 -0800 (PST) schreef Krishna Myneni:
>
> <snip>
>
> > The one test that fails to compile, above, also seems to be pretty
> > consistent in failing across various Forth systems, with the exception
> > of my system. Although, I don't understand yet what it is about the
> > Forth-94 standard which precludes a colon definition from placing
> > something on the stack between ":" and ";".
>
> > Krishna
>
> : aap [ 3 ] ;
> fails on all the Forths I tested, because of the presence of !CSP and ?CSP
> or something like that.
> I think this behavior is also helpful to signal unfinished control
> structures:
>
> : noot if else ;
>
> --
> Coos
>
> CHForth, 16 bit DOS applicationshttp://home.hccnet.nl/j.j.haak/forth.html

Apparently, the restriction is an implicit one by the allowance in
Forth-94 for the flow control stack to be the same as the data stack.
However, implementations which do not use the data stack for the flow
control stack should be able to place items onto the data stack during
word definitions, without side effects. Whether or not such a practice
has any benefits is not clear.

Also, systems which do not use the data stack to hold control
structure information during compilation can also detect incomplete
structures, e.g., in kForth:

: app [ 3 ] ;
 ok
: noot if else ;
Line 2: Compiler Error(6): Incomplete IF...THEN structure
: noot if else ;


Krishna

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

#7524

On Nov 27, 2:11 am, Krishna Myneni <krishna.myn...@ccreweb.org> wrote:
> On Nov 26, 7:09 pm, Coos Haak <chfo...@hccnet.nl> wrote:
>
>
>
> > Op Sat, 26 Nov 2011 16:00:00 -0800 (PST) schreef Krishna Myneni:
>
> > <snip>
>
> > > The one test that fails to compile, above, also seems to be pretty
> > > consistent in failing across various Forth systems, with the exception
> > > of my system. Although, I don't understand yet what it is about the
> > > Forth-94 standard which precludes a colon definition from placing
> > > something on the stack between ":" and ";".
>
> > > Krishna
>
> > : aap [ 3 ] ;
> > fails on all the Forths I tested, because of the presence of !CSP and ?CSP
> > or something like that.
> > I think this behavior is also helpful to signal unfinished control
> > structures:
>
> > : noot if else ;
>
> > --
> > Coos
>
> > CHForth, 16 bit DOS applicationshttp://home.hccnet.nl/j.j.haak/forth.html
>
> Apparently, the restriction is an implicit one by the allowance in
> Forth-94 for the flow control stack to be the same as the data stack.
> However, implementations which do not use the data stack for the flow
> control stack should be able to place items onto the data stack during
> word definitions, without side effects. Whether or not such a practice
> has any benefits is not clear.
>
> Also, systems which do not use the data stack to hold control
> structure information during compilation can also detect incomplete
> structures, e.g., in kForth:
>
> : app [ 3 ] ;
>  ok
> : noot if else ;
> Line 2: Compiler Error(6): Incomplete IF...THEN structure
> : noot if else ;
>

Forth systems requiring stack depth to be the same across a colon
definition has long been a source of irritation when writing portable
programs in ANS Forth. For example to pass data into and out of a
colon definition requires a trick such as PASS

: pass >r ' execute r> ; immediate

(if I've remembered it correctly)

Usage e.g. 3 pass : foo ... ;

Gerry

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

#7525

On Nov 27, 8:09 am, Gerry <ge...@jackson9000.fsnet.co.uk> wrote:
> On Nov 27, 2:11 am, Krishna Myneni <krishna.myn...@ccreweb.org> wrote:
>
>
>
>
>
>
>
>
>
> > On Nov 26, 7:09 pm, Coos Haak <chfo...@hccnet.nl> wrote:
>
> > > Op Sat, 26 Nov 2011 16:00:00 -0800 (PST) schreef Krishna Myneni:
>
> > > <snip>
>
> > > > The one test that fails to compile, above, also seems to be pretty
> > > > consistent in failing across various Forth systems, with the exception
> > > > of my system. Although, I don't understand yet what it is about the
> > > > Forth-94 standard which precludes a colon definition from placing
> > > > something on the stack between ":" and ";".
>
> > > > Krishna
>
> > > : aap [ 3 ] ;
> > > fails on all the Forths I tested, because of the presence of !CSP and ?CSP
> > > or something like that.
> > > I think this behavior is also helpful to signal unfinished control
> > > structures:
>
> > > : noot if else ;
>
> > > --
> > > Coos
>
> > > CHForth, 16 bit DOS applicationshttp://home.hccnet.nl/j.j.haak/forth.html
>
> > Apparently, the restriction is an implicit one by the allowance in
> > Forth-94 for the flow control stack to be the same as the data stack.
> > However, implementations which do not use the data stack for the flow
> > control stack should be able to place items onto the data stack during
> > word definitions, without side effects. Whether or not such a practice
> > has any benefits is not clear.
>
> > Also, systems which do not use the data stack to hold control
> > structure information during compilation can also detect incomplete
> > structures, e.g., in kForth:
>
> > : app [ 3 ] ;
> >  ok
> > : noot if else ;
> > Line 2: Compiler Error(6): Incomplete IF...THEN structure
> > : noot if else ;
>
> Forth systems requiring stack depth to be the same across a colon
> definition has long been a source of irritation when writing portable
> programs in ANS Forth. For example to pass data into and out of a
> colon definition requires a trick such as PASS
>
> : pass >r ' execute r> ; immediate
>
> (if I've remembered it correctly)
>
> Usage e.g. 3 pass : foo ... ;
>
> Gerry

Agreed. WRT to catching unbalanced constructs such as IF...THEN etc, I
simply implemented reference counting.  Since IF (for example) is
immediate it simply increments an 'IF' counter (a dedicated cell in
memory, not stored on the stack). THEN simply decrements the same
counter. The word ; contains checks the various reference counters. If
a counter > 0 then the appropriate error condition is reported e.g.
"Error:Unbalanced IF/THEN". It's probably not fool proof, but it does
mean that the stack is yours before, during, and after compilation!

Mark

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

#7526

Mark Wills <forthfreak@gmail.com> writes Re: Test of COMPILE,

> On Nov 27, 8:09 am, Gerry <ge...@jackson9000.fsnet.co.uk> wrote:
[..]
>> Forth systems requiring stack depth to be the same across a colon
>> definition has long been a source of irritation when writing portable
>> programs in ANS Forth. For example to pass data into and out of a
>> colon definition requires a trick such as PASS

>> : pass >r ' execute r> ; immediate

>> (if I've remembered it correctly)

>> Usage e.g. 3 pass : foo ... ;

>> Gerry

> Agreed. WRT to catching unbalanced constructs such as IF...THEN etc, I
> simply implemented reference counting.  Since IF (for example) is
> immediate it simply increments an 'IF' counter (a dedicated cell in
> memory, not stored on the stack). THEN simply decrements the same
> counter. The word ; contains checks the various reference counters. If
> a counter > 0 then the appropriate error condition is reported e.g.
> "Error:Unbalanced IF/THEN". It's probably not fool proof, but it does
> mean that the stack is yours before, during, and after compilation!

And where do you temporarily store the patch addresses needed by THEN ?

-marcel

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

#7529

On Nov 27, 8:48 am, m...@iae.nl (Marcel Hendrix) wrote:
> Mark Wills <forthfr...@gmail.com> writes Re: Test of COMPILE,
>
>
>
>
>
>
>
>
>
>
>
> > On Nov 27, 8:09 am, Gerry <ge...@jackson9000.fsnet.co.uk> wrote:
> [..]
> >> Forth systems requiring stack depth to be the same across a colon
> >> definition has long been a source of irritation when writing portable
> >> programs in ANS Forth. For example to pass data into and out of a
> >> colon definition requires a trick such as PASS
> >> : pass >r ' execute r> ; immediate
> >> (if I've remembered it correctly)
> >> Usage e.g. 3 pass : foo ... ;
> >> Gerry
> > Agreed. WRT to catching unbalanced constructs such as IF...THEN etc, I
> > simply implemented reference counting.  Since IF (for example) is
> > immediate it simply increments an 'IF' counter (a dedicated cell in
> > memory, not stored on the stack). THEN simply decrements the same
> > counter. The word ; contains checks the various reference counters. If
> > a counter > 0 then the appropriate error condition is reported e.g.
> > "Error:Unbalanced IF/THEN". It's probably not fool proof, but it does
> > mean that the stack is yours before, during, and after compilation!
>
> And where do you temporarily store the patch addresses needed by THEN ?
>
> -marcel

They're on the stack; the 'classical' method of resolving addresses
(i.e. on the stack) is used. But there's no colon-sys or equivalent in
play.

Mark

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

#7541

In article <d9103622-67ae-4f35-8347-28971e754763@n10g2000vbg.googlegroups.com>,
Gerry  <gerry@jackson9000.fsnet.co.uk> wrote:
>On Nov 27, 2:11=A0am, Krishna Myneni <krishna.myn...@ccreweb.org> wrote:
>> On Nov 26, 7:09=A0pm, Coos Haak <chfo...@hccnet.nl> wrote:
>>
>>
>>
>> > Op Sat, 26 Nov 2011 16:00:00 -0800 (PST) schreef Krishna Myneni:
>>
>> > <snip>
>>
>> > > The one test that fails to compile, above, also seems to be pretty
>> > > consistent in failing across various Forth systems, with the exceptio=
>n
>> > > of my system. Although, I don't understand yet what it is about the
>> > > Forth-94 standard which precludes a colon definition from placing
>> > > something on the stack between ":" and ";".
>>
>> > > Krishna
>>
>> > : aap [ 3 ] ;
>> > fails on all the Forths I tested, because of the presence of !CSP and ?=
>CSP
>> > or something like that.
>> > I think this behavior is also helpful to signal unfinished control
>> > structures:
>>
>> > : noot if else ;
>>
>> > --
>> > Coos
>>
>> > CHForth, 16 bit DOS applicationshttp://home.hccnet.nl/j.j.haak/forth.ht=
>ml
>>
>> Apparently, the restriction is an implicit one by the allowance in
>> Forth-94 for the flow control stack to be the same as the data stack.
>> However, implementations which do not use the data stack for the flow
>> control stack should be able to place items onto the data stack during
>> word definitions, without side effects. Whether or not such a practice
>> has any benefits is not clear.
>>
>> Also, systems which do not use the data stack to hold control
>> structure information during compilation can also detect incomplete
>> structures, e.g., in kForth:
>>
>> : app [ 3 ] ;
>> =A0ok
>> : noot if else ;
>> Line 2: Compiler Error(6): Incomplete IF...THEN structure
>> : noot if else ;
>>
>
>Forth systems requiring stack depth to be the same across a colon
>definition has long been a source of irritation when writing portable
>programs in ANS Forth. For example to pass data into and out of a
>colon definition requires a trick such as PASS
>
>: pass >r ' execute r> ; immediate
>
>(if I've remembered it correctly)
>
>Usage e.g. 3 pass : foo ... ;

For systems that just put a single cell on the stack at :,
you need no extra word ( _ puts a don't care on the stack )
3  : foo [ _ SWAP do-your-thing ] LITERAL ... ; DROP

For me this technique suffices.
This not as portable as your technique, but yours is not fully
compliant either.

Or straightforward :

VARIABLE temp
3 temp !
.....  temp @ .....
 'temp HIDDEN  ( for the paranoid )

Not reentrant ? We are compiling here, so.

>
>Gerry

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] | [next] | [standalone]

#7545

On 27/11/2011 21:08, Albert van der Horst wrote:
[...]
>>> Apparently, the restriction is an implicit one by the allowance in
>>> Forth-94 for the flow control stack to be the same as the data stack.
>>> However, implementations which do not use the data stack for the flow
>>> control stack should be able to place items onto the data stack during
>>> word definitions, without side effects. Whether or not such a practice
>>> has any benefits is not clear.
>>>
>>> Also, systems which do not use the data stack to hold control
>>> structure information during compilation can also detect incomplete
>>> structures, e.g., in kForth:
>>>
>>> : app [ 3 ] ;
>>> =A0ok
>>> : noot if else ;
>>> Line 2: Compiler Error(6): Incomplete IF...THEN structure
>>> : noot if else ;
>>>
>>
>> Forth systems requiring stack depth to be the same across a colon
>> definition has long been a source of irritation when writing portable
>> programs in ANS Forth. For example to pass data into and out of a
>> colon definition requires a trick such as PASS
>>
>> : pass >r ' execute r>  ; immediate
>>
>> (if I've remembered it correctly)
>>
>> Usage e.g. 3 pass : foo ... ;
>
> For systems that just put a single cell on the stack at :,
> you need no extra word ( _ puts a don't care on the stack )
> 3  : foo [ _ SWAP do-your-thing ] LITERAL ... ; DROP
>
> For me this technique suffices.

As you apparently don't care about portability that's fine for you but 
hardly to be recommended. Different systems put varying numbers of cells 
on the stack - I've seen 0, 1, 2 and 3 cells.

> This not as portable as your technique,
Given that I was talking about portable programs, ISTM that your 
technique above is irrelevant.

but yours is not fully
> compliant either.

Why not? Of course the value passed in has to be used before the ; but 
that doesn't make it non-compliant. Incidentally I didn't invent it, 
AFAIK it was Michael Gassanenko.
>
> Or straightforward :

To a beginner probably not.

>
> VARIABLE temp
> 3 temp !
> .....  temp @ .....
>   'temp HIDDEN  ( for the paranoid )
>
> Not reentrant ? We are compiling here, so.
>


-- 
Gerry

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

#7558

On Nov 27, 4:08 pm, Albert van der Horst <alb...@spenarnc.xs4all.nl>
wrote:
> In article <d9103622-67ae-4f35-8347-28971e754...@n10g2000vbg.googlegroups.com>,

>> : pass >r ' execute r> ; immediate

>> (if I've remembered it correctly)

>> Usage e.g. 3 pass : foo ... ;

> This not as portable as your technique, but yours is not fully compliant either.

pass has an implementation dependency on the return stack not being
used as the control-flow stack, but that's met by a lot of
implementations.

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

#7566

BruceMcF <agila61@netscape.net> writes:
>On Nov 27, 4:08=A0pm, Albert van der Horst <alb...@spenarnc.xs4all.nl>
>wrote:
>> In article <d9103622-67ae-4f35-8347-28971e754...@n10g2000vbg.googlegroups=
>.com>,
>
>>> : pass >r ' execute r> ; immediate
>
>>> (if I've remembered it correctly)
>
>>> Usage e.g. 3 pass : foo ... ;
>
>> This not as portable as your technique, but yours is not fully compliant =
>either.
>
>pass has an implementation dependency on the return stack not being
>used as the control-flow stack

The control-flow stack may be on the data stack or separate, but it
certainly must not be on the return stack.  So

: pass >r ' execute r> ; immediate
3 pass : foo literal ;

is a standard program.  If it does not port to some non-standard
systems, I doubt that the use of the return stack is the cause.

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

#7550

On Nov 27, 2:09 am, Gerry <ge...@jackson9000.fsnet.co.uk> wrote:
> On Nov 27, 2:11 am, Krishna Myneni <krishna.myn...@ccreweb.org> wrote:
>
>
>
>
>
>
>
>
>
> > On Nov 26, 7:09 pm, Coos Haak <chfo...@hccnet.nl> wrote:
>
> > > Op Sat, 26 Nov 2011 16:00:00 -0800 (PST) schreef Krishna Myneni:
>
> > > <snip>
>
> > > > The one test that fails to compile, above, also seems to be pretty
> > > > consistent in failing across various Forth systems, with the exception
> > > > of my system. Although, I don't understand yet what it is about the
> > > > Forth-94 standard which precludes a colon definition from placing
> > > > something on the stack between ":" and ";".
>
> > > > Krishna
>
> > > : aap [ 3 ] ;
> > > fails on all the Forths I tested, because of the presence of !CSP and ?CSP
> > > or something like that.
> > > I think this behavior is also helpful to signal unfinished control
> > > structures:
>
> > > : noot if else ;
>
> > > --
> > > Coos
>
> > > CHForth, 16 bit DOS applicationshttp://home.hccnet.nl/j.j.haak/forth.html
>
> > Apparently, the restriction is an implicit one by the allowance in
> > Forth-94 for the flow control stack to be the same as the data stack.
> > However, implementations which do not use the data stack for the flow
> > control stack should be able to place items onto the data stack during
> > word definitions, without side effects. Whether or not such a practice
> > has any benefits is not clear.
>
> > Also, systems which do not use the data stack to hold control
> > structure information during compilation can also detect incomplete
> > structures, e.g., in kForth:
>
> > : app [ 3 ] ;
> >  ok
> > : noot if else ;
> > Line 2: Compiler Error(6): Incomplete IF...THEN structure
> > : noot if else ;
>
> Forth systems requiring stack depth to be the same across a colon
> definition has long been a source of irritation when writing portable
> programs in ANS Forth. For example to pass data into and out of a
> colon definition requires a trick such as PASS
>
> : pass >r ' execute r> ; immediate
>
> (if I've remembered it correctly)
>
> Usage e.g. 3 pass : foo ... ;
>
> Gerry

Gerry,

Can you provide an example of where it is necessary to pass a value on
the stack to a word under construction? Is there a reason why we
couldn't use "[ ... ] literal" to achieve the same result?

Krishna

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

#7565

On 27/11/2011 23:00, Krishna Myneni wrote:
> On Nov 27, 2:09 am, Gerry<ge...@jackson9000.fsnet.co.uk>  wrote:


>> Forth systems requiring stack depth to be the same across a colon
>> definition has long been a source of irritation when writing portable
>> programs in ANS Forth. For example to pass data into and out of a
>> colon definition requires a trick such as PASS
>>
>> : pass>r ' execute r>  ; immediate
>>
>> (if I've remembered it correctly)
>>
>> Usage e.g. 3 pass : foo ... ;
>>
>> Gerry
>
> Gerry,
>
> Can you provide an example of where it is necessary to pass a value on
> the stack to a word under construction? Is there a reason why we
> couldn't use "[ ... ] literal" to achieve the same result?
>
> Krishna

I can't remember the details of when I first came across it as a problem 
and I avoid doing it these days. I think it was when setting up some 
data structure and passing the address into a colon definition, which 
worked on my Forth as it has a separate control flow stack and doesn't 
check stack depth across a colon definition, but failed miserably when I 
tested the code on other Forths.

There is the point that ALLOT C, etc, say for creating anonymous 
objects, cannot be used portably inside the [ ... ] when compiling. Also 
if the code inside the [ ... ] is more than a few words it seems better 
to do it outside the colon definition.

IMO using the data stack as the control-flow stack and checking stack 
depths before and after a colon definition is a legacy from the days of 
resource-limited computers and has no place in a modern Forth. But then 
I don't use resource-limited processors so I would say that. But then 
again I get the impression that code for such processors tends to be 
non-standard anyway.

-- 
Gerry

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

#7569

On Nov 28, 11:39 am, Gerry Jackson <ge...@jackson9000.fsnet.co.uk>
wrote:
> On 27/11/2011 23:00, Krishna Myneni wrote:
>
>
>
>
>
>
>
>
>
> > On Nov 27, 2:09 am, Gerry<ge...@jackson9000.fsnet.co.uk>  wrote:
> >> Forth systems requiring stack depth to be the same across a colon
> >> definition has long been a source of irritation when writing portable
> >> programs in ANS Forth. For example to pass data into and out of a
> >> colon definition requires a trick such as PASS
>
> >> : pass>r ' execute r>  ; immediate
>
> >> (if I've remembered it correctly)
>
> >> Usage e.g. 3 pass : foo ... ;
>
> >> Gerry
>
> > Gerry,
>
> > Can you provide an example of where it is necessary to pass a value on
> > the stack to a word under construction? Is there a reason why we
> > couldn't use "[ ... ] literal" to achieve the same result?
>
> > Krishna
>
> I can't remember the details of when I first came across it as a problem
> and I avoid doing it these days. I think it was when setting up some
> data structure and passing the address into a colon definition, which
> worked on my Forth as it has a separate control flow stack and doesn't
> check stack depth across a colon definition, but failed miserably when I
> tested the code on other Forths.
>
> There is the point that ALLOT C, etc, say for creating anonymous
> objects, cannot be used portably inside the [ ... ] when compiling. Also
> if the code inside the [ ... ] is more than a few words it seems better
> to do it outside the colon definition.
>
> IMO using the data stack as the control-flow stack and checking stack
> depths before and after a colon definition is a legacy from the days of
> resource-limited computers and has no place in a modern Forth. But then
> I don't use resource-limited processors so I would say that. But then
> again I get the impression that code for such processors tends to be
> non-standard anyway.
>
> --
> Gerry

The use of the data stack for control flow is really very simple to
implement, since it doesn't require another stack. The requirement to
have matching stack depths at : and ; is a very minor inconvenience,
and when they don't, 99 times out of a 100 it's because I've miscoded.

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

#7574

On 28/11/2011 12:52, Alex McDonald wrote:
> On Nov 28, 11:39 am, Gerry Jackson<ge...@jackson9000.fsnet.co.uk>
> wrote:

[...]

>> IMO using the data stack as the control-flow stack and checking stack
>> depths before and after a colon definition is a legacy from the days of
>> resource-limited computers and has no place in a modern Forth. But then
>> I don't use resource-limited processors so I would say that. But then
>> again I get the impression that code for such processors tends to be
>> non-standard anyway.
>>

>
> The use of the data stack for control flow is really very simple to
> implement, since it doesn't require another stack.

Which is why, presumably, the data stack was used in early 
implementations of Forth. Implementing another stack is hardly difficult 
- ease of use, particularly for beginners, ought to be a more important 
consideration than a minor inconvenience for implementers.

The requirement to
> have matching stack depths at : and ; is a very minor inconvenience,

But why have even a minor inconvenience when it is easily avoided?

> and when they don't, 99 times out of a 100 it's because I've miscoded.

As pointed out elsethread, in a well designed system a stack mismatch 
will be detected anyway without a depth check as there won't be a 
colon-sys on the stack for ; to check.

However it's not that important an issue, just an occasional irritation.

-- 
Gerry

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

#7575

Gerry Jackson <gerry@jackson9000.fsnet.co.uk> wrote:
> On 28/11/2011 12:52, Alex McDonald wrote:
>> On Nov 28, 11:39 am, Gerry Jackson<ge...@jackson9000.fsnet.co.uk>
>> wrote:
> 
> [...]
> 
>>> IMO using the data stack as the control-flow stack and checking stack
>>> depths before and after a colon definition is a legacy from the days of
>>> resource-limited computers and has no place in a modern Forth. But then
>>> I don't use resource-limited processors so I would say that. But then
>>> again I get the impression that code for such processors tends to be
>>> non-standard anyway.
>>
>> The use of the data stack for control flow is really very simple to
>> implement, since it doesn't require another stack.
> 
> Which is why, presumably, the data stack was used in early 
> implementations of Forth. Implementing another stack is hardly difficult 
> - ease of use, particularly for beginners, ought to be a more important 
> consideration than a minor inconvenience for implementers.

How would a separate control-flow stack make things easier for anyone,
let alone a beginner?  I really don't see this one.

> The requirement to
>> have matching stack depths at : and ; is a very minor inconvenience,
> 
> But why have even a minor inconvenience when it is easily avoided?

Partly, it's a philosophical thing.  Forth is the way it is because of
a ruthless approach to simplification.  It has things that are needed,
and nothing else, or at least that's the idea.  Some might argue that
Standard Forth has somewhat deviated from this ideal.  ;-)

In any case, it's not that easy to avoid.  Every task that can compile
would need its own control-flow stack, and you'd have to find
somewhere to put it.

>> and when they don't, 99 times out of a 100 it's because I've miscoded.
> 
> As pointed out elsethread, in a well designed system a stack mismatch 
> will be detected anyway without a depth check as there won't be a 
> colon-sys on the stack for ; to check.

Really well-designed systems don't put *anything* on the stack at : ,
IMO.

Andrew.

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

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

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

csiph-web