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