[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-users] Unbounded stack growth

From: cjtenny
Subject: Re: [Chicken-users] Unbounded stack growth
Date: Thu, 12 Jul 2012 02:30:55 -0400
User-agent: Internet Messaging Program (IMP) H3 (4.2)

At the risk of charging in like an entire stampede of cluelessness,

Quoting "Matthew Flatt" <address@hidden>:

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)
     [(number? t) t]
      (+ (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

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 ;)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]