On Thu, Jun 25, 2009 at 8:33 PM, Tim Starling<tstarling(a)wikimedia.org> wrote: Could you offer a bit more beyond "I don't like it"? A few devs, and you in particular, have expressed dismay over what string functions would do to wiki template code. However, most devs are rarely if ever involved with writing wiki templates. By contrast, the community of people who do work on such templates have been asking for these functions for literally years and don't seem the least bit afraid that the marginal impact of adding a few more parser functions will bring the house down. It is hard for me to figure why this case is so peculiar that the devs should block the wishes of the community. Nor do I see why the existence of basic string functionality should be dependent on someone overhauling or replacing the template coding scheme. -Robert Rohde

On Thu, Jun 25, 2009 at 9:07 PM, Brian<Brian.Mingus(a)colorado.edu> wrote: Yes, template code can suck, and that's a fine example. But how is adding or not adding string functions going to make a significant difference to that? How is it different that {{#expr:}} or different from creating {{#if:}} to replace {{qif}}, etc.? I don't see why the fact that template code is a mess should bear on the orthogonal question of providing string functionality to the community. I'm sure that if someone ever does create a better template coding system then many people will quickly migrate to it, but why should that need to come first? -Robert Rohde

* Gregory Maxwell <gmaxwell(a)gmail.com> [Fri, 26 Jun 2009 01:03:01 -0400]: It's already a programming language, though a bit limited one and not very well readable. A good built-in language would expand the usage of MediaWiki beyond Wikipedia (for example with SMW/SF extensions), though it's probably has no use to Wikimedia Foundation. Dmitriy

On Thu, Jun 25, 2009 at 10:35 PM, Tim Starling&lt;tstarling(a)wikimedia.org&gt; wrote: <snip> There is some truth to this. However, I believe the community of people who would like to see string functions is much, much larger, than just the community of template coders. Most Wikipedians can use templates even if they don't feel comfortable creating them, and many of them have at one time or another encountered practical problems that could be solved with basic string functionality. <snip> Do you actually have a plan for introducing a scripting language? Lua, which seems to your favored strategy, was recently LATER-ed on bugzilla by Brion, and suffers from several serious problems. For example the dependency on compiled binaries is highly undesirable. The relative power of a full programming language would require limiting its resources to avoid bad code consuming all memory or flooding Mediawiki with output, and that is only the starting point for considering the risks of malicious or overtaxing code. Not to mention that the comments at Extension talk:Lua suggest several people have failed in attempts to get the Extension working at all. Even if one gets past that, Lua brings its own grammar, set of function keywords, and methodologies, which will again create a high barrier to participation for people wanting to work with it. Frankly Lua feels like it creates at least as many usability and portability problems as it solves, and is still a long ways off. Werdna's suggestion to adapt the AbuseFilter parser into a home-grown Mediawiki scripting language feels lot more natural in terms of control and ability to affect an integrated presentation, but that would also seem quite distant. If one is going to say "no string functions until the template coding problem is solved", then I'd liked to know if there is really a serious strategy for doing that. -Robert Rohde

2009/6/26 Stephen Bain &lt;stephen.bain(a)gmail.com&gt;om>: Maybe it's the mindset that should be changed then? For one thing, {{link}} used to use {{substr}} to check if the first argument started with http:// , https:// or ftp:// and produced an internal link if not, despite the fact that the documentation for {{link}} clearly states that it creates an *external* link, which means people shouldn't be using it to create internal links. If people try to use a template for something it's not intended for, they should be told to use a different template; currently, it seems like the template is just extended with new functionality, leading unnecessary {{#if: , {{#switch: and {{substr}} uses that serve only the users' laziness. To get back to {{cite}}: the template itself contains no more than some logic to choose between {{Citation/core}} and {{Citation/patent}} based on the presence/absence of certain parameters, and {{Citation/core}} does the same thing to choose between books and periodicals. What's wrong with breaking up this template in, say, {{cite patent}}, {{cite book}} and {{cite periodical}}? Similarly, other multifunctional templates could be broken up as well. The reason I believe breaking up templates improves performance is this: they're typically of the form {{#if:{{{someparam|}}}|{{foo}}|{{bar}}}} . The preprocessor will see that this is a parser function call with three arguments, and expand all three of them before it runs the #if hook. This means both {{foo}} and {{bar}} get expanded, one of which in vain. Of course this is even worse for complex systems of nested #if/#ifeq statements and/or #switch statements, in which every possible 'code' path is evaluated before a decision is made. In practice, this means that for every call to {{cite}}, which seems to have three major modes, the preprocessor will spend about 2/3 of its time expanding stuff it's gonna throw away anyway. To fix this, control flow parser functions such as #if could be put in a special class of parser functions that take their arguments unexpanded. They could then call the parser to expand their first argument and return a value based on that. Whether these functions are expected to return expanded or unexpanded wikitext doesn't really matter from a performance standpoint. (Disclaimer: I'm hardly a parser expert, Tim is; he should of course be the judge of the feasibility of this proposal.) As an aside, lazy evaluation of #if statements would also improve performance for stuff like: {{#if:{{{param1|}}}|Do something with param1 {{#if:{{{param2|}}}|Do something with param2 ... {{#if:{{{param9|}}}|Do something with param9}}}}}}}}}}}}}}}}}} Roan Kattouw (Catrope)

On Thu, Jun 25, 2009 at 11:33 PM, Tim Starling&lt;tstarling(a)wikimedia.org&gt; wrote: Well, then at least let's be consistent and cripple padleft/padright. Also, while I disagree with Robert's skepticism about the comparative usability of a real scripting language, I'd be interested to hear what your ideas are for actually implementing that. Come to think of it, the easiest scripting language to implement would be . . . PHP! Just run it through the built-in PHP parser, carefully sanitize the tokens so that it's safe (possibly banning things like function definitions), and eval()! We could even dump the scripts into lots of little files and use includes, so APC can cache them. That would probably be the easiest thing to do, if we need to keep pure PHP support for the sake of third parties. It's kind of horrible, of course . . . How much of Wikipedia is your random shared-hosted site going to be able to mirror anyway, though? Couldn't we at least require working exec() to get infoboxes to work? People on shared hosting could use Special:ExpandTemplates to get a copy of the article with no dependencies, too (albeit with rather messy source code). On Fri, Jun 26, 2009 at 6:33 AM, Roan Kattouw&lt;roan.kattouw(a)gmail.com&gt; wrote: I thought this was fixed ages ago with the new preprocessor.

where did I say no, and what was my 'no' about? -- domas

2009/6/26 Robert Rohde &lt;rarohde(a)gmail.com&gt;om>: You're right that dead code never reaches the parser (your "processor"), but ideally the preprocessor wouldn't bother expanding it either. I have vague recollection that it was fixed with the new preprocessor, as Simetrical said, but I have no idea how much truth there is in that. Roan Kattouw (Catrope)

On Fri, Jun 26, 2009 at 2:44 AM, Stephen Bain &lt;stephen.bain(a)gmail.com&gt;wrote;wrote: The good old days are long gone. If you believe there is never a valid case for basic programming constructs such as conditionals you should have objected when ParserFunctions were first implemented.

Brian wrote: I have seen this before. People use #if for everything even when there is a better way. Look at what you're doing: {{#if:{{{4}}}|{{{4}}}|{{#if:{{{5}}}|{{{5}}}}}}} {{#if:{{{5}}}|{{{5}}} }}}} mean "show parameter 5 if it is set", or "show parameter 5 if it is not blank". In either case, {{{5|}}} would do the job. The parent #if is simlar parameter 4 if set, else parameter 5. {{{4| {{{5|}}} }}} would do the job. Template default parameters were here much before ParserFunctions. But people prefer using ugly #ifs, making syntax more unreadable (and increasing preprocessor limits). Another common abuse is to do: {{#if: {{{Foo}}}| <tr><td>Foo: </td><td>{{{Foo}}} </td></tr> }} I'd like to have a feature in the parser to mark a section to be skipped if the inner parameter is not set, without having to use #ifs everywhere.

Brian wrote: Then you shouldn't be presenting examples of how it can't be implemented reasonably in template programming. Almost any _reasonable programming language_ allows you to write ugly code if so you want. That doesn't prove the language is ugly. Nonetheless... it's ugly :)