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

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

What about code blocks (not Forth blocks)?

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

Contents

  What about code blocks (not Forth blocks)? Alexander Skobelev <al.skobelev@gmail.com> - 2013-12-17 23:56 -0800
    Re: What about code blocks (not Forth blocks)? mhx@iae.nl - 2013-12-18 01:14 -0800
      Re: What about code blocks (not Forth blocks)? Mark Wills <markrobertwills@yahoo.co.uk> - 2013-12-18 01:34 -0800
      Re: What about code blocks (not Forth blocks)? Alexander Skobelev <al.skobelev@gmail.com> - 2013-12-18 02:33 -0800
        Re: What about code blocks (not Forth blocks)? Coos Haak <chforth@hccnet.nl> - 2013-12-18 14:36 +0100
          Re: What about code blocks (not Forth blocks)? Alexander Skobelev <al.skobelev@gmail.com> - 2013-12-18 06:24 -0800
            Re: What about code blocks (not Forth blocks)? Coos Haak <chforth@hccnet.nl> - 2013-12-19 02:54 +0100
              Re: What about code blocks (not Forth blocks)? Alexander Skobelev <al.skobelev@gmail.com> - 2013-12-18 22:12 -0800
        Re: What about code blocks (not Forth blocks)? mhx@iae.nl - 2013-12-18 05:43 -0800
    Re: What about code blocks (not Forth blocks)? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-12-18 11:21 +0000
      Re: What about code blocks (not Forth blocks)? Alexander Skobelev <al.skobelev@gmail.com> - 2013-12-18 04:31 -0800
        Re: What about code blocks (not Forth blocks)? Ilya Tarasov <ilya74.tarasov@gmail.com> - 2013-12-18 04:49 -0800
          Re: What about code blocks (not Forth blocks)? Alexander Skobelev <al.skobelev@gmail.com> - 2013-12-18 05:12 -0800
    Re: What about code blocks (not Forth blocks)? "Elizabeth D. Rather" <erather@forth.com> - 2013-12-18 08:26 -1000
      Re: What about code blocks (not Forth blocks)? Paul Rubin <no.email@nospam.invalid> - 2013-12-18 11:03 -0800
        Re: What about code blocks (not Forth blocks)? Alexander Skobelev <al.skobelev@gmail.com> - 2013-12-18 11:21 -0800
      Re: What about code blocks (not Forth blocks)? Alexander Skobelev <al.skobelev@gmail.com> - 2013-12-18 11:19 -0800
        Re: What about code blocks (not Forth blocks)? "Elizabeth D. Rather" <erather@forth.com> - 2013-12-18 10:08 -1000
          Re: What about code blocks (not Forth blocks)? Bernd Paysan <bernd.paysan@gmx.de> - 2013-12-18 21:58 +0100
            Re: What about code blocks (not Forth blocks)? "Ed" <invalid@invalid.com> - 2013-12-19 14:15 +1100
              Re: What about code blocks (not Forth blocks)? "Alex McDonald" <blog@rivadpm.com> - 2013-12-19 13:32 +0000
                Re: What about code blocks (not Forth blocks)? "Ed" <invalid@invalid.com> - 2013-12-20 21:07 +1100
                  Re: What about code blocks (not Forth blocks)? "Alex McDonald" <blog@rivadpm.com> - 2013-12-20 12:35 +0000
                    Re: What about code blocks (not Forth blocks)? "Alex McDonald" <blog@rivadpm.com> - 2013-12-20 13:02 +0000
                    Re: What about code blocks (not Forth blocks)? "Ed" <invalid@invalid.com> - 2013-12-22 14:19 +1100
                      Re: What about code blocks (not Forth blocks)? "Alex McDonald" <blog@rivadpm.com> - 2013-12-22 10:15 +0000
                        Re: What about code blocks (not Forth blocks)? "Ed" <invalid@invalid.com> - 2013-12-24 12:30 +1100
                          Re: What about code blocks (not Forth blocks)? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-12-24 16:48 +0000
                            Re: What about code blocks (not Forth blocks)? "Ed" <invalid@invalid.com> - 2013-12-28 11:08 +1100
                              Re: What about code blocks (not Forth blocks)? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-12-28 11:40 +0000
                          Re: What about code blocks (not Forth blocks)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-12-26 18:03 +0000
                            Re: What about code blocks (not Forth blocks)? Paul Rubin <no.email@nospam.invalid> - 2013-12-26 10:34 -0800
                              Re: What about code blocks (not Forth blocks)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-12-27 15:53 +0000
                                Re: What about code blocks (not Forth blocks)? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2013-12-28 17:26 +0000
                                  Re: What about code blocks (not Forth blocks)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-12-28 17:53 +0000
                                    Re: What about code blocks (not Forth blocks)? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2013-12-28 18:21 +0000
                                      Re: What about code blocks (not Forth blocks)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-12-29 14:49 +0000
                                        Re: What about code blocks (not Forth blocks)? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2013-12-29 20:45 +0000
                                          Re: What about code blocks (not Forth blocks)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-12-30 17:08 +0000
                                            Re: What about code blocks (not Forth blocks)? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2013-12-30 20:00 +0000
                                  Re: What about code blocks (not Forth blocks)? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-12-28 18:04 +0000
                                    Re: What about code blocks (not Forth blocks)? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2013-12-28 18:47 +0000
                                      Re: What about code blocks (not Forth blocks)? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2013-12-28 19:12 +0000
                            Re: What about code blocks (not Forth blocks)? "Ed" <invalid@invalid.com> - 2013-12-28 11:09 +1100
                              Re: What about code blocks (not Forth blocks)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-12-28 13:45 +0000
            Re: What about code blocks (not Forth blocks)? Elizabeth D Rather <erather@forth.com> - 2013-12-18 19:04 -1000
              Re: What about code blocks (not Forth blocks)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-12-19 09:25 +0000
              Re: What about code blocks (not Forth blocks)? Paul Rubin <no.email@nospam.invalid> - 2013-12-19 05:00 -0800
          Re: What about code blocks (not Forth blocks)? Alexander Skobelev <al.skobelev@gmail.com> - 2013-12-18 23:41 -0800
          Re: What about code blocks (not Forth blocks)? Alexander Skobelev <al.skobelev@gmail.com> - 2013-12-19 01:00 -0800
          Re: What about code blocks (not Forth blocks)? Alexander Skobelev <al.skobelev@gmail.com> - 2013-12-19 02:47 -0800
            Re: What about code blocks (not Forth blocks)? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2013-12-19 11:23 +0000
              Re: What about code blocks (not Forth blocks)? Alexander Skobelev <al.skobelev@gmail.com> - 2013-12-19 03:52 -0800
    Re: What about code blocks (not Forth blocks)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-12-19 15:58 +0000
      Re: What about code blocks (not Forth blocks)? Paul Rubin <no.email@nospam.invalid> - 2013-12-19 10:05 -0800
        Re: What about code blocks (not Forth blocks)? "Alex McDonald" <blog@rivadpm.com> - 2013-12-19 20:07 +0000
          Re: What about code blocks (not Forth blocks)? Paul Rubin <no.email@nospam.invalid> - 2013-12-19 12:33 -0800
            Re: What about code blocks (not Forth blocks)? "Alex McDonald" <blog@rivadpm.com> - 2013-12-19 20:33 +0000
              Re: What about code blocks (not Forth blocks)? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-12-19 20:52 +0000
              Re: What about code blocks (not Forth blocks)? Paul Rubin <no.email@nospam.invalid> - 2013-12-19 18:52 -0800
            Re: What about code blocks (not Forth blocks)? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-12-28 12:52 -0600
              Re: What about code blocks (not Forth blocks)? Paul Rubin <no.email@nospam.invalid> - 2013-12-28 11:47 -0800
                Re: What about code blocks (not Forth blocks)? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-12-29 07:39 -0600
                  Re: What about code blocks (not Forth blocks)? Paul Rubin <no.email@nospam.invalid> - 2013-12-29 08:11 -0800
              Re: What about code blocks (not Forth blocks)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-12-29 15:25 +0000
                Re: What about code blocks (not Forth blocks)? Paul Rubin <no.email@nospam.invalid> - 2013-12-29 08:15 -0800
                  Re: What about code blocks (not Forth blocks)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-12-29 16:03 +0000
                    Re: What about code blocks (not Forth blocks)? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2013-12-29 20:54 +0000
                      Re: What about code blocks (not Forth blocks)? mhx@iae.nl - 2013-12-29 13:38 -0800
                      Re: What about code blocks (not Forth blocks)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-12-30 17:04 +0000
                        Re: What about code blocks (not Forth blocks)? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2013-12-30 20:05 +0000
                          Re: What about code blocks (not Forth blocks)? Paul Rubin <no.email@nospam.invalid> - 2013-12-30 16:49 -0800
                          Re: What about code blocks (not Forth blocks)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-02 17:27 +0000
                Re: What about code blocks (not Forth blocks)? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-12-29 16:40 -0600
                  Re: What about code blocks (not Forth blocks)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-12-30 16:51 +0000
                    Re: What about code blocks (not Forth blocks)? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-12-30 11:15 -0600
                      Re: What about code blocks (not Forth blocks)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-12-30 17:37 +0000
                        Re: What about code blocks (not Forth blocks)? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-12-30 12:07 -0600
          Re: What about code blocks (not Forth blocks)? "Alex McDonald" <blog@rivadpm.com> - 2013-12-20 13:50 +0000
        Re: What about code blocks (not Forth blocks)? hughaguilar96@yahoo.com - 2013-12-19 21:49 -0800
          Re: What about code blocks (not Forth blocks)? "Alex McDonald" <blog@rivadpm.com> - 2013-12-20 08:56 +0000
            Re: What about code blocks (not Forth blocks)? hughaguilar96@yahoo.com - 2014-04-03 19:13 -0700
          Re: What about code blocks (not Forth blocks)? "WJ" <w_a_x_man@yahoo.com> - 2014-03-11 05:35 +0000
            Re: What about code blocks (not Forth blocks)? Bernd Paysan <bernd.paysan@gmx.de> - 2014-03-11 12:59 +0100
              Re: What about code blocks (not Forth blocks)? hughaguilar96@yahoo.com - 2014-03-11 23:44 -0700
                Re: What about code blocks (not Forth blocks)? Julian Fondren <ayrnieu@gmail.com> - 2014-03-12 11:48 -0700
                  Re: What about code blocks (not Forth blocks)? Bernd Paysan <bernd.paysan@gmx.de> - 2014-03-12 20:21 +0100
                    Re: What about code blocks (not Forth blocks)? hughaguilar96@yahoo.com - 2014-03-12 23:35 -0700
                      Re: What about code blocks (not Forth blocks)? "Alex McDonald" <blog@rivadpm.com> - 2014-03-14 14:25 +0000
                        Re: What about code blocks (not Forth blocks)? Bernd Paysan <bernd.paysan@gmx.de> - 2014-03-14 16:36 +0100
                          Re: What about code blocks (not Forth blocks)? mhx@iae.nl - 2014-03-14 11:27 -0700
                          Re: What about code blocks (not Forth blocks)? hughaguilar96@yahoo.com - 2014-03-16 17:38 -0700
                            Re: What about code blocks (not Forth blocks)? "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-03-17 03:35 -0400
                          Re: What about code blocks (not Forth blocks)? Paul Rubin <no.email@nospam.invalid> - 2014-03-17 20:36 -0700
                            Re: What about code blocks (not Forth blocks)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-03-18 13:13 +0000
                              Re: What about code blocks (not Forth blocks)? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-03-18 14:28 +0000
                              Re: What about code blocks (not Forth blocks)? Paul Rubin <no.email@nospam.invalid> - 2014-03-18 10:10 -0700
                              Re: What about code blocks (not Forth blocks)? Paul Rubin <no.email@nospam.invalid> - 2014-03-25 12:54 -0700
                                Re: What about code blocks (not Forth blocks)? hughaguilar96@yahoo.com - 2014-03-25 23:09 -0700
                                Re: What about code blocks (not Forth blocks)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-03-26 13:49 +0000
                                  Re: What about code blocks (not Forth blocks)? Bernd Paysan <bernd.paysan@gmx.de> - 2014-03-26 22:07 +0100
                            Re: What about code blocks (not Forth blocks)? hughaguilar96@yahoo.com - 2014-03-20 22:11 -0700
                          Re: What about code blocks (not Forth blocks)? hughaguilar96@yahoo.com - 2014-03-28 22:18 -0700
                            Re: What about code blocks (not Forth blocks)? "Alex McDonald" <blog@rivadpm.com> - 2014-03-29 10:57 +0000
                    Re: What about code blocks (not Forth blocks)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-03-13 16:42 +0000
            Re: What about code blocks (not Forth blocks)? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-03-11 12:51 +0000
              Re: What about code blocks (not Forth blocks)? "Alex McDonald" <blog@rivadpm.com> - 2014-03-11 14:54 +0000
      Re: What about code blocks (not Forth blocks)? Alexander Skobelev <al.skobelev@gmail.com> - 2013-12-19 21:36 -0800
        Re: What about code blocks (not Forth blocks)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-12-20 16:56 +0000
      Re: What about code blocks (not Forth blocks)? Alexander Skobelev <al.skobelev@gmail.com> - 2013-12-19 23:24 -0800
        Re: What about code blocks (not Forth blocks)? mhx@iae.nl - 2013-12-20 02:05 -0800
        Re: What about code blocks (not Forth blocks)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-12-20 12:41 +0000
          Re: What about code blocks (not Forth blocks)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-12-20 17:46 +0000
            Re: What about code blocks (not Forth blocks)? Alexander Skobelev <al.skobelev@gmail.com> - 2013-12-21 08:11 -0800
              Re: What about code blocks (not Forth blocks)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-12-23 10:07 +0000
                Re: What about code blocks (not Forth blocks)? Bernd Paysan <bernd.paysan@gmx.de> - 2013-12-23 19:31 +0100
                  Re: What about code blocks (not Forth blocks)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-12-26 17:45 +0000

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

#27317 — What about code blocks (not Forth blocks)?

Hello all,
I'm just wondering, what is common opinion (if it exists) about using code blocks (something like 'quotes' in Retro forth) among experienced Forthers? Would it be a valuable addition to Forth?

Just for example here a very naive Gforth-specific implementation of local  code blocks (i.e not intended to be used anywhere but only inside a word definition):

<code>
\ Gforth-specific blocks

0 >body constant BODY-OFFSET
:noname ; @ constant CFA-VALUE
variable cfa-addr

\ LOCAL-EXIT is EXIT that keeps locals
: local-exit postpone ;s ; immediate

: [| ( -- )    \ C: build a block prefix: keep HERE in cfa-addr, compile in CFA-VALUE 
    postpone ahead
    align HERE dup cfa-addr ! BODY-OFFSET allot CFA-VALUE swap !
; immediate

: |] (E: -- xt)
    postpone local-exit
    postpone then
    cfa-addr @ 
    postpone literal
; immediate

\ --
: ntimes ( xt n -- ; xt: i -- )
    0 ?do i over execute loop drop ;

: test-ntimes [| ( n -- ) cr . ." time" |] swap ntimes ;

: e-or ( xt1 xt2 -- flag )
    swap execute if
        drop TRUE
    else
        execute
    then
; 

: e-and ( xt1 xt2 -- flag )
    swap execute if
        execute
    else
        drop FALSE
    then
;

: test-e-or { n1 n2 -- flag }
    [| cr ." 1st is " n1 dup .  |] [| cr ." 2nd is " n2 dup . |] e-or  dup ." -> " . ;
-1 0 test-e-or
0 -1 test-e-or

: test-e-and { n1 n2 -- flag }
    [| cr ." 1st is " n2 dup .  |] [| cr ." 2nd is " n1 dup . |] e-and  dup ." -> " . ;

-1 0 test-e-and
-1 -1 test-e-and

</code>

 

[toc] | [next] | [standalone]

#27318

On Wednesday, December 18, 2013 8:56:34 AM UTC+1, Alexander Skobelev wrote: What about code blocks (not Forth blocks)?

> I'm just wondering, what is common opinion (if it exists) 
> about using code blocks (something like 'quotes' in Retro 
> forth) among experienced Forthers? Would it be a valuable 
> addition to Forth?

You don't read/check CLF that much, do you :-)

When this discussion came around last time I implemented 'code 
blocks' for iForth (it is more difficult for an optimizing 
compiler). Since that time I haven't felt a pressing need to use 
them -- they are just syntactical sugar.

> Just for example here a very naive Gforth-specific implementation 
> of local  code blocks (i.e not intended to
> be used anywhere but only inside a word definition):

You know that your implementation has close to zero chance
to work on other Forths, and maybe not even on other variations
of Gforth :-) Of course this is a nice example of the
flexibility of Forth.

> Just for example here a very naive Gforth-specific 
> implementation of local  code blocks (i.e not intended to
> be used anywhere but only inside a word definition):

Why do you use

  BODY-OFFSET allot CFA-VALUE swap !

instead of

  CFA-VALUE ,

? What happens if BODY-OFFSET is more than 1 CELL ?

-marcel

-- Here's how to do it in the development release of iForth:

ANEW -codeblocks
NEEDS -anons

: ntimes ( xt n -- ; xt: i -- )  0 ?do  i over execute  loop drop ;
: test-ntimes [: ( n -- ) cr . ." time" ;] swap ntimes ;

: e-or ( xt1 xt2 -- flag )
    swap execute if
        drop TRUE
    else
        execute
    then
; 

: e-and ( xt1 xt2 -- flag )
    swap execute if
        execute
    else
        drop FALSE
    then
;

: test-e-or LOCALS| n2 n1 | ( -- flag )
    [: cr ." 1st is " n1 dup .  ;] [: cr ." 2nd is " n2 dup . ;] e-or  dup ." -> " . ;

: test-e-and LOCALS| n2 n1 | ( n1 n2 -- flag )
    [: cr ." 1st is " n2 dup .  ;] [: cr ." 2nd is " n1 dup . ;] e-and  dup ." -> " . ;

: test-foo ( flag -- )
	#10 SWAP
	   IF  [: ( n1 -- n2 ) DUP 1 > IF  DUP 1-  MYSELF  SWAP 2-  MYSELF +  ENDIF ;] \ fib
	 ELSE  [: ( n1 -- n2 ) DUP     IF  DUP 1-  MYSELF  SWAP *   ELSE  1+  ENDIF ;] \ fac
	ENDIF  EXECUTE . ;

3 test-ntimes
-1  0 test-e-or .
 0 -1 test-e-or .
-1  0 test-e-and .
-1 -1 test-e-and .
cr true test-foo
   false test-foo

-- output

Creating --- Anonymous words     Version 0.02 ---
0 time
1 time
2 time
1st is -1 -> -1 -1
1st is 0
2nd is -1 -> -1 -1
1st is 0 -> 0 0
1st is -1
2nd is -1 -> -1 -1
55 3628800  ok

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

#27320

On Wednesday, December 18, 2013 9:14:08 AM UTC, m...@iae.nl wrote:
> When this discussion came around last time I implemented 'code 
> blocks' for iForth (it is more difficult for an optimizing 
> compiler). Since that time I haven't felt a pressing need to use 
> them -- they are just syntactical sugar.

Agreed. 

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

#27321

On Wednesday, December 18, 2013 1:14:08 PM UTC+4, m...@iae.nl wrote:
> On Wednesday, December 18, 2013 8:56:34 AM UTC+1, Alexander Skobelev wrote: What about code blocks (not Forth blocks)?
> 
> > I'm just wondering, what is common opinion (if it exists) 
> > about using code blocks (something like 'quotes' in Retro 
> > forth) among experienced Forthers? Would it be a valuable 
> > addition to Forth?
> 
> You don't read/check CLF that much, do you :-)

Mea culpa! Just didn't know how to do that. :(

> When this discussion came around last time I implemented 'code 
> blocks' for iForth (it is more difficult for an optimizing 
> compiler). Since that time I haven't felt a pressing need to use 
> them -- they are just syntactical sugar.

Well, agreed. What I was trying to understand is how much this sugar
can make forthing sweeter. :)
Do not remember who said about multiply inheritance: "Usually, you
don't need it but sometimes it is a pity you don't have it". 
So may be there is the same situation.  
> 
> > Just for example here a very naive Gforth-specific implementation 
> > of local  code blocks (i.e not intended to
> > be used anywhere but only inside a word definition):
> 
> You know that your implementation has close to zero chance
> to work on other Forths, and maybe not even on other variations
> of Gforth :-) Of course this is a nice example of the
> flexibility of Forth.

Yes, I know. In fact, I started thinking about 'code blocks' when I
decided to rewrite a tiny Factor program in Forth. I wrote it without
'code blocks' but an idea about how to implement them in Forth was
stuck in my mind.

> 
> > Just for example here a very naive Gforth-specific 
> > implementation of local  code blocks (i.e not intended to
> > be used anywhere but only inside a word definition):
> 
> Why do you use
> 
>   BODY-OFFSET allot CFA-VALUE swap !
> 
> instead of
> 
>   CFA-VALUE ,
> 
> ? What happens if BODY-OFFSET is more than 1 CELL ?

Well, in fact it is

here BODY-OFFEST allot CFA-VALUE swap !

so I store CVA-VALUE in the beginning of the allocated region having
BODY-OFFSET bytes in length, that can be anything more then 1 CELL. On
my machine it is exactly 2 CELLS.
 
Well it is a sort of a hack and non-portable code, but I'm not sure
that it can be made in a portable way at all, because we need to
create lightweight word's header while compiling other word.

> 
> -marcel
> 
> 
> 
> -- Here's how to do it in the development release of iForth:
> 
> ANEW -codeblocks
> NEEDS -anons
> 
> : ntimes ( xt n -- ; xt: i -- )  0 ?do  i over execute  loop drop ;
> : test-ntimes [: ( n -- ) cr . ." time" ;] swap ntimes ;
> 
> : e-or ( xt1 xt2 -- flag )
>     swap execute if
>         drop TRUE
>     else
>         execute
>     then
> ; 
> 
> : e-and ( xt1 xt2 -- flag )
>     swap execute if
>         execute
>     else
>         drop FALSE
>     then
> ;
> 
> : test-e-or LOCALS| n2 n1 | ( -- flag )
>     [: cr ." 1st is " n1 dup .  ;] [: cr ." 2nd is " n2 dup . ;] e-or  dup ." -> " . ;
> 
> : test-e-and LOCALS| n2 n1 | ( n1 n2 -- flag )
>     [: cr ." 1st is " n2 dup .  ;] [: cr ." 2nd is " n1 dup . ;] e-and  dup ." -> " . ;
> 
> : test-foo ( flag -- )
> 	#10 SWAP
> 	   IF  [: ( n1 -- n2 ) DUP 1 > IF  DUP 1-  MYSELF  SWAP 2-  MYSELF +  ENDIF ;] \ fib
> 	 ELSE  [: ( n1 -- n2 ) DUP     IF  DUP 1-  MYSELF  SWAP *   ELSE  1+  ENDIF ;] \ fac
> 	ENDIF  EXECUTE . ;
> 
> 3 test-ntimes
> -1  0 test-e-or .
>  0 -1 test-e-or .
> -1  0 test-e-and .
> -1 -1 test-e-and .
> cr true test-foo
>    false test-foo
> 
> -- output
> 
> Creating --- Anonymous words     Version 0.02 ---
> 0 time
> 1 time
> 2 time
> 1st is -1 -> -1 -1
> 1st is 0
> 2nd is -1 -> -1 -1
> 1st is 0 -> 0 0
> 1st is -1
> 2nd is -1 -> -1 -1
> 55 3628800  ok

BTW, if it is possible, it would be interesting to look at your
iForth's realization of 'code blocks'.  Could you please point me to
it?

Thanks!

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

#27330

Op Wed, 18 Dec 2013 02:33:25 -0800 (PST) schreef Alexander Skobelev:

> On Wednesday, December 18, 2013 1:14:08 PM UTC+4, m...@iae.nl wrote:
>> 
>> Why do you use
>> 
>>   BODY-OFFSET allot CFA-VALUE swap !
>> 
>> instead of
>> 
>>   CFA-VALUE ,
>> 
>> ? What happens if BODY-OFFSET is more than 1 CELL ?
> 
> Well, in fact it is
> 
> here BODY-OFFEST allot CFA-VALUE swap !
> 
> so I store CVA-VALUE in the beginning of the allocated region having
> BODY-OFFSET bytes in length, that can be anything more then 1 CELL. On
> my machine it is exactly 2 CELLS.
>  

So you should use 2! instead of ! and CFA-VALUE is a double.
Or:   CFA-VALUE ( d ) , ,

-- 
Coos

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

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

#27332

On Wednesday, December 18, 2013 5:36:12 PM UTC+4, Coos Haak wrote:
> Op Wed, 18 Dec 2013 02:33:25 -0800 (PST) schreef Alexander Skobelev:
> 
> 
> 
> > On Wednesday, December 18, 2013 1:14:08 PM UTC+4, m...@iae.nl wrote:
> 
> >> 
> 
> >> Why do you use
> 
> >> 
> 
> >>   BODY-OFFSET allot CFA-VALUE swap !
> 
> >> 
> 
> >> instead of
> 
> >> 
> 
> >>   CFA-VALUE ,
> 
> >> 
> 
> >> ? What happens if BODY-OFFSET is more than 1 CELL ?
> 
> > 
> 
> > Well, in fact it is
> 
> > 
> 
> > here BODY-OFFEST allot CFA-VALUE swap !
> 
> > 
> 
> > so I store CVA-VALUE in the beginning of the allocated region having
> 
> > BODY-OFFSET bytes in length, that can be anything more then 1 CELL. On
> 
> > my machine it is exactly 2 CELLS.
> 
> >  
> 
> 
> 
> So you should use 2! instead of ! and CFA-VALUE is a double.
> 
> Or:   CFA-VALUE ( d ) , ,

Hmm, CFA-VALUE is an address and as far as I know the width of CELL is equal to width of address cell. It is in dpANS 3.1.3 (http://lars.nocrew.org/dpans/dpans3.htm#3.1.3): "Data-stack elements, return-stack elements, addresses, execution tokens, flags, and integers are one cell wide." Or I have missed something?



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

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

#27341

Op Wed, 18 Dec 2013 06:24:46 -0800 (PST) schreef Alexander Skobelev:

> Hmm, CFA-VALUE is an address and as far as I know the width of CELL is equal to width of address cell. It is in dpANS 3.1.3 (http://lars.nocrew.org/dpans/dpans3.htm#3.1.3): "Data-stack elements, return-stack elements, addresses, execution tokens, flags, and integers are one cell wide." Or I have missed something?
> 

Why then did you write:
>>> BODY-OFFSET bytes in length, that can be anything more then 1 CELL. On
>> 
>>> my machine it is exactly 2 CELLS.
                             --------
?

-- 
Coos

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

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

#27346

On Thursday, December 19, 2013 5:54:02 AM UTC+4, Coos Haak wrote:
> Op Wed, 18 Dec 2013 06:24:46 -0800 (PST) schreef Alexander Skobelev:
> 
> > Hmm, CFA-VALUE is an address and as far as I know the width of CELL is equal
> > to width of address cell. It is in dpANS 3.1.3
> > (http://lars.nocrew.org/dpans/dpans3.htm#3.1.3): "Data-stack elements,
> > return-stack elements, addresses, execution tokens, flags, and integers are
> > one cell wide." Or I have missed something?
> > 
> 
> Why then did you write:
> >>> BODY-OFFSET bytes in length, that can be anything more then 1 CELL. On
> >> 
> >>> my machine it is exactly 2 CELLS.
>                              --------
> ?

Well, as far as I understand, this is because there is one more cell in Gforth
header just behind the CFA one. It seems to be somehow used in DOES> words.

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

#27331

On Wednesday, December 18, 2013 11:33:25 AM UTC+1, Alexander Skobelev wrote:
> BTW, if it is possible, it would be interesting to look at your
> iForth's realization of 'code blocks'.  Could you please point me to
> it?

https://groups.google.com/d/msg/comp.lang.forth/irQzTmYE_oM/_bszZSgaWtsJ

-marcel

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

#27324

In article <583c56b0-8514-4e6c-a120-029bce9ad7c1@googlegroups.com>,
Alexander Skobelev  <al.skobelev@gmail.com> wrote:
>Hello all,
>I'm just wondering, what is common opinion (if it exists) about using
>code blocks (something like 'quotes' in Retro forth) among experienced
>Forthers? Would it be a valuable addition to Forth?
>
>Just for example here a very naive Gforth-specific implementation of
>local  code blocks (i.e not intended to be used anywhere but only inside
>a word definition):

I have posted some time ago about adding a block structure to Forth.
That would replace locals *and* vocabularies. It uses only { }.
It adds the dictionary rule that you can find things that are hidden
by one layer of { }, but not by two or more layers.
Apart from this influence on the dictionary structure, { } can be placed
anywehere, so also in the middle of a compilation, resetting the
compilation state.
There was no interest whatsoever.

>
><code>
>\ Gforth-specific blocks
>
>0 >body constant BODY-OFFSET
>:noname ; @ constant CFA-VALUE
>variable cfa-addr
>
>\ LOCAL-EXIT is EXIT that keeps locals
>: local-exit postpone ;s ; immediate
>
>: [| ( -- )    \ C: build a block prefix: keep HERE in cfa-addr, compile
>in CFA-VALUE
>    postpone ahead
>    align HERE dup cfa-addr ! BODY-OFFSET allot CFA-VALUE swap !
>; immediate
>
>: |] (E: -- xt)
>    postpone local-exit
>    postpone then
>    cfa-addr @
>    postpone literal
>; immediate
>
>\ --
>: ntimes ( xt n -- ; xt: i -- )
>    0 ?do i over execute loop drop ;
>
>: test-ntimes [| ( n -- ) cr . ." time" |] swap ntimes ;
>
>: e-or ( xt1 xt2 -- flag )
>    swap execute if
>        drop TRUE
>    else
>        execute
>    then
>;
>
>: e-and ( xt1 xt2 -- flag )
>    swap execute if
>        execute
>    else
>        drop FALSE
>    then
>;
>
>: test-e-or { n1 n2 -- flag }
>    [| cr ." 1st is " n1 dup .  |] [| cr ." 2nd is " n2 dup . |] e-or
>dup ." -> " . ;
>-1 0 test-e-or
>0 -1 test-e-or
>
>: test-e-and { n1 n2 -- flag }
>    [| cr ." 1st is " n2 dup .  |] [| cr ." 2nd is " n1 dup . |] e-and
>dup ." -> " . ;
>
>-1 0 test-e-and
>-1 -1 test-e-and
>
></code>
>
>
-- 
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]

#27326

On Wednesday, December 18, 2013 3:21:14 PM UTC+4, Albert van der Horst wrote:
> In article <583c56b0-8514-4e6c-a120-029bce9ad7c1@googlegroups.com>,
> Alexander Skobelev  <> wrote:
> >Hello all,
> >I'm just wondering, what is common opinion (if it exists) about using
> >code blocks (something like 'quotes' in Retro forth) among experienced
> >Forthers? Would it be a valuable addition to Forth?
> >
> >Just for example here a very naive Gforth-specific implementation of
> >local  code blocks (i.e not intended to be used anywhere but only inside
> >a word definition):
> 
> I have posted some time ago about adding a block structure to Forth.
> That would replace locals *and* vocabularies. It uses only { }.
> It adds the dictionary rule that you can find things that are hidden
> by one layer of { }, but not by two or more layers.
> Apart from this influence on the dictionary structure, { } can be placed
> anywehere, so also in the middle of a compilation, resetting the
> compilation state.
> There was no interest whatsoever.
> 

That sounds interesting, but it looks like somewhat more extended
functionality what I was asking about. I suppose, that your's block
structure requires (much?) more changes to be done in the kernel. But
to add two additional words to create a non-linked header and make a
local exit seems to be much easier. Well, of course I can be wrond
here. For example, I have no idea how to implelemnt the same in
SwiftForth in which 0 >BODY returns 8229 on my machine.

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

#27327

My solution (implemented in assembler).

===================================
VARIABLE X
1 X !

: TEST
  LOC[
    VARIABLE X
    : R 2 2 + . ;
  ]LOC

  5 X !
  X @ .
  R

;


TEST
X @ .  
================================

Output: 5 4 1.

LOC{ stores the value of the current vocabulary entry on the stack, so we can define any word after LOC{, but all of them will be forgotten after restoring latest LFA. There are no restrictions for the quantity of nested levels of LOC{ 

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

#27328

On Wednesday, December 18, 2013 4:49:10 PM UTC+4, Ilya Tarasov wrote:
> My solution (implemented in assembler).
> 
> 
> 
> ===================================
> 
> VARIABLE X
> 
> 1 X !
> 
> 
> 
> : TEST
> 
>   LOC[
> 
>     VARIABLE X
> 
>     : R 2 2 + . ;
> 
>   ]LOC
> 
> 
> 
>   5 X !
> 
>   X @ .
> 
>   R
> 
> 
> 
> ;
> 
> 
> 
> 
> 
> TEST
> 
> X @ .  
> 
> ================================
> 
> 
> 
> Output: 5 4 1.
> 
> 
> 
> LOC{ stores the value of the current vocabulary entry on the stack, so we can define any word after LOC{, but all of them will be forgotten after restoring latest LFA. There are no restrictions for the quantity of nested levels of LOC{

Ilya, my point was about adding some syntactical sugar that would help a programmer write less. For instance, instead of writing two words write only one and inline the other in it. From this point I don't want to have the full defining functionality inside a code block – just ability to compile some words and refer local variables inside the brackets. So, for me, your solution is too much. :)

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

#27333

On 12/17/13 9:56 PM, Alexander Skobelev wrote:
> Hello all,
> I'm just wondering, what is common opinion (if it exists) about using code blocks (something like 'quotes' in Retro forth) among experienced Forthers? Would it be a valuable addition to Forth?
>
> Just for example here a very naive Gforth-specific implementation of local  code blocks (i.e not intended to be used anywhere but only inside a word definition):
>

Could you explain what you see as the advantage of such blocks vs. Forth 
definitions? I'm not sure what problem you're trying to solve.

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]

#27334

"Elizabeth D. Rather" <erather@forth.com> writes:
> Could you explain what you see as the advantage of such blocks
> vs. Forth definitions? I'm not sure what problem you're trying to
> solve.

It avoids leaving internal factors as named entities cluttering the
programmer's mind.  It's similar to doing calculations on the stack
instead of putting the intermediate results in global variables.

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

#27336

On Wednesday, December 18, 2013 11:03:50 PM UTC+4, Paul Rubin wrote:
> "Elizabeth D. Rather" writes:
> 
> > Could you explain what you see as the advantage of such blocks
> > vs. Forth definitions? I'm not sure what problem you're trying to
> > solve.
> 
> It avoids leaving internal factors as named entities cluttering the
> programmer's mind.  It's similar to doing calculations on the stack
> instead of putting the intermediate results in global variables.

Paul, you gave much better and shorted description than myself one.

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

#27335

On Wednesday, December 18, 2013 10:26:43 PM UTC+4, Elizabeth D. Rather wrote:
> On 12/17/13 9:56 PM, Alexander Skobelev wrote:
> 
> > Hello all, I'm just wondering, what is common opinion (if it
> > exists) about using code blocks (something like 'quotes' in Retro
> > forth) among experienced Forthers? Would it be a valuable addition
> > to Forth?
> >
> > Just for example here a very naive Gforth-specific implementation
> > of local code blocks (i.e not intended to be used anywhere but
> > only inside a word definition):
> >
> 
> Could you explain what you see as the advantage of such blocks vs. Forth 
> definitions? I'm not sure what problem you're trying to solve.
> 

Well, I think, such blocks could make a program code clearer.
While they behave like a separate definition (in a sense that they are
identified by XT and they get control with a call to EXECUTE), they
existence is only meaningful in the context of a definition where they
are defined.  They can be useful for iterating over array, or as arguments
to some short-circuit operators. Of course the Forth definition can be
used in these applications very well, but you need to create a separate
definition. You need to think how to name it and not to clash with
existing names. Even if it can be sit very close to the place you use it,
it is still somewhat out of context the definition that uses it. If
you make any changes in that definition, you need go back and check,
if nothing has broken in that helper. 

So this is only a question of convenience and a language flexibility.

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

#27337

On 12/18/13 9:19 AM, Alexander Skobelev wrote:
> On Wednesday, December 18, 2013 10:26:43 PM UTC+4, Elizabeth D. Rather wrote:
>> On 12/17/13 9:56 PM, Alexander Skobelev wrote:
>>
>>> Hello all, I'm just wondering, what is common opinion (if it
>>> exists) about using code blocks (something like 'quotes' in Retro
>>> forth) among experienced Forthers? Would it be a valuable addition
>>> to Forth?
>>>
>>> Just for example here a very naive Gforth-specific implementation
>>> of local code blocks (i.e not intended to be used anywhere but
>>> only inside a word definition):
>>>
>>
>> Could you explain what you see as the advantage of such blocks vs. Forth
>> definitions? I'm not sure what problem you're trying to solve.
>>
>
> Well, I think, such blocks could make a program code clearer.
> While they behave like a separate definition (in a sense that they are
> identified by XT and they get control with a call to EXECUTE), they
> existence is only meaningful in the context of a definition where they
> are defined.  They can be useful for iterating over array, or as arguments
> to some short-circuit operators. Of course the Forth definition can be
> used in these applications very well, but you need to create a separate
> definition. You need to think how to name it and not to clash with
> existing names. Even if it can be sit very close to the place you use it,
> it is still somewhat out of context the definition that uses it. If
> you make any changes in that definition, you need go back and check,
> if nothing has broken in that helper.
>
> So this is only a question of convenience and a language flexibility.

Sounds more like a question of programming style. In my experience, a 
sequence that's worth factoring has a conceptual name, and may as well 
be a definition. I never saw making definitions as a chore! One common 
approach for naming a major factor of NAME is (NAME), for example. I'd 
much rather see a reference to a name than a long string of code, and if 
you needed to see what the word does, you can use LOCATE on any good 
implementation.

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]

#27338

Elizabeth D. Rather wrote:
> Sounds more like a question of programming style. In my experience, a
> sequence that's worth factoring has a conceptual name, and may as well
> be a definition. I never saw making definitions as a chore! One common
> approach for naming a major factor of NAME is (NAME), for example. I'd
> much rather see a reference to a name than a long string of code, and if
> you needed to see what the word does, you can use LOCATE on any good
> implementation.

These quotations often go in some sort of what we perceive as control 
structure.  Take TRAVERSE-WORDLIST: It is an implicit loop over the words in 
a wordlist.  WORDS is something like

: words ( -- ) [: .name true ;] current @ traverse-wordlist ;

As the xt passed to traverse-wordlist needs a "continue" flag, we don't want 
to make this trivial composition a named word of its own.  .NAME is fine as 
word of its own, but a .NAME with a true flag returned wouldn't.

Another example: To wrap words which are BASE-sensitive into a secure layer 
that works even when the word crashes in the middle, we use BASE-EXECUTE.  
Usually this is a very simple word like

: dump-byte ( addr -- addr' ) count [: 2 u.r space ;] $10 base-execute ;

or so.  Factoring these two one-liners even further, and giving the snippets 
a name is too much.  If you have a lengthy piece of code, yes, please give 
it a name or more than one.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

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

#27342

Bernd Paysan wrote:
> ...
> Usually this is a very simple word like
>
> : dump-byte ( addr -- addr' ) count [: 2 u.r space ;] $10 base-execute ;
>
> or so.  Factoring these two one-liners even further, and giving the snippets
> a name is too much.  If you have a lengthy piece of code, yes, please give
> it a name or more than one.

I wonder what Chuck would say.  Names are meant to be a convenience, not
a burden.  In Forth, it's names that make definitions "readable" and re-usable
and provide access for testing/debugging.

It's one thing to strip out names after an app has been completed (e.g. you
want to make the exe smaller).  Stripping them out, or not having them
during the writing/testing phase, strikes me as counter-productive.

Nested definitions?  No thanks.

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

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

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

csiph-web