On Tue, Oct 29, 2013 at 04:21:35PM +0100, Igor Bukanov wrote: > This is a weak argument. If one needs that much memory, then using an > explicit stack is a must as it allows for significantly more compact > memory presentation.
I considered this when I wrote the e-mail. I partially agree but not fully. Let me expound some. In general, both segmented stacks and an explicit stack on the heap have the property that if you add more RAM, you can get more work done. I agree that using a stack on the heap offers a better constant factor (that is, a better work-to-RAM ratio), but that may not be the relevant point for all use cases. This debate is not new: we've been considering whether or not to keep segmented stacks for a while. Originally I thought as you do, that one should just not write recursion whose depth is proportional to the input, for fear of overflow. In past compilers I've worked on we tried to obey this rule, since people always managed to surprise us with the complexity of inputs they would provide. But I've been watching the code I write now and I've found that many times a recursion-based solution is much cleaner. Moreover, since we integrate recursion specially with the type system in the form of lifetimes, it can also express things that are more awkward with a heap vector. All that said, probably the most important thing is that we have graceful failure on stack overflow (even an abort is perhaps adequate, though obviously a proper failure is better). This permits users to start with recursion-based code and either convert to heap-based code or allocate bigger stack frames when they start to hit limits. Obviously no one is proposing segfaulting on stack overflow, so I guess I will be satisfied. :) Niko _______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
