[EMAIL PROTECTED] wrote:
>
> Let's see how it performs on a structure that is naturally recursive:
>
... nice code and stack crash deleted ...
>
> But:
>
... more deletions ...
>
> 140 levels can hold maximum 2^139 + 2^138 + ... + 2^0 elements...
>
> I think running out of memory is a bigger problem than running out of
> stack space ! :))
>
EXCEPT that sometimes a recursive structure is composed from input
data not under the control of the programmer! For example, building
a sort tree from pathologically ordered data can produce a 140-level
tree that contains only 141 leaves.
Of course the program can be re-written to continually rebalance the
tree, but means that the programmer is having to make a more complex
program to work around a limitation of the implementation -- NOT a
very friendly solution for the casual (or novice) programmer.
CONCRETE SUGGESTIONS: Why not allow the programmer or user some more
control over stack size? I suggest that REBOL would benefit from:
1) A command-line argument allowing the stack size to be set to a
supplied value. On a larger box, one could simply make the size
bigger to allow deeper recursion. (As a side note, I recently
found that I could nest recursive calls deeper under w95 than
under Solaris, even though the Sun box had WAYYYYY more RAM.
("What a rebolting development THAT is!")
2) A primitive function allowing running code to query the amount
of total and free stack space. This would enable a script to
predict an impending stack crash and take preventive action,
rather than simply detecting the crash after the fact.
It would also be nice to have the same capabilitiy(ies) for
heap/string space, but I'm assuming more than I know about the
implementation of REBOL. ;-)
3) In the best of all possible worlds, REBOL would have both of
the above, PLUS a function to grow the stack/heap/whatever by
a specified amount of memory. Of course that function would
fail gracefully if the environment didn't have sufficient
resources to let the interpreter grow.
How about it, REBOL wizards? I realize that these may be non-trivial
changes (depending on how the interpreter is built) but I believe they
offer some real value, both to those of us who occasionally write
quick-and-dirty code and to those who deal with really complex or
large data structures.
-jn-
