ssanbeg at ask
Jul 6, 2009, 9:46 AM
Post #112 of 116
(954 views)
Permalink
|
|
Re: On templates and programming languages
[In reply to]
|
|
On Fri, 03 Jul 2009 17:13:45 +1000, Tim Starling wrote:
> Steve Sanbeg wrote:
>> I'd assume we want locked down. Loops would be hard in any locked-down
>> environment; I don't recall seeing any recommendation in this thread on
>> how that wold be done. Recursion is much simpler, just track the depth,
>> and throw an exception if it goes to deep; emacs lisp already uses this
>> mechanism.
>
> Loops are essential for readable code. There is no problem with
> allowing loops in conjunction with time limits, that we don't have
> already with complex templates. In fact, time limits for complex
> templates would be an improvement over the system of expansion limits
> we have at the moment.
>
In some cases they would be helpful; i.e. to loop over all of the template
arguments instead of those horrible #switch things they use now. But
letting people run out the clock with arbitrarily complex loops seems
messy.
On the one hand, anyone can easily write code to take up the
maximum alloted time, and stuff as many into a page as they could, to
either prevent the page from rendering at all, or cause the system to stop
executing code before it gets to the parts that are supposed to be there.
On the other hand, it could make templates fail unpredictably; with a
seemingly small change having just enough affect on execution time for the
template to fail, at least some of the time.
> Recursion can give a long running time even if the depth is limited.
> By calling the function multiple times from its own body, you can have
> exponential time order in the recursion depth.
>
All those calls still end up on the same stack; even if it could be a tree
in theory, the stack only grows one way, and execution time would only be
linear.
I found some documentation on the example I'd thought of emulating, which
may clarify a little:
http://www.delorie.com/gnu/docs/elisp-manual-21/elisp_123.html
This variable defines the maximum depth allowed in calls to eval, apply,
and funcall before an error is signaled (with error message "Lisp nesting
exceeds max-lisp-eval-depth"). This limit, with the associated error when
it is exceeded, is one way that Lisp avoids infinite recursion on an
ill-defined function.
The depth limit counts internal uses of eval, apply, and funcall, such as
for calling the functions mentioned in Lisp expressions, and recursive
evaluation of function call arguments and function body forms, as well as
explicit calls in Lisp code.
_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
|
