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

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

props to gforth

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

Contents

  props to gforth beeflo <beeflobill@gmail.com> - 2015-12-11 12:58 -0800
    Re: props to gforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-12-11 22:16 +0000
      Re: props to gforth beeflo <beeflobill@gmail.com> - 2015-12-11 14:50 -0800
        Re: props to gforth Paul Rubin <no.email@nospam.invalid> - 2015-12-11 15:23 -0800
      Re: props to gforth Bernd Paysan <bernd.paysan@gmx.de> - 2015-12-12 02:38 +0100
        Re: props to gforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-12-12 16:12 +0000
          Re: props to gforth Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-12-13 11:37 +0000
            Re: props to gforth Bernd Paysan <bernd.paysan@gmx.de> - 2015-12-13 22:20 +0100
    Re: props to gforth hughaguilar96@gmail.com - 2015-12-14 19:47 -0800
      Re: props to gforth beeflo <beeflobill@gmail.com> - 2015-12-16 15:50 -0800

#44198 — props to gforth

gforth developers,

Thanks a bunch for putting gforth together.  I really appreciate the quality of the tool.

It may be a small thing, but I was using some language features I expected to fail but did not.  

I have some words which make linked list objects and iterate over them.  I put them into a word called do-each which takes a linked list object and executes an xt over every element in it.

This is how do-each is defined:

\ it-new makes the iterator
\ it-more? leaves iterator object on stack, leaves flag on stack
\ it-next  leaves iterator object on stack, gives data from linked list
\ on the stack
: do-each ( ll-addr xt  -- )
   >r it-new
   begin
      it-more?
   while
      it-next r@ execute
   repeat
   free assert( 0 = ) rdrop
;

I have a structure which nests these linked lists into each other and has some other information.  I wrote a recursive call to traverse the tree and print out information.  It had basically the same form of do-each above:

\ comp-name and comp-print print other information int linked list objects
: hier-print ( list-addr -- )
   recursive
   dup comp-name ." ==> " dup comp-print cr \ print stuff
   it-new
   begin
      it-more?
   while
      it-next hier-print
   repeat
   free assert( 0 = )
;

I initially thought that do-each wouldn't be usable in the above, but then I decided to try to use do-each in the recursive call to see what would happen.  I wrote this:

: hier-print ( list-addr -- ) recursive
   dup comp-name  ." ==> " dup comp-print cr
   ['] hier-print do-each
;

I was happy to see that this works.  I can imagine some might say that's no big deal, and it might not be.  But, I think it's pretty cool.  Thanks!

[toc] | [next] | [standalone]

#44199

beeflo <beeflobill@gmail.com> writes:
>   free assert( 0 = ) rdrop

assert( 0 = )

consumes a stack item when the assertions are enabled, but does not
consume it if they are disabled.  So that's likely a bug.  A better
alternative is

assert( dup 0= )

Also, the usual way to deal with iors is to THROW them; then you also
get a more or less useful error message.

>: hier-print ( list-addr -- ) recursive
>   dup comp-name  ." ==> " dup comp-print cr
>   ['] hier-print do-each
>;

Ok, so I'm not the only one who passes the xt of the current word to
some other word.

- 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 2015: http://www.rigwit.co.uk/EuroForth2015/

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

#44200

> assert( 0 = )
> 
> consumes a stack item when the assertions are enabled, but does not
> consume it if they are disabled.  So that's likely a bug.  A better
> alternative is

I see the bug with assert being dependent on the assertion level.  I'm not sure how assert( dup 0= ) is better, but I do see how THROW is what I want.  Thanks.

> Ok, so I'm not the only one who passes the xt of the current word to
> some other word. 

Well, I thought that was pretty neat (obviously).  I like the idea of being able to factor out the looping because it sure clutters things.

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

#44201

beeflo <beeflobill@gmail.com> writes:
> I'm not sure how assert( dup 0= ) is better

It leaves the stack unchanged regardless of the assertion level.
Non-failing asserts should not change the code behaviour.

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

#44204

Anton Ertl wrote:
>>: hier-print ( list-addr -- ) recursive
>>   dup comp-name  ." ==> " dup comp-print cr
>>   ['] hier-print do-each
>>;
> 
> Ok, so I'm not the only one who passes the xt of the current word to
> some other word.

In the current development version, you can also use ['] recurse to do that.  
RECURSE there is an alias to the latest definition.  We don't go so far that 
POSTPONE RECURSE postpones the current definition; that would be a bug IMHO.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/

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

#44216

Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>>>: hier-print ( list-addr -- ) recursive
>>>   dup comp-name  ." ==> " dup comp-print cr
>>>   ['] hier-print do-each
>>>;
>> 
>> Ok, so I'm not the only one who passes the xt of the current word to
>> some other word.
>
>In the current development version, you can also use ['] recurse to do that.  
>RECURSE there is an alias to the latest definition.  We don't go so far that 
>POSTPONE RECURSE postpones the current definition; that would be a bug IMHO.

Definitely.  The following standard program would no longer work:

: my-recurse postpone recurse ; immediate
: fib dup 1 > if dup 1- my-recurse swap 2 - my-recurse + then ;
5 fib .

['] RECURSE is ambiguous, so the behaviour of the current
implementation of RECURSE for ['] RECURSE is as standard as any;
however, given that we made ['] IF give an xt for the compilation
semantics of IF, we should do that for RECURSE, too.  The current
behaviour is cute, but probably contrary to the expectations of most
programmers (at least those that are most likely to try ticking
RECURSE).

- 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 2015: http://www.rigwit.co.uk/EuroForth2015/

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

#44235

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:

>Bernd Paysan <bernd.paysan@gmx.de> writes:
>>Anton Ertl wrote:
>>>>: hier-print ( list-addr -- ) recursive
>>>>   dup comp-name  ." ==> " dup comp-print cr
>>>>   ['] hier-print do-each
>>>>;
>>>
>>> Ok, so I'm not the only one who passes the xt of the current word to
>>> some other word.
>>
>>In the current development version, you can also use ['] recurse to do that.
>>RECURSE there is an alias to the latest definition.  We don't go so far that
>>POSTPONE RECURSE postpones the current definition; that would be a bug IMHO.

>Definitely.  The following standard program would no longer work:

>: my-recurse postpone recurse ; immediate
>: fib dup 1 > if dup 1- my-recurse swap 2 - my-recurse + then ;
>5 fib .

>['] RECURSE is ambiguous, so the behaviour of the current
>implementation of RECURSE for ['] RECURSE is as standard as any;
>however, given that we made ['] IF give an xt for the compilation
>semantics of IF, we should do that for RECURSE, too.  The current
>behaviour is cute, but probably contrary to the expectations of most
>programmers (at least those that are most likely to try ticking
>RECURSE).

I've come to hate RECURSE, especially because it stands in the
way of mutual recursion and hinders factoring. (euler problems!)

I've introduced
:F aap ;
..
: noot .... aap ... ;
..
:R aap .... noot ... aap .... ;

:F is a forward definition. :R resolves it. In an indirect threaded
Forth it is just header manipulation and is not slower.
DEFER is more cumbersome to use and more difficult to read.

[In the same screen I've also  :I
:I qqq <code? ;
makes that the code of qqq is inlined. In a Forth were code is relocatable
and has a recognizable end (with a `` (;) '' that is equivalent but
distinguisable from EXIT), this is very easy to implement.
and
:2 which suppresses a redefinition message, but is otherwise identical
to : ]

P.S The DOES> part of :I can be as simple as (under above circumstances)

"
 BEGIN @+ DUP '(;) <> WHILE , REPEAT
"

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

#44239

Albert van der Horst wrote:
> I've come to hate RECURSE, especially because it stands in the
> way of mutual recursion and hinders factoring. (euler problems!)
> 
> I've introduced
> :F aap ;
> ..
> : noot .... aap ... ;
> ..
> :R aap .... noot ... aap .... ;
> 
> :F is a forward definition. :R resolves it. In an indirect threaded
> Forth it is just header manipulation and is not slower.
> DEFER is more cumbersome to use and more difficult to read.

In bigForth I've FORWARD <name>, and a definition of that <name> resolves 
it.  There are two ways to do the resolution: bigForth's is to change the 
call target, so that it is as fast as any other high level definition; the 
other possibility would be to have an AHEAD to be patched.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/

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

#44257

On Friday, December 11, 2015 at 1:58:42 PM UTC-7, beeflo wrote:
> gforth developers,
> 
> Thanks a bunch for putting gforth together.  I really appreciate the quality of the tool.
> 
> It may be a small thing, but I was using some language features I expected to fail but did not.  
> 
> I have some words which make linked list objects and iterate over them.  I put them into a word called do-each which takes a linked list object and executes an xt over every element in it.
> 
> This is how do-each is defined:
> 
> \ it-new makes the iterator
> \ it-more? leaves iterator object on stack, leaves flag on stack
> \ it-next  leaves iterator object on stack, gives data from linked list
> \ on the stack
> : do-each ( ll-addr xt  -- )
>    >r it-new
>    begin
>       it-more?
>    while
>       it-next r@ execute
>    repeat
>    free assert( 0 = ) rdrop
> ;

Your code is bad because it leaves the data-stack cluttered with internal data when it is executing the xt, so the xt word can't access the data-stack of the parent function (the function that called DO-EACH).

This is how I define EACH in my novice package:

0
    w field .fore   
constant list

: each ( i*x head 'toucher -- j*x )         \ toucher: i*x node -- j*x
    >r
    begin  dup while                        \ -- node               \r: -- 'toucher
        r@  over .fore @ >r                 \ -- node 'toucher      \r: -- 'toucher next
        execute  r> repeat drop
    rdrop ;

The FFL library had the same problem that your code does for linked lists, but it got fixed after I pointed out the problem. I doubt that any of their other data-structures were fixed however. I don't pay any attention to FFL.

> I have a structure which nests these linked lists into each other and has some other information.  I wrote a recursive call to traverse the tree and print out information.  It had basically the same form of do-each above:
> 
> \ comp-name and comp-print print other information int linked list objects
> : hier-print ( list-addr -- )
>    recursive
>    dup comp-name ." ==> " dup comp-print cr \ print stuff
>    it-new
>    begin
>       it-more?
>    while
>       it-next hier-print
>    repeat
>    free assert( 0 = )
> ;
> 
> I initially thought that do-each wouldn't be usable in the above, but then I decided to try to use do-each in the recursive call to see what would happen.  I wrote this:
> 
> : hier-print ( list-addr -- ) recursive
>    dup comp-name  ." ==> " dup comp-print cr
>    ['] hier-print do-each
> ;
> 
> I was happy to see that this works.  I can imagine some might say that's no big deal, and it might not be.  But, I think it's pretty cool.  Thanks!

I don't know what RECURSIVE does. That isn't ANS-Forth. Weirdly enough, gForth is supposedly the reference compiler for ANS-Forth, yet the gForth developers ignore the ANS-Forth standard gratuitously.

Anyway, I'm sure Anton Ertl and Bernd Paysan appreciated your telling them how wonderful they are. This guarantees that you will be considered to be an ANS-Forth programmer. They have both declared that I'm not an ANS-Forth programmer.  

I notice that they don't point out the obvious bug in your code that I pointed out --- they don't care about writing code that works correctly --- being an ANS-Forth programmer is really all about praising them, and there is no other criteria.

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

#44281

On Monday, December 14, 2015 at 8:47:50 PM UTC-7, hughag...@gmail.com wrote:
> On Friday, December 11, 2015 at 1:58:42 PM UTC-7, beeflo wrote:
> > gforth developers,
> > 
> > Thanks a bunch for putting gforth together.  I really appreciate the quality of the tool.
> > 
> > It may be a small thing, but I was using some language features I expected to fail but did not.  
> > 
> > I have some words which make linked list objects and iterate over them.  I put them into a word called do-each which takes a linked list object and executes an xt over every element in it.
> > 
> > This is how do-each is defined:
> > 
> > \ it-new makes the iterator
> > \ it-more? leaves iterator object on stack, leaves flag on stack
> > \ it-next  leaves iterator object on stack, gives data from linked list
> > \ on the stack
> > : do-each ( ll-addr xt  -- )
> >    >r it-new
> >    begin
> >       it-more?
> >    while
> >       it-next r@ execute
> >    repeat
> >    free assert( 0 = ) rdrop
> > ;
> 
> Your code is bad because it leaves the data-stack cluttered with internal data when it is executing the xt, so the xt word can't access the data-stack of the parent function (the function that called DO-EACH).
> 
> This is how I define EACH in my novice package:
> 
> 0
>     w field .fore   
> constant list
> 
> : each ( i*x head 'toucher -- j*x )         \ toucher: i*x node -- j*x
>     >r
>     begin  dup while                        \ -- node               \r: -- 'toucher
>         r@  over .fore @ >r                 \ -- node 'toucher      \r: -- 'toucher next
>         execute  r> repeat drop
>     rdrop ;
> 
> The FFL library had the same problem that your code does for linked lists, but it got fixed after I pointed out the problem. I doubt that any of their other data-structures were fixed however. I don't pay any attention to FFL.
> 

Thanks for the tip, Hugh.  I think that will be useful.


> > I have a structure which nests these linked lists into each other and has some other information.  I wrote a recursive call to traverse the tree and print out information.  It had basically the same form of do-each above:
> > 
> > \ comp-name and comp-print print other information int linked list objects
> > : hier-print ( list-addr -- )
> >    recursive
> >    dup comp-name ." ==> " dup comp-print cr \ print stuff
> >    it-new
> >    begin
> >       it-more?
> >    while
> >       it-next hier-print
> >    repeat
> >    free assert( 0 = )
> > ;
> > 
> > I initially thought that do-each wouldn't be usable in the above, but then I decided to try to use do-each in the recursive call to see what would happen.  I wrote this:
> > 
> > : hier-print ( list-addr -- ) recursive
> >    dup comp-name  ." ==> " dup comp-print cr
> >    ['] hier-print do-each
> > ;
> > 
> > I was happy to see that this works.  I can imagine some might say that's no big deal, and it might not be.  But, I think it's pretty cool.  Thanks!
> 
> I don't know what RECURSIVE does. That isn't ANS-Forth. Weirdly enough, gForth is supposedly the reference compiler for ANS-Forth, yet the gForth developers ignore the ANS-Forth standard gratuitously.
> 
> Anyway, I'm sure Anton Ertl and Bernd Paysan appreciated your telling them how wonderful they are. 

I hope so.

>This guarantees that you will be considered to be an ANS-Forth programmer. >They have both declared that I'm not an ANS-Forth programmer.  
> 
> I notice that they don't point out the obvious bug in your code that I pointed out --- they don't care about writing code that works correctly --- being an ANS-Forth programmer is really all about praising them, and there is no other criteria.

I don't think perfection is a requirement here, so I can only be happy that you decided to cover that point.

[toc] | [prev] | [standalone]

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

csiph-web