Saagar Jha
6 replies
Saagar Jha
(replying to Daniel Kochmański)
Daniel Kochmański
(replying to Saagar Jha)
@saagar that's why we should go only forward with the stack, then the beginning can be garbage collected (and no, I don't like scheme _that_ much)
Michel Schinz
(replying to Saagar Jha)
@saagar Hotter take: there should be no stack, activation frames should be allocated from the heap like everything else.
Phairupegiont
(replying to Saagar Jha)
@saagar Hotter counter-take: recursion is control flow obfuscation, it gives up the benefits of structured programming.
Ocaml was right to require explicit marking of recursive functions, so that we can know most of the code is free of this danger
Saagar Jha
(replying to Saagar Jha)
3 replies
Félix
(replying to Saagar Jha)
@saagar enjoy accidental infinite recursion eating all of your RAM
2 replies
Saagar Jha
(replying to Félix)
Félix
(replying to Saagar Jha)
@saagar also enjoy the debugger taking 15 minutes to give you a backtrace when you stop your process by hand
2 replies
Saagar Jha
(replying to Félix)
Andy Wingo
(replying to Saagar Jha)
@saagar @fay59 there are solutions to all of these problems https://wingolog.org/archives/2014/03/17/stack-overflow
Jason Molenda
(replying to Félix)
@fay59 @saagar fake news, lldb has an optimized stack walker specifically to handle inf recursion crashes well; I think the most stack frames you can get with std main thread stack size is ~500k frames; lldb can walk that in 5.5 seconds on my m4 max desktop. I mean unlimited stack means really infinite recursion crash ofc, 500k is just the start of what you could do in that env.
Jason Molenda
(replying to Jason Molenda)
@fay59 @saagar (if you have lldb formatting argument variables for each stack frame, that’s gonna take longer of course - lots of memory reads and type formatters. but just looking at “lldb has enumerated all stack frames, and knows the pc values with symbol name and debug info for each”, 5-6 seconds max.)
Félix
(replying to Jason Molenda)
@jasonmolenda @saagar I don’t stack overflow all that much but I recall at least Xcode not being very good at it. maybe I’m unjustly blaming lldb for it
Jason Molenda
(replying to Félix)
@fay59 @saagar to be fair, in the early days I’d written lldb’s register tracking up & down the stack with a recursive algorithm and you can guess what happened next.
Marin Todorov
(replying to Saagar Jha)
@saagar but what about all these people who have this question on their coding interview list, imagine the amt of manhours to replace it with new one... think about the economy and productivity 😱
Jesse Wilson
(replying to Saagar Jha)
@saagar or abuse your favorite language’s async feature
Kotlin:
suspend fun sum(a: UInt, b: UInt): UInt {
enableDeepRecursion()
if (a == 0) return b
return sum(a - 1, b + 1)
}
suspend fun enableDeepRecursion() {
yield() // ✨
}