00:10:52
##forth
<amby>
i expect it varies depending on how many pixels you're changing
00:22:00
##forth
<crc>
I've not seen any clear answers on that
18:57:45
##forth
<user51>
How can words like IF and BEGIN work in normal mode?
18:57:53
##forth
<user51>
Let's not get started on RECURSE :)
20:06:10
##forth
<veltas>
user51: They would skip input, and return back to start of input, by modifying >IN
20:06:16
##forth
<veltas>
That's how [IF] [THEN] work
20:06:27
##forth
<veltas>
And how I write loops with [IF] [THEN]
20:07:34
##forth
<veltas>
e.g. 10 DUP [IF] 1- . 4 >IN ! [THEN]
20:08:31
##forth
<veltas>
However I think this is pointless because it's quite limited, inconvenient, it can be *very* slow on some systems, and it's trivial to write/forget a word for a loop
20:18:57
##forth
<pgimeno>
I've been thinking about that; one idea is to compile to a temporary word and execute it when the token stack is balanced again
20:20:39
##forth
<pgimeno>
not applicable to RECURSE, of course
20:21:27
##forth
<pgimeno>
I don't understand why RECURSE had to be introduced though, is it really that common to use the previous definition of a word when compiling it?
20:23:07
##forth
<pgimeno>
!gforth : a ." previous def;" ; : a ." new def;" a ." new again;" ; a
20:23:27
##forth
<pgimeno>
gforth
20:24:12
##forth
<pgimeno>
oops, I mean, gforth_eval_bot is gone, didn't notice
20:26:18
##forth
<pgimeno>
to me it's just natural to use the name of the word being defined; the juppy does that
21:15:47
##forth
<veltas>
I think it's quite common to extend existing words
21:16:05
##forth
<veltas>
e.g. add overflow detection to a stack word
21:17:33
##forth
<veltas>
It also works as a sort of private namespace mechanism, I suppose
21:17:47
##forth
<veltas>
You just build up a definition by constantly redefining smaller pieces with the same name