I have been experimenting with the Spock Scheme to JavaScript compiler. I
encountered a bug in its implementation of the Cheney on the MTA approach to
tail-calls and continuations. The bug also exists for Chicken.
In the Cheney on the MTA approach there needs to be a check, at regular
interva
Marc Feeley scripsit:
> In this example, there will be an arbitrarily long sequence of C calls
> (in the unwinding of the recursion to even) with no Scheme call, so
> stack size checks will not be performed during the unwinding, yet the
> C stack grows during the unwinding. There is no stack over
It seems that compiling with clang (llvm 3.0)
prevents the crash, at least for values up to 20 million, on
OS X and Linux. Any higher and I start to hit swap.
I don't know why this works.
Plain gcc on linux, and llvm-gcc (llvm 2.7) on OS X 10.7, do crash
at about 600k here w/ stack ulimit 8M. Ba
On 2012-07-11, at 2:31 PM, John Cowan wrote:
> Marc Feeley scripsit:
>
>> In this example, there will be an arbitrarily long sequence of C calls
>> (in the unwinding of the recursion to even) with no Scheme call, so
>> stack size checks will not be performed during the unwinding, yet the
>> C st
On 2012-07-11, at 3:44 PM, Jim Ursetto wrote:
> It seems that compiling with clang (llvm 3.0)
> prevents the crash, at least for values up to 20 million, on
> OS X and Linux. Any higher and I start to hit swap.
> I don't know why this works.
>
> Plain gcc on linux, and llvm-gcc (llvm 2.7) on OS
On 2012-07-11, at 2:31 PM, John Cowan wrote:
> Marc Feeley scripsit:
>
>> In this example, there will be an arbitrarily long sequence of C calls
>> (in the unwinding of the recursion to even) with no Scheme call, so
>> stack size checks will not be performed during the unwinding, yet the
>> C st
On Jul 11, 2012, at 2:47 PM, Marc Feeley wrote:
>
> I'm pretty sure LLVM is simply implementing the tail-call itself. So there
> is no stack growth in the unwinding phase.
That is possible. We do currently disable __attribute__((noreturn))
on functions across the board when using clang, and la
The issue could be splitted to two:
1. Whether the implementation checks stack usage more often
2. Whether the implementation terminates with more descriptive
message than SEGV
I think John argues on the first ground, however Marc's argument
can cover both.
These days PCs have lots of heap, a
From: Marc Feeley
Subject: [Chicken-users] Unbounded stack growth
Date: Wed, 11 Jul 2012 13:23:30 -0400
> I have been experimenting with the Spock Scheme to JavaScript compiler. I
> encountered a bug in its implementation of the Cheney on the MTA approach to
> tail-calls and continuations. Th
>
> Performance should not trump safety and correctness.
Absolutely right, yet everybody has a different perception of what
performance, safety and correctness means. Segfaulting on
_stack-overflow_ is not something that I'd call "incorrect" or "unsafe"
- I'd call it "inconvenient" and it may be
On 2012-07-11, at 5:59 PM, Felix wrote:
>>
>> Performance should not trump safety and correctness.
>
> Absolutely right, yet everybody has a different perception of what
> performance, safety and correctness means. Segfaulting on
> _stack-overflow_ is not something that I'd call "incorrect" or
On Thu, Jul 12, 2012 at 10:52 AM, Marc Feeley wrote:
>
> On 2012-07-11, at 5:59 PM, Felix wrote:
>
>>>
>>> Performance should not trump safety and correctness.
>>
>> Absolutely right, yet everybody has a different perception of what
>> performance, safety and correctness means. Segfaulting on
>> _
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
Matthew Flatt scripsit:
> Amen. Just because a computation is naturally expressed as a recursion
> does not mean that you should write it that way.
Well. Just because you can implement division by tree-walking doesn't
mean you should write *it* that way.
But thanks for a much-needed injection.
On Thu, Jul 12, 2012 at 11:55 AM, Matthew Flatt wrote:
> 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 t
At the risk of charging in like an entire stampede of cluelessness,
Quoting "Matthew Flatt" :
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 g
16 matches
Mail list logo
