IRC Log - 2025-02-04 - ##forth

Channel: ##forth
Total messages: 104
Time range: 07:34:45 - 22:24:50
Most active: vms14 (65), pgimeno (14), veltas (10)
07:34:45 ##forth <vms14> pgimeno I think I have found a way to optimize recursion into a loop even if it's not a tail call
07:34:57 ##forth <vms14> I have to try it yet
07:37:09 ##forth <vms14> instead of duplicating the same code on the return stack or whatever I use, the code will not change so I increment a counter and when the recursion ends I evaluate the remaining code that number of times
08:37:03 ##forth <vms14> : oh 1- dup 0= 'exit if oh 1+ 1+ ;
08:37:14 ##forth <vms14> that's the version in my toy lang
08:37:34 ##forth <vms14> returns 12 like gforth did
08:38:36 ##forth <vms14> with the remaining (1+ 1+) I save that and every time I recurse I increment a counter
08:39:18 ##forth <vms14> once recursion ends I just evaluate that (1+ 1+) the number of times of the counter
08:40:59 ##forth <vms14> so no matter how much it recurses there is no call stack, but an array that only has the size of two elements (1+ 1+) and will not grow during recursion
08:49:04 ##forth <vms14> in gforth
08:49:07 ##forth <vms14> : test 1- dup 0= if exit then recurse 1+ 1+ ;
08:49:22 ##forth <vms14> 300000 test . cr => return stack overflow
08:50:53 ##forth <vms14> in my lang returns 599998
08:50:53 ##forth <vms14> but I'm not sure if it's working fine or just the return stack of perl is bigger
09:12:46 ##forth <vms14> 1000000 oh => 1999998
09:18:45 ##forth <vms14> I cannot find a way to have multiple branches though
09:26:22 ##forth <veltas> That's interesting
09:26:39 ##forth <GeDaMo> Multiple branches?
09:26:56 ##forth <veltas> No, recursive -> loop optimisation
09:27:20 ##forth <GeDaMo> Sorry, I missed the start of this :P
09:27:43 ##forth <veltas> No problemo
09:30:56 ##forth <veltas> Multiple branches is interesting though, the reason you can't is because I think you'd need a stack to track what post-effects to apply
09:30:56 ##forth <veltas> I.E. there's no benefit to looping
09:31:15 ##forth <veltas> But if there's only one post-effect you can track how many times with a counter and just loop, so there's less memory usage
09:32:49 ##forth <veltas> If the post-effects were commutative you could have two counters for two branches
09:32:56 ##forth <veltas> etc
10:27:15 ##forth <vms14> yeah I can only give id to the branches and store a sequence of those id
10:27:26 ##forth <vms14> then use compression mechanisms
10:28:10 ##forth <vms14> GeDaMo use the irc log
10:28:24 ##forth <GeDaMo> This channel is logged?
10:29:07 ##forth <GeDaMo> That should really be mentioned in the /topic
10:29:19 ##forth <vms14> it is
10:29:37 ##forth <vms14> | http://forth.chat for more information, related channels, public logs of the channel, and notes on the bots
10:29:44 ##forth <GeDaMo> Oh yeah :P
10:43:16 ##forth <vms14> the one branch can be unlimited since you can use an additional counter for when the counter wraps when reaches it's maximum value
10:44:07 ##forth <vms14> to count how many times it wraps and make a nested loop
10:44:47 ##forth <vms14> and if the wrap counter also wraps you make another counter and so on xd
10:45:07 ##forth <vms14> well eventually will die
10:46:18 ##forth <vms14> for the multiple branches I was thinking that if you detect patterns like 123123123 you can use a hash table or alike to save that as x => 123123123 and store the x in the sequence instead, then decode when evaluating
12:09:20 ##forth <crc> GeDaMo: in addition to the mention in the channel title, there is a channel join message that mentions the channel being publicly logged
12:09:48 ##forth <GeDaMo> I don't think I get that one
12:12:08 ##forth <crc> probably depends on the client, some don't make it easy to see channel welcome messages. (e.g., irccloud dumps these into the main server messages listing)
13:03:44 ##forth <xentrac> some very small CPUs used to use LFSRs for their program counters, and for example the Atari 2600 used one for its X-coordinate pixel counter
13:04:34 ##forth <xentrac> a fun thing I realized the other day about LFSR program counters is that they allow you to have conditional branch instructions that don't specify a destination
13:05:28 ##forth <xentrac> I don't think any architecture has ever done this
13:07:17 ##forth <xentrac> because almost any trivial modification you make to the program counter, such as toggling the LSB, will put you on an almost arbitrarily far away part of the LFSR sequence
15:08:35 ##forth <pgimeno> vms14: sorry to be the one to burst your bubble again, but anything that doesn't use a return stack is broken
15:10:53 ##forth <pgimeno> you may have solved my example, which was a simple example designed to show how using a jump doesn't cut it, but for every other hack I can give you an example that breaks it. In this case, visiting every node in a tree would break it, and so would two mutually recursive functions.
15:11:07 ##forth <pgimeno> Come to think about it, can you do mutual recursion in Forth?
15:14:21 ##forth <pgimeno> Ah, apparently there's a word DEFER which is kind of a forward declaration.
15:45:26 ##forth <vms14> pgimeno don't worry, I appreciate your feedback
15:45:38 ##forth <vms14> and I'm not afraid of making mistakes, that's how I learn
15:45:45 ##forth <vms14> but yeah you are right
15:46:00 ##forth <vms14> is a very limited thing and cannot handle mutual recursion
15:47:25 ##forth <pgimeno> or two recursive calls in the same word
15:50:52 ##forth <vms14> xd yeah
15:52:49 ##forth <vms14> it seems that I cannot avoid having a global return stack for this
15:53:18 ##forth <vms14> saw some light but it was a little hole
15:53:58 ##forth <vms14> still I value that you help me realize
15:54:10 ##forth <vms14> so thanks again pgimeno :D
15:55:55 ##forth <pgimeno> no prob, I am now writing a binary tree visiting example so you have something to test it on
16:01:09 ##forth <veltas> Yeah it's only taken you years to accept this lol :P
16:01:24 ##forth <vms14> :D
16:01:34 ##forth <veltas> Better late than never
16:28:34 ##forth <pgimeno> (just updated to emphasize it's a binary tree)
16:29:03 ##forth <vms14> pgimeno ty for the code, I will try to see if I can make it run somehow
16:29:27 ##forth <vms14> although it would be different because this version of the interpreter is not trying to be forth like the other did
16:30:55 ##forth <vms14> I will play with it later and come here to cry when does not work
16:31:25 ##forth <pgimeno> ok ^.^
16:38:04 ##forth <vms14> pgimeno are you spanish?
16:38:52 ##forth <vms14> I'm from barcelona, asking cause the link has .es
16:40:00 ##forth <vms14> is that site your bussiness?
16:40:36 ##forth <pgimeno> oh yes I am, Pedro Gimeno
16:40:53 ##forth <pgimeno> it was at some point, now the business parts are obsolete
16:42:16 ##forth <vms14> I wanted to send a resume :/
16:42:51 ##forth <pgimeno> oh, sorry
20:27:49 ##forth <xentrac> vms14: being from Barcelona, would you say you were Spanish or not?
20:58:51 ##forth <vms14> yes
20:59:25 ##forth <vms14> catalonia independence was only a joke
20:59:37 ##forth <vms14> we are not going anywhere
21:56:57 ##forth <vms14> pgimeno I can't
21:57:07 ##forth <vms14> at least not like I'm trying
21:57:16 ##forth <vms14> I can evaluate only one branch
21:57:22 ##forth <vms14> but serves me well
21:57:38 ##forth <vms14> I will only optimize tail calls and learn the lesson
21:58:00 ##forth <vms14> and no mutual recursion
22:03:22 ##forth <pgimeno> are you sure about the memory leak, btw? Python is reference counted but it has a different kind of garbage collector for the cases of circular references
22:03:53 ##forth <pgimeno> the memory leak in Perl when you make a self-referencing closure, I mean
22:06:22 ##forth <thrig> in perl one is probably supposed to use weaken somewhere
22:10:01 ##forth <vms14> yeah if a closure retains a variable of itself perl cannot reclaim it
22:10:53 ##forth <vms14> as thrig mentions you can weaken a reference so it should work
22:10:53 ##forth <vms14> and you can also store it somewhere
22:11:41 ##forth <vms14> I guess I can manage to provide something refining what I was doing
22:12:19 ##forth <vms14> but I have no idea how to fix it and it won't provide much more than what perl already provides
22:12:56 ##forth <vms14> so I'll just add tco when I see is a tail call and let the perl return stack do it's job when not
22:13:59 ##forth <vms14> the cool thing is that I could use compression mechanisms to make the return stack more compact, with very bad performance since it will have to decode it
22:14:31 ##forth <vms14> but at the end it will have a limit so it's a lot of effort to get at the same place I was already
22:14:49 ##forth <vms14> tco is the only thing that makes sense to implement
22:15:08 ##forth <vms14> was cool to play with the concept though
22:15:21 ##forth <vms14> so I thank you again for that code
22:15:41 ##forth <xentrac> :-)
22:24:50 ##forth <vms14> I like the fact that you can make in the interpreter the dept limit a variable and let the user choose its own recursion depth limit