Brett Stahlman wrote: > On Saturday, December 31, 2016 at 12:23:10 PM UTC-6, ZyX wrote: > > 2016-12-30 20:09 GMT+03:00 Brett Stahlman <[email protected]>: > > > Consider the following recursive user function... > > > > > > fu! Fun(count) > > > if a:count > 0 > > > call Fun(a:count - 1) > > > endif > > > endfu > > > > > > :h 'maxfuncdepth' describes the option's purpose as follows: > > > > > > Maximum depth of function calls for user functions. This normally > > > catches endless recursion. When using a recursive function with > > > more depth, set 'maxfuncdepth' to a bigger number. > > > > > > So I would expect to be able to make the following recursive call with no > > > error: > > > :set maxfuncdepth=1000 > > > :call Fun(500) > > > > > > But I get the following error after slightly less than 200 recursive > > > calls: > > > E169: Command too recursive > > > > > > The documentation for E169 states the following: > > > > > > This happens when an Ex command executes an Ex command that executes an Ex > > > command, etc. This is only allowed 200 times. When it's more there > > > probably > > > is an endless loop. Probably a |:execute| or |:source| command is > > > involved. > > > > > > It's as though the :call (Ex command) is triggering the error long > > > before the number of calls to the user function Fun() has reached > > > 'maxfuncdepth'. But if this is the way it's supposed to work, what's > > > the point of 'maxfuncdepth'? Don't all calls to user functions involve > > > an Ex command (since both `call' and `let' are Ex commands)? Is there > > > a way to permit more than 200 recursive calls to Fun() without > > > triggering the error? > > > > I tried lambdas, but they also catch this error due to the way they > > are implemented. Unlike (until you consider their internal > > implementation) lambdas regular functions are lists of Ex commands, so > > this is not surprising. Note that by default &maxfuncdepth is 100 > > which is lesser then 200. > > Hmm... Perhaps Bram will weigh in on this, but effectively limiting > 'maxfuncdepth' to 200 feels like an unintended consequence, rather than > design intent - especially since the help on 'maxfuncdepth' makes no mention > of the limit. The documentation on E169 suggests that the purpose of the 200 > limit is to detect certain types of recursion involving :source and :execute > commands. If it was meant to apply to function calls generally, why even have > a separate option for function calls, especially if you can't increase its > value to something that would permit meaningful recursion? > > Since there's no option governing the E169 limit, perhaps it could be changed > to the maximum of 200 and 'maxfuncdepth'. Or perhaps it could take into > account the type of Ex command (i.e., source/execute vs call/let). Or perhaps > there could be a 'maxmemfunc' option (analogous to 'maxmempattern'), which > would limit function call recursion by stack space consumed (or some rough > approximation thereof) rather than # of calls. > > I noticed this because I'm running a tree processing algorithm that is > inherently recursive. I had intended to compute 'maxfuncdepth' as a function > of another option, but discovered that my choice was silently ignored for > anything over 200. Although the depth of the trees can exceed 200 in extreme > cases, the depth is bounded and known, so it made sense simply to boost > 'maxfuncdepth' long enough to recurse the tree. If there's no way around the > 200 maximum, I'll probably have to rewrite the algorithm to use breadth-first > traversals, rather than the much more natural (and simple) tree recursion.
I think that we can also used 'maxfuncdepth' for the Ex command recursion. They have similar functionality, even though the semantics are a bit different. It's not worth adding another option for this. So you can set 'maxfuncdepth' to 1000 and have a call depth of 1000, minus any other Ex commands that are involved, such as :execute. -- hundred-and-one symptoms of being an internet addict: 172. You join listservers just for the extra e-mail. /// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net \\\ /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org /// \\\ help me help AIDS victims -- http://ICCF-Holland.org /// -- -- You received this message from the "vim_use" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
