Will Coleda via RT wrote: >It's dealing with a specific behavior needed of the VM by rakudo which >isn't appropriate to push into nqp ... >At which point the limit on each backend will no doubt need to be >different,
Interesting: your view here implies a rather different intent to the recursion_limit code than any of the options I considered. I'd supposed that the intent was to provide a settable recursion limit where possible, looking essentially similar to HLL code across VMs, with only the implementation differing. But if essentially different behaviour is wanted per VM, that sounds more like you're intending to cope with different kinds of limit imposed by each VM, hiding it entirely from HLL code. If the intent is to cope with, and hide, the fact that Parrot imposes a (low) recursion limit by default, the value you should set the limit to is -1. That is, -1 as it appears in the interpreter recursion_limit method that takes a Parrot int (signed word) for its parameter. Internally the recursion limit is interpreted as an *un*signed word, so the -1 becomes the highest possible value. In fact, since the comparison (in src/pmc/sub.pmc) is of the form depth>limit, with the limit at all-bits-one the exception can never be triggered even if the depth count somehow becomes decoupled from actual stack frame records and grows enough to wrap around. -zefram
