Re: [Chicken-users] Unbounded stack growth
At the risk of charging in like an entire stampede of cluelessness, Quoting Matthew Flatt mfl...@cs.utah.edu: At Thu, 12 Jul 2012 11:25:44 +0900, Alex Shinn wrote: I disagree - I think a stack grown too large is likely indicative of a programming error, or at the very least an inefficient algorithm. In the general case I want my programs to be able to allocate as much heap as possible, but have a separate limitation on the stack. Amen. Just because a computation is naturally expressed as a recursion does not mean that you should write it that way. Just because a computation can be expressed inefficiently, does not mean it should not be allowed to be expressed inefficiently. If things were otherwise, how many of your programs would've never compiled? I know a large number of mine never would've seen the light of day. To take a toy example, suppose you're summing numbers in from a binary tree. For this toy, suppose that a tree is either a number or a `cons' of two trees. Then, only a novice would write ; A tree-of-number is either ; - num ; - (cons tree-of-number tree-of-number) ; sum : tree-of-number - number (define (sum t) (cond [(number? t) t] [else (+ (sum (car t)) (sum (cdr t)))])) That `sum' will work fine on relatively balanced trees, but it will crash (as it should!) if the tree is too large and too list-like. Every real programmer knows that you should crate your own stack to sum the numbers. Why should it? Shouldn't it just run slowly, the sign of inefficient code? Since when is the sign of /inefficient/ code that it crashes? That's the sign of incorrect code, although incorrect code may certainly be inefficient. (I assume that we can all extrapolate from the toy to real programs. A compiler processes a tree of expressions, right? It may be given a too-deeply nested pile of function calls, and only an naive compiler writer would simply recur on sub-expressions to compile an expression. On second thought, maybe the compiler writer should just recur, and the right response for too-deeply nested code is a seg fault; that would serve the compiler user right for producing such a strange input.) I believe a naive compiler writer should be allowed to write a compiler, without being 'served right' by those who would take such a stance in this. The performance of his compiler will be his quite-sufficient punishment. And, finally: if this bug is fixed, but the option to disable the fix is introduced, badcheney is a fantastic (although not necessarily wise) option name ;) Cheers, -Cam ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Unbounded stack growth
Hallo, On Thu, Jul 12, 2012 at 4:25 AM, Alex Shinn alexsh...@gmail.com wrote: I disagree - I think a stack grown too large is likely indicative of a programming error, or at the very least an inefficient algorithm. In the general case I want my programs to be able to allocate as much heap as possible, but have a separate limitation on the stack. Programming errors or inefficient algorithms should crash C programs, not Scheme programs. -- -alex http://www.artisancoder.com/ ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Unbounded stack growth
On Thu, Jul 12, 2012 at 4:39 PM, Alex Queiroz asand...@gmail.com wrote: Hallo, On Thu, Jul 12, 2012 at 4:25 AM, Alex Shinn alexsh...@gmail.com wrote: I disagree - I think a stack grown too large is likely indicative of a programming error, or at the very least an inefficient algorithm. In the general case I want my programs to be able to allocate as much heap as possible, but have a separate limitation on the stack. Programming errors or inefficient algorithms should crash C programs, not Scheme programs. Wow, if you've got a magical Scheme compiler that can read my mind and fix all my bugs for me I'll switch right now! :) -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Unbounded stack growth
On Thu, Jul 12, 2012 at 9:47 AM, Alex Shinn alexsh...@gmail.com wrote: Wow, if you've got a magical Scheme compiler that can read my mind and fix all my bugs for me I'll switch right now! :) Are you really saying that it is ok for a Scheme program to crash with a segmentation fault because of programming errors, and not just because of compiler bugs? -- -alex http://www.artisancoder.com/ ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Unbounded stack growth
On Thu, Jul 12, 2012 at 4:51 PM, Alex Queiroz asand...@gmail.com wrote: On Thu, Jul 12, 2012 at 9:47 AM, Alex Shinn alexsh...@gmail.com wrote: Wow, if you've got a magical Scheme compiler that can read my mind and fix all my bugs for me I'll switch right now! :) Are you really saying that it is ok for a Scheme program to crash with a segmentation fault because of programming errors, and not just because of compiler bugs? No, and I never said nor implied that. I think the continuum here is, all else being equal: raise continuable exception abort with meaningful message segfault though often all else is not equal. For the specific case of handling programs which use unbounded stack, most implementations just blow up, and the question is how heap do they allocate in the process. Are they optimistic and think it can't be much longer now as they allocate that last 100MB, or do they bail out a little earlier? Whether you set a fixed limit or just let it use up all available memory, there is still a limit. Setting a separate limit does leave you with some heap space to try to recover with, though, and is friendlier to other processes. But now we're just negotiating the price. -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
