Topic on Extension talk:Scribunto

I think there might possibly be a design problem in the frame object. The problem is that currently a Lua module can launch an infinity of templates, an infinity of parsers functions, but only 100 other modules. I explain the situation at :en:Wikipedia talk:Lua § Editing the args metatable of a child frame:

Module:Params offers the possibility to map or rename parameters using either helper templates or modules or parser functions. Currently, in the case of mapping_by_invoking and renaming_by_invoking, while iterating, a new child frame gets created for each parameter (#1, #2). This means that if the parameters to map or rename are more than about a hundred the code breaks, because, as the Scribunto-Lua manual says, “The number of frames that may be created at any one time is limited”.

I have tried to solve the problem in Module:Params/sandbox, but all my attempts at keeping only one child frame throughout the loop failed (#3, #4, #5, #6). The reason is that once the child frame object gets created I can no longer edit its .args metatable. Yet, I would need to do that, because each module invocation needs to receive different parameters.

Testcases are available at Module:Params/testcases/tmaps and Params/testcases/tmaps sandbox. Any idea on how to solve the problem and being able to map more than 100 parameters using a module?

Is any workaround possible?

To better understand the paradox, if I try to create 120 dummy parameters and map them using the {{replace}} template (which uses {{#invoke:string|replace}}), everything works well:

{{#invoke:params|imposing|120|foobar|filling_the_gaps|mapping_by_calling|replace|blindly|let|plain|false|3|foo|^.*$|test|for_each|[$#: $@]}}

But if I try to map these parameters using {{#invoke:string|replace}} directly, without calling the {{replace}} template (i.e. if I use mapping_by_invoking instead of mapping_by_calling),

{{#invoke:params|imposing|120|foobar|filling_the_gaps|mapping_by_invoking|string|replace|blindly|5|foo|^.*$|test||false|for_each|[$#: $@]}}

I get

Lua error: newChild: too many frames.

Isn't this a bit absurd?

@Grufo:

currently a Lua module can launch an infinity of templates, an infinity of parsers functions

If you ask me, that's the absurdity. For performance reasons, those should be limited as well. (And... aren't they, at least at Wikipedia? I'm pretty sure there's some configurable limit, and I thought it was set a lot lower than 100.)

@FeRDNYC

It is definitely absurd that the three things (i.e. template call, module call and parser function call) are treated differently. If you ask me if there should be a limit at all, I don't know. But if there were a limit, I would say that 100 would be too low; in the case of Module:Params, although rare, it is not unthinkable to have a template called with 120 parameters, and with a limit of 100 the module would not be able to map all the incoming parameters. Moreover, even with 35 parameters, a template might need to map each parameter more than once, and already three mappings would break the limit of 100. So, if you ask me, a limit should not be lower than 1000, if any.

Module:Params can also increase the number of parameters a template was called with, and if done automatically (see filling_the_gaps), there is a safety limit of 1024 parameters that can be automatically created in this way – so you will not be able to use this module to call other templates/modules millions of times in any case.