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

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

Genral advise and comments on callback style words

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

Contents

  Genral advise and comments on callback style words Chris Hinsley <chris.hinsley@gmail.com> - 2012-11-07 13:42 +0000
    Re: Genral advise and comments on callback style words Chris Hinsley <chris.hinsley@gmail.com> - 2012-11-07 13:51 +0000
      Re: Genral advise and comments on callback style words Chris Hinsley <chris.hinsley@gmail.com> - 2012-11-07 13:56 +0000
    Re: Genral advise and comments on callback style words anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-11-07 13:55 +0000
      Re: Genral advise and comments on callback style words Chris Hinsley <chris.hinsley@gmail.com> - 2012-11-07 15:29 +0000
        Re: Genral advise and comments on callback style words Chris Hinsley <chris.hinsley@gmail.com> - 2012-11-07 15:35 +0000
      Re: Genral advise and comments on callback style words Chris Hinsley <chris.hinsley@gmail.com> - 2012-11-07 15:32 +0000
      Re: Genral advise and comments on callback style words Chris Hinsley <chris.hinsley@gmail.com> - 2012-11-07 15:37 +0000
        Re: Genral advise and comments on callback style words anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-11-08 16:31 +0000
          Re: Genral advise and comments on callback style words Chris Hinsley <chris.hinsley@gmail.com> - 2012-11-08 17:02 +0000
            Re: Genral advise and comments on callback style words anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-11-08 17:07 +0000
            Re: Genral advise and comments on callback style words Mark Wills <forthfreak@gmail.com> - 2012-11-09 01:16 -0800
      Re: Genral advise and comments on callback style words Chris Hinsley <chris.hinsley@gmail.com> - 2012-11-07 15:41 +0000
        Re: Genral advise and comments on callback style words anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-11-08 16:39 +0000
    Re: Genral advise and comments on callback style words Brad Eckert <hwfwguy@gmail.com> - 2012-11-07 08:07 -0800
      Re: Genral advise and comments on callback style words Chris Hinsley <chris.hinsley@gmail.com> - 2012-11-08 12:52 +0000
    Re: Genral advise and comments on callback style words humptydumpty <ouatubi@gmail.com> - 2012-11-07 13:04 -0800
      Re: Genral advise and comments on callback style words Chris Hinsley <chris.hinsley@gmail.com> - 2012-11-08 13:04 +0000
        Re: Genral advise and comments on callback style words Mark Wills <forthfreak@gmail.com> - 2012-11-08 06:34 -0800
          Re: Genral advise and comments on callback style words Chris Hinsley <chris.hinsley@gmail.com> - 2012-11-08 14:40 +0000
      Re: Genral advise and comments on callback style words Chris Hinsley <chris.hinsley@gmail.com> - 2012-11-08 13:14 +0000
        Re: Genral advise and comments on callback style words Chris Hinsley <chris.hinsley@gmail.com> - 2012-11-08 13:23 +0000
        Re: Genral advise and comments on callback style words Ouatu Bogdan <ouatubi@gmail.com> - 2012-11-08 13:45 +0000
          Re: Genral advise and comments on callback style words Chris Hinsley <chris.hinsley@gmail.com> - 2012-11-08 13:59 +0000
          Re: Genral advise and comments on callback style words Chris Hinsley <chris.hinsley@gmail.com> - 2012-11-08 14:02 +0000
            Re: Genral advise and comments on callback style words Chris Hinsley <chris.hinsley@gmail.com> - 2012-11-08 15:35 +0000
              Re: Genral advise and comments on callback style words Chris Hinsley <chris.hinsley@gmail.com> - 2012-11-08 16:24 +0000
                Re: Genral advise and comments on callback style words Chris Hinsley <chris.hinsley@gmail.com> - 2012-11-08 16:39 +0000
                  Re: Genral advise and comments on callback style words Chris Hinsley <chris.hinsley@gmail.com> - 2012-11-08 16:57 +0000
                    Re: Genral advise and comments on callback style words "Elizabeth D. Rather" <erather@forth.com> - 2012-11-08 07:56 -1000
    Re: Genral advise and comments on callback style words Josh Grams <josh@qualdan.com> - 2012-11-08 13:54 +0000
      Re: Genral advise and comments on callback style words Chris Hinsley <chris.hinsley@gmail.com> - 2012-11-08 14:06 +0000
        Re: Genral advise and comments on callback style words Josh Grams <josh@qualdan.com> - 2012-11-08 18:04 +0000
          Re: Genral advise and comments on callback style words Chris Hinsley <chris.hinsley@gmail.com> - 2012-11-08 19:36 +0000
          Re: Genral advise and comments on callback style words Chris Hinsley <chris.hinsley@gmail.com> - 2012-11-08 19:38 +0000
            Re: Genral advise and comments on callback style words Chris Hinsley <chris.hinsley@gmail.com> - 2012-11-08 19:42 +0000
      Re: Genral advise and comments on callback style words Chris Hinsley <chris.hinsley@gmail.com> - 2012-11-08 14:11 +0000
        Re: Genral advise and comments on callback style words Chris Hinsley <chris.hinsley@gmail.com> - 2012-11-08 14:31 +0000
          Re: Genral advise and comments on callback style words Chris Hinsley <chris.hinsley@gmail.com> - 2012-11-08 14:51 +0000
            Re: Genral advise and comments on callback style words Josh Grams <josh@qualdan.com> - 2012-11-08 18:23 +0000
              Re: Genral advise and comments on callback style words Chris Hinsley <chris.hinsley@gmail.com> - 2012-11-08 19:57 +0000
              Re: Genral advise and comments on callback style words Chris Hinsley <chris.hinsley@gmail.com> - 2012-11-08 20:04 +0000
                Re: Genral advise and comments on callback style words Chris Hinsley <chris.hinsley@gmail.com> - 2012-11-08 20:17 +0000
                  Re: Genral advise and comments on callback style words Chris Hinsley <chris.hinsley@gmail.com> - 2012-11-08 20:29 +0000
                    Re: Genral advise and comments on callback style words Chris Hinsley <chris.hinsley@gmail.com> - 2012-11-08 20:50 +0000

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

#17115 — Genral advise and comments on callback style words

Folks I have implamented an Amiga style double linked list words set a 
few days back and I have an emueration word as follows:

\ ( u xt lh -- ln | 0)
\ xt api is ( u ln lh -- ln | 0 )
: LISTHEAD-ENUMERATE-FORWARDS
	0 >R
	DUP LISTHEAD-GET-HEAD DUP
	BEGIN
		NIP DUP LISTNODE-GET-SUCC
		DUP
	WHILE
		4 PICK 2 PICK 4 PICK
		6 PICK EXECUTE DUP R!
	UNTIL THEN
	2DROP 2DROP DROP
	R>
;

This scans down the list until either it hits the end, or the callback 
for each node returns a value other than 0, that value is returned and 
the scan stops if it isn't 0 !

I'd like comments and advice on techniuqe, paticularly for things like 
the PICK stuff that gathers paramaters for each callback, and the use 
of the return stack for the returned value. Or if you just plain think 
I could code this a better way !

I'm not wanting to be pointed to "the novice package", thank you, but 
want this API as stated ! ;)

Regards all

Chris

[toc] | [next] | [standalone]

#17116

On 2012-11-07 13:42:18 +0000, Chris Hinsley said:

> Folks I have implamented an Amiga style double linked list words set a 
> few days back and I have an emueration word as follows:
> 
> \ ( u xt lh -- ln | 0)
> \ xt api is ( u ln lh -- ln | 0 )
> : LISTHEAD-ENUMERATE-FORWARDS
> 	0 >R
> 	DUP LISTHEAD-GET-HEAD DUP
> 	BEGIN
> 		NIP DUP LISTNODE-GET-SUCC
> 		DUP
> 	WHILE
> 		4 PICK 2 PICK 4 PICK
> 		6 PICK EXECUTE DUP R!
> 	UNTIL THEN
> 	2DROP 2DROP DROP
> 	R>
> ;
> 
> This scans down the list until either it hits the end, or the callback 
> for each node returns a value other than 0, that value is returned and 
> the scan stops if it isn't 0 !
> 
> I'd like comments and advice on techniuqe, paticularly for things like 
> the PICK stuff that gathers paramaters for each callback, and the use 
> of the return stack for the returned value. Or if you just plain think 
> I could code this a better way !
> 
> I'm not wanting to be pointed to "the novice package", thank you, but 
> want this API as stated ! ;)
> 
> Regards all
> 
> Chris

I should also add that I wish to retain the 'look ahead' pointer to the 
next node as the callback word must be allowed to remove or modify the 
node it gets handed ! So the 'NIP DUP LISTNODE-GET-SUCC' is the bit 
doing that.

Chris

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

#17117

On 2012-11-07 13:51:23 +0000, Chris Hinsley said:

> On 2012-11-07 13:42:18 +0000, Chris Hinsley said:
> 
>> Folks I have implamented an Amiga style double linked list words set a 
>> few days back and I have an emueration word as follows:
>> 
>> \ ( u xt lh -- ln | 0)
>> \ xt api is ( u ln lh -- ln | 0 )
>> : LISTHEAD-ENUMERATE-FORWARDS
>> 	0 >R
>> 	DUP LISTHEAD-GET-HEAD DUP
>> 	BEGIN
>> 		NIP DUP LISTNODE-GET-SUCC
>> 		DUP
>> 	WHILE
>> 		4 PICK 2 PICK 4 PICK
>> 		6 PICK EXECUTE DUP R!
>> 	UNTIL THEN
>> 	2DROP 2DROP DROP
>> 	R>
>> ;
>> 
>> This scans down the list until either it hits the end, or the callback 
>> for each node returns a value other than 0, that value is returned and 
>> the scan stops if it isn't 0 !
>> 
>> I'd like comments and advice on techniuqe, paticularly for things like 
>> the PICK stuff that gathers paramaters for each callback, and the use 
>> of the return stack for the returned value. Or if you just plain think 
>> I could code this a better way !
>> 
>> I'm not wanting to be pointed to "the novice package", thank you, but 
>> want this API as stated ! ;)
>> 
>> Regards all
>> 
>> Chris
> 
> I should also add that I wish to retain the 'look ahead' pointer to the 
> next node as the callback word must be allowed to remove or modify the 
> node it gets handed ! So the 'NIP DUP LISTNODE-GET-SUCC' is the bit 
> doing that.
> 
> Chris

Plus I do need to pass the list head into the callback, as they are 
allowed to add elements to the list as a result of scanning it etc. For 
example I have a 2D rectangle patch list and callbacks that can cut, 
paste or copy new patches to/from the list, as the callback slices and 
dices patches on the list new entires are add to the front of the list 
etc, and the current node can be removed entirely...

Chris

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

#17119

Chris Hinsley <chris.hinsley@gmail.com> writes:
>Folks I have implamented an Amiga style double linked list words set a 
>few days back and I have an emueration word as follows:
>
>\ ( u xt lh -- ln | 0)
>\ xt api is ( u ln lh -- ln | 0 )
>: LISTHEAD-ENUMERATE-FORWARDS
>	0 >R
>	DUP LISTHEAD-GET-HEAD DUP
>	BEGIN
>		NIP DUP LISTNODE-GET-SUCC
>		DUP
>	WHILE
>		4 PICK 2 PICK 4 PICK
>		6 PICK EXECUTE DUP R!
>	UNTIL THEN
>	2DROP 2DROP DROP
>	R>
>;
>
>This scans down the list until either it hits the end, or the callback 
>for each node returns a value other than 0, that value is returned and 
>the scan stops if it isn't 0 !
>
>I'd like comments and advice on techniuqe, paticularly for things like 
>the PICK stuff that gathers paramaters for each callback, and the use 
>of the return stack for the returned value. Or if you just plain think 
>I could code this a better way !

Someone could probably code this in a better way.  "6 PICK" is gross.
And having no lower case does not help readability.

However, the may thing I want to point out is that in my experience
it's a good idea if the wrapper word (LISTHEAD-ENUMERATE-FORWARDS in
this case) does not keep its data on the data stack during the
callback, and thus allows the caller to pass additional data to the
called-back word (which can then pass data to the next invocation of
the called-back word etc.).  I.e., the stack effect of
LISTHEAD-ENUMERATE-FORWARDS might be ( i*x u xt lh -- i*x <ln|0> ),
and the stack effect of the xt would then be ( i*x u ln lh -- i*x
<ln|0> ).

Another (independent) question is whether one should pass an xt or use
a different approach.  We discussed this some time ago, and Andrew
Haley proposed writing two macros that one would put before and after
the "called-back" code, as in

... <listhead-enum-forward "called-back"-code listhead-enum-forward> ...

The advantages are that the called-back code can consist of several
words and you avoid the overhead of EXECUTUE.  The disadvantage is
that you can only use this inside colon definitions.

- 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 2012: http://www.euroforth.org/ef12/

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

#17121

On 2012-11-07 13:55:19 +0000, Anton Ertl said:

> Chris Hinsley <chris.hinsley@gmail.com> writes:
>> Folks I have implamented an Amiga style double linked list words set a
>> few days back and I have an emueration word as follows:
>> 
>> \ ( u xt lh -- ln | 0)
>> \ xt api is ( u ln lh -- ln | 0 )
>> : LISTHEAD-ENUMERATE-FORWARDS
>> 	0 >R
>> 	DUP LISTHEAD-GET-HEAD DUP
>> 	BEGIN
>> 		NIP DUP LISTNODE-GET-SUCC
>> 		DUP
>> 	WHILE
>> 		4 PICK 2 PICK 4 PICK
>> 		6 PICK EXECUTE DUP R!
>> 	UNTIL THEN
>> 	2DROP 2DROP DROP
>> 	R>
>> ;
>> 
>> This scans down the list until either it hits the end, or the callback
>> for each node returns a value other than 0, that value is returned and
>> the scan stops if it isn't 0 !
>> 
>> I'd like comments and advice on techniuqe, paticularly for things like
>> the PICK stuff that gathers paramaters for each callback, and the use
>> of the return stack for the returned value. Or if you just plain think
>> I could code this a better way !
> 
> Someone could probably code this in a better way.  "6 PICK" is gross.
> And having no lower case does not help readability.

Yes, I know, which is why I asked the question in the first place ! I 
didn't see any easier way to marshall paramaters for the callback. But 
I was unhappy, hence my question about style and wanting to get the 
beards involved ;)

Chris

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

#17123

On 2012-11-07 15:29:31 +0000, Chris Hinsley said:

> On 2012-11-07 13:55:19 +0000, Anton Ertl said:
> 
>> Chris Hinsley <chris.hinsley@gmail.com> writes:
>>> Folks I have implamented an Amiga style double linked list words set a
>>> few days back and I have an emueration word as follows:
>>> 
>>> \ ( u xt lh -- ln | 0)
>>> \ xt api is ( u ln lh -- ln | 0 )
>>> : LISTHEAD-ENUMERATE-FORWARDS
>>> 	0 >R
>>> 	DUP LISTHEAD-GET-HEAD DUP
>>> 	BEGIN
>>> 		NIP DUP LISTNODE-GET-SUCC
>>> 		DUP
>>> 	WHILE
>>> 		4 PICK 2 PICK 4 PICK
>>> 		6 PICK EXECUTE DUP R!
>>> 	UNTIL THEN
>>> 	2DROP 2DROP DROP
>>> 	R>
>>> ;
>>> 
>>> This scans down the list until either it hits the end, or the callback
>>> for each node returns a value other than 0, that value is returned and
>>> the scan stops if it isn't 0 !
>>> 
>>> I'd like comments and advice on techniuqe, paticularly for things like
>>> the PICK stuff that gathers paramaters for each callback, and the use
>>> of the return stack for the returned value. Or if you just plain think
>>> I could code this a better way !
>> 
>> Someone could probably code this in a better way.  "6 PICK" is gross.
>> And having no lower case does not help readability.
> 
> Yes, I know, which is why I asked the question in the first place ! I 
> didn't see any easier way to marshall paramaters for the callback. But 
> I was unhappy, hence my question about style and wanting to get the 
> beards involved ;)
> 
> Chris

Plus you guys like nothing better than some young upstart asking a 
'dork' question (maybe I'm just widing you up !) that you can then 
argue the toss over for several days. Oh yes, and Hugh can then wade in 
and insult anybody he thinks deserves a kicking, then you can all slag 
him off, then he mentions Nazi's and you all sit back and mark another 
win on your bedpost's ;)

Chris

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

#17122

On 2012-11-07 13:55:19 +0000, Anton Ertl said:

> Chris Hinsley <chris.hinsley@gmail.com> writes:
>> Folks I have implamented an Amiga style double linked list words set a
>> few days back and I have an emueration word as follows:
>> 
>> \ ( u xt lh -- ln | 0)
>> \ xt api is ( u ln lh -- ln | 0 )
>> : LISTHEAD-ENUMERATE-FORWARDS
>> 	0 >R
>> 	DUP LISTHEAD-GET-HEAD DUP
>> 	BEGIN
>> 		NIP DUP LISTNODE-GET-SUCC
>> 		DUP
>> 	WHILE
>> 		4 PICK 2 PICK 4 PICK
>> 		6 PICK EXECUTE DUP R!
>> 	UNTIL THEN
>> 	2DROP 2DROP DROP
>> 	R>
>> ;
>> 
>> This scans down the list until either it hits the end, or the callback
>> for each node returns a value other than 0, that value is returned and
>> the scan stops if it isn't 0 !
>> 
>> I'd like comments and advice on techniuqe, paticularly for things like
>> the PICK stuff that gathers paramaters for each callback, and the use
>> of the return stack for the returned value. Or if you just plain think
>> I could code this a better way !
> 
> Someone could probably code this in a better way.  "6 PICK" is gross.
> And having no lower case does not help readability.

I'm having issues with the whole case stuff in Forth. I really don't 
like the idea of a case sensative Forth, but feel compeled to write in 
a single case ! Upper case so far, but I could easily swap if the 
powers that be say I should. ;)

Chris

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

#17124

> However, the may thing I want to point out is that in my experience
> it's a good idea if the wrapper word (LISTHEAD-ENUMERATE-FORWARDS in
> this case) does not keep its data on the data stack during the
> callback, and thus allows the caller to pass additional data to the
> called-back word

The u paramater here is exactly that ! A user data value, pointer to 
structure or whatever. It can be used to pass information to the 
callback or be used by the callback to pass data onto the next callback 
invocation etc. It's very flexable.

Chris

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

#17166

Chris Hinsley <chris.hinsley@gmail.com> writes:
>> However, the may thing I want to point out is that in my experience
>> it's a good idea if the wrapper word (LISTHEAD-ENUMERATE-FORWARDS in
>> this case) does not keep its data on the data stack during the
>> callback, and thus allows the caller to pass additional data to the
>> called-back word
>
>The u paramater here is exactly that ! A user data value, pointer to 
>structure or whatever. It can be used to pass information to the 
>callback or be used by the callback to pass data onto the next callback 
>invocation etc. It's very flexable.

It's even more flexible if you avoid any internal data on the data
stack during the callback, because that allows passing an arbitrary
number of stack elements into and out of the callback, not just one.

- 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 2012: http://www.euroforth.org/ef12/

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

#17170

On 2012-11-08 16:31:34 +0000, Anton Ertl said:

> Chris Hinsley <chris.hinsley@gmail.com> writes:
>>> However, the may thing I want to point out is that in my experience
>>> it's a good idea if the wrapper word (LISTHEAD-ENUMERATE-FORWARDS in
>>> this case) does not keep its data on the data stack during the
>>> callback, and thus allows the caller to pass additional data to the
>>> called-back word
>> 
>> The u paramater here is exactly that ! A user data value, pointer to
>> structure or whatever. It can be used to pass information to the
>> callback or be used by the callback to pass data onto the next callback
>> invocation etc. It's very flexable.
> 
> It's even more flexible if you avoid any internal data on the data
> stack during the callback, because that allows passing an arbitrary
> number of stack elements into and out of the callback, not just one.
> 
> - anton

Yes, but then surely there will just be similar issues with marshalling 
multiple paramaters on the data stack in the callback and an arguement 
for just passing in a structure pointer and letting the callback 
accsess that structure as required ? It all get's tricky to judge the 
best approach, but I have this API used in other projects in C/C++, so 
kind of like the familiarity of how it works.

Chris

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

#17171

Chris Hinsley <chris.hinsley@gmail.com> writes:
>On 2012-11-08 16:31:34 +0000, Anton Ertl said:
>> It's even more flexible if you avoid any internal data on the data
>> stack during the callback, because that allows passing an arbitrary
>> number of stack elements into and out of the callback, not just one.
...
>Yes, but then surely there will just be similar issues with marshalling 
>multiple paramaters on the data stack in the callback and an arguement 
>for just passing in a structure pointer and letting the callback 
>accsess that structure as required ?

I don't know what you mean with "marshalling" here, it's different
from the usage of the word I am familiar with.  If it's more
convenient to pass a pointer to a structure, then do that, but often
it's more convenient to pass the stuff directly on the stack.

> It all get's tricky to judge the 
>best approach, but I have this API used in other projects in C/C++, so 
>kind of like the familiarity of how it works.

Sure, in C/C++ you have no choice.  But just because these languages
have this limitation, there is no reason to apply the same limitation
in Forth if it can be avoided.

- 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 2012: http://www.euroforth.org/ef12/

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

#17197

On Nov 8, 5:02 pm, Chris Hinsley <chris.hins...@gmail.com> wrote:
> On 2012-11-08 16:31:34 +0000, Anton Ertl said:
>
>
>
>
>
> > Chris Hinsley <chris.hins...@gmail.com> writes:
> >>> However, the may thing I want to point out is that in my experience
> >>> it's a good idea if the wrapper word (LISTHEAD-ENUMERATE-FORWARDS in
> >>> this case) does not keep its data on the data stack during the
> >>> callback, and thus allows the caller to pass additional data to the
> >>> called-back word
>
> >> The u paramater here is exactly that ! A user data value, pointer to
> >> structure or whatever. It can be used to pass information to the
> >> callback or be used by the callback to pass data onto the next callback
> >> invocation etc. It's very flexable.
>
> > It's even more flexible if you avoid any internal data on the data
> > stack during the callback, because that allows passing an arbitrary
> > number of stack elements into and out of the callback, not just one.
>
> > - anton
>
> Yes, but then surely there will just be similar issues with marshalling
> multiple paramaters on the data stack in the callback and an arguement
> for just passing in a structure pointer and letting the callback
> accsess that structure as required ? It all get's tricky to judge the
> best approach, but I have this API used in other projects in C/C++, so
> kind of like the familiarity of how it works.
>
> Chris- Hide quoted text -
>
> - Show quoted text -

I don't see why you are against passing pointers to structures? Much
neater IMHO. And, if you're after the "Amiga Experience" then you need
*lots* more structures than you have at the moment! :-)

I remember my Amiga programming days from the early 90's. I was lucky
enough to be paid professionally to do it. I always tended to use 68K
though, rather than C, because the instruction set was so good. Still,
I remember interfacing with the OS required a lot of boiler plate to
fill in the structures required, calls to amiga.library etc... Ah...
Those were the days.

It's structure-ville on the Atari ST too the moment you need to
interface with the OS in any way. Sheesh. Don't try drop down menu's
on the ST. OMG! :-/

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

#17125

> The advantages are that the called-back code can consist of several
> words and you avoid the overhead of EXECUTUE.  The disadvantage is
> that you can only use this inside colon definitions.
> 
> - anton

Well execute is INLINE, on my setup, so the overhead is pretty minimal. 
It just end's up being a 'call addr', or a 'call [ebx]', or switched to 
a jmp if followed by exit etc.

Chris

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

#17168

Chris Hinsley <chris.hinsley@gmail.com> writes:
>> The advantages are that the called-back code can consist of several
>> words and you avoid the overhead of EXECUTUE.  The disadvantage is
>> that you can only use this inside colon definitions.
>> 
>> - anton
>
>Well execute is INLINE, on my setup, so the overhead is pretty minimal. 
>It just end's up being a 'call addr', or a 'call [ebx]', or switched to 
>a jmp if followed by exit etc.

On more sophisticated systems (like VFX) the main overhead is that the
stack elements have to be transferred to the canonical places
(typically in memory) instead of staying in the registers where they
are now, and that overhead may by bigger than the payload of the
callback.

- 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 2012: http://www.euroforth.org/ef12/

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

#17126

Two comments:

1. You are using really long names for some words. Name collisions aren't necessarily bad, so you don't have to go out of your way (like using 26-character names) to avoid them. Sure, don't step on a system word that you'll need later, but it's okay to have a HEAD that is only needed in this scope. Even if later code redefines HEAD to mean something else. Just make sure you have a means to test the earlier HEAD.

2. Factor more. BEGIN this WHILE that REPEAT (what's with the UNTIL THEN?) where this and that are separate words. When you find yourself using 6 PICK, you know it's time to re-factor.

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

#17147

On 2012-11-07 16:07:35 +0000, Brad Eckert said:

> Two comments:
> 
> 1. You are using really long names for some words. Name collisions 
> aren't necessarily bad, so you don't have to go out of your way (like 
> using 26-character names) to avoid them. Sure, don't step on a system 
> word that you'll need later, but it's okay to have a HEAD that is only 
> needed in this scope. Even if later code redefines HEAD to mean 
> something else. Just make sure you have a means to test the earlier 
> HEAD.

I was once into TLA's for practically everything, variables, functions 
names, the lot. In recent years I've tended to go for more verbose but 
much more readable meaningful stuff, makes the code much more self 
documenting. What is the official standard for how many letters are 
significant in Forth these days ?

> 
> 2. Factor more. BEGIN this WHILE that REPEAT (what's with the UNTIL 
> THEN?) where this and that are separate words. When you find yourself 
> using 6 PICK, you know it's time to re-factor.

The 'until then' lets me not have to do a '0= while then' I can drop 
the 0= and just do 'until then' ? Is this a bad thing ? Seam's I'd need 
the extra 'then' in both cases.

I'm not convinced about refactoring in this case ! And I'm not 
convinced about the rabid dislike of PICK ! This is no worse than what 
a C compiler would do to accsess the paramaters of a function ?

IF I had an auto inlining optimizing compiler then yes, I'd factor it 
more, but I don't and most Forth's arn't ! So I'd like to get 
reasonable speed with the simple compiler I've created.

Chris

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

#17129

On Wednesday, November 7, 2012 1:42:19 PM UTC, Chris Hinsley wrote:
> Folks I have implamented an Amiga style double linked list words set a 
> 
> few days back and I have an emueration word as follows:
> 
> 
> 
> \ ( u xt lh -- ln | 0)
> 
> \ xt api is ( u ln lh -- ln | 0 )
> 
> : LISTHEAD-ENUMERATE-FORWARDS
> 
> 	0 >R
> 
> 	DUP LISTHEAD-GET-HEAD DUP
> 
> 	BEGIN
> 
> 		NIP DUP LISTNODE-GET-SUCC
> 
> 		DUP
> 
> 	WHILE
> 
> 		4 PICK 2 PICK 4 PICK
> 
> 		6 PICK EXECUTE DUP R!
> 
> 	UNTIL THEN
> 
> 	2DROP 2DROP DROP
> 
> 	R>
> 
> ;
> 
> 
> 
> This scans down the list until either it hits the end, or the callback 
> 
> for each node returns a value other than 0, that value is returned and 
> 
> the scan stops if it isn't 0 !
> 
> 
> 
> I'd like comments and advice on techniuqe, paticularly for things like 
> 
> the PICK stuff that gathers paramaters for each callback, and the use 
> 
> of the return stack for the returned value. Or if you just plain think 
> 
> I could code this a better way !
> 
> 
> 
> I'm not wanting to be pointed to "the novice package", thank you, but 
> 
> want this API as stated ! ;)
> 
> 
> 
> Regards all
> 
> 
> 
> Chris

Hi!

Building backward from EXECUTE and applying desired stack-effects,
I've got:

: HEAD ( lh -- ln )   ; 
: SUCC ( ln -- ln' )  ;             


\ xt ( u ln lh--R|0 )  
: ENUMERATE     ( u xt lh -- R|0 )
( u xt lh )             swap >R
( u lh )                dup HEAD
( u lh ln )
                        BEGIN
( u lh ln   )                   dup SUCC dup 0=         
( u lh ln   ln' f )             IF  RDROP 2drop 2drop 0 EXIT THEN         
( u lh ln   ln' )               swap 2over        
( u lh ln'  ln u lh )           rot swap R@         
( u lh ln'  u ln lh xt )        EXECUTE dup 
( u lh ln'  R f=R )             IF  RDROP   nip nip nip EXIT THEN 
( u lh ln'  R )                 drop
( u lh ln'  )           AGAIN
;

Question:
what happens if `execute'-ing xt invalidate the succesor `ln'' ?

Have a nice day,
humptydumpty 

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

#17148

On 2012-11-07 21:04:20 +0000, humptydumpty said:

> On Wednesday, November 7, 2012 1:42:19 PM UTC, Chris Hinsley wrote:
>> Folks I have implamented an Amiga style double linked list words set a
>> 
>> few days back and I have an emueration word as follows:
>> 
>> 
>> 
>> \ ( u xt lh -- ln | 0)
>> 
>> \ xt api is ( u ln lh -- ln | 0 )
>> 
>> : LISTHEAD-ENUMERATE-FORWARDS
>> 
>> 	0 >R
>> 
>> 	DUP LISTHEAD-GET-HEAD DUP
>> 
>> 	BEGIN
>> 
>> 		NIP DUP LISTNODE-GET-SUCC
>> 
>> 		DUP
>> 
>> 	WHILE
>> 
>> 		4 PICK 2 PICK 4 PICK
>> 
>> 		6 PICK EXECUTE DUP R!
>> 
>> 	UNTIL THEN
>> 
>> 	2DROP 2DROP DROP
>> 
>> 	R>
>> 
>> ;
>> 
>> 
>> 
>> This scans down the list until either it hits the end, or the callback
>> 
>> for each node returns a value other than 0, that value is returned and
>> 
>> the scan stops if it isn't 0 !
>> 
>> 
>> 
>> I'd like comments and advice on techniuqe, paticularly for things like
>> 
>> the PICK stuff that gathers paramaters for each callback, and the use
>> 
>> of the return stack for the returned value. Or if you just plain think
>> 
>> I could code this a better way !
>> 
>> 
>> 
>> I'm not wanting to be pointed to "the novice package", thank you, but
>> 
>> want this API as stated ! ;)
>> 
>> 
>> 
>> Regards all
>> 
>> 
>> 
>> Chris
> 
> Hi!
> 
> Building backward from EXECUTE and applying desired stack-effects,
> I've got:
> 
> : HEAD ( lh -- ln )   ;
> : SUCC ( ln -- ln' )  ;
> 
> 
> \ xt ( u ln lh--R|0 )
> : ENUMERATE     ( u xt lh -- R|0 )
> ( u xt lh )             swap >R
> ( u lh )                dup HEAD
> ( u lh ln )
>                         BEGIN
> ( u lh ln   )                   dup SUCC dup 0=
> ( u lh ln   ln' f )             IF  RDROP 2drop 2drop 0 EXIT THEN
> ( u lh ln   ln' )               swap 2over
> ( u lh ln'  ln u lh )           rot swap R@
> ( u lh ln'  u ln lh xt )        EXECUTE dup
> ( u lh ln'  R f=R )             IF  RDROP   nip nip nip EXIT THEN
> ( u lh ln'  R )                 drop
> ( u lh ln'  )           AGAIN
> ;
> 
> Question:
> what happens if `execute'-ing xt invalidate the succesor `ln'' ?

See my follow up reply to my original posting about that. The callback 
_must_ be able to remove, if needed, the current list node, so the 
succeeding ln must be keeped safe before the callback.

What are people thoughts on having EXIT or in this case multiple EXIT's 
in the middle of words ? It's not very 'stuctured', but maybe that 
dosn't matter. It could have a bad effect on simple inlineing Forth's ? 
ie, if inlining just copys the code of the word inline minus the 'ret' 
at the end ?

I did think about having this double EXIT and IF,THEN stuff, but the 
idea of having 2 taken branches, asside from the loop repeat per 
iteration put me off. My posted version has 2 none taken branches, 
granted that the x86 branch predicter probably folds both these ways 
into the same thing these days, but other cpu's it might be an issue, 
certainly I've been brought up to think taken branches are a big no no 
:)

> 
> Have a nice day,
> humptydumpty

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

#17158

On Nov 8, 1:04 pm, Chris Hinsley <chris.hins...@gmail.com> wrote:
> What are people thoughts on having EXIT or in this case multiple EXIT's
> in the middle of words ? It's not very 'stuctured', but maybe that
> dosn't matter. It could have a bad effect on simple inlineing Forth's ?
> ie, if inlining just copys the code of the word inline minus the 'ret'
> at the end ?


My novice understanding/opinion of that is: As soon as you determine
that you need to exit, just exit. Don't the do the "set a flag to be
caught somewhere else to effect the exit" thing or the "set the loop
exit condition to make the code drop out at the bottom of the loop"
thing like you would do in more constrained/highly structured
languages. There's no shame in EXIT. It's there, so use it ;-)

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

#17159

On 2012-11-08 14:34:27 +0000, Mark Wills said:

> On Nov 8, 1:04 pm, Chris Hinsley <chris.hins...@gmail.com> wrote:
>> What are people thoughts on having EXIT or in this case multiple EXIT's
>> in the middle of words ? It's not very 'stuctured', but maybe that
>> dosn't matter. It could have a bad effect on simple inlineing Forth's ?
>> ie, if inlining just copys the code of the word inline minus the 'ret'
>> at the end ?
> 
> 
> My novice understanding/opinion of that is: As soon as you determine
> that you need to exit, just exit. Don't the do the "set a flag to be
> caught somewhere else to effect the exit" thing or the "set the loop
> exit condition to make the code drop out at the bottom of the loop"
> thing like you would do in more constrained/highly structured
> languages. There's no shame in EXIT. It's there, so use it ;-)

Yeah. I'm still not keen on introduceing extra taken branches into the 
loop iteration though ! :(

Chris

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

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

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

csiph-web