Topic on Extension talk:ParserFunctions

Suggestion: new functions #ifnot, #ifand

18
Od1n (talkcontribs)

Do you think a new function #ifnot would be accepted?

Very simple to implement and unambiguous, it would simply be the contrary of #if, and let avoid the extra, easy-to-overlook pipe we encounter quite often:

{{#ifnot: <expr> | <dosomething> }}

instead of:
{{#if: <expr> | | <dosomething> }}
or even:
{{#ifeq: <expr> | | <dosomething> }}
Od1n (talkcontribs)

Another function that would be much useful, and integrates smoothly with the existing ones: #ifand.

{{#ifand: <expr1> | <expr2> | yep | nope }}

instead of:
{{#ifexpr: {{#if:<expr1>|1|0}} and {{#if:<expr2>|1|0}} | yep | nope }}
or even:
{{#if: <expr1> | {{#if: <expr2> | yep | nope }} | nopebis }}

Easy to apprehend, as it's a bit similar to #ifeq.

No need for #ifor, as {{#if: <expr1> <expr2> | yep | nope }} already does the job.

121.219.80.119 (talkcontribs)

Let's not further encourage abusing wikitext for programming.

Pi zero (talkcontribs)

It's undesirable to pile on more and more complicated magic words. However, wiki text is ultimately the single most desirable programming medium for wikis, as it embraces the wiki philosophy by putting control directly into the hands of the general community of wiki users. The problem daunting, but not impossible is to fashion wiki markup into a language suitable for that sort of radically user-driven programming.

121.219.247.173 (talkcontribs)

We don't need to try to pretend wikitext is capable of sane programming (it isn't), when we already have actual programming languages available.

Pi zero (talkcontribs)

Wikitext is currently poor for sophisticated purposes. There are ways and ways to fix that. Scribunto is (though imho a nice programming language, as traditional ALGOL-style programming languages go) a good example of the poor fit between ALGOL-style programming and wikis, and sadly an example of the socially destructive trend toward isolating control away from the lay wiki community, on the far side of a linguistic and conceptual discontinuity where it becomes the province of a high priesthood. It looks great if you compare it only to the status quo ante, but looked at in the larger realm of possibilities it's leading in the wrong direction.

Od1n (talkcontribs)
  • Scribunto is powerful, but often you don't want to implement a whole Lua module just because you need it at one location.
  • What happens when a simple, useful, ParserFunction is not implemented because "let's not encourage/pretend blah blah" ? People nevertheless implement it, in a very much shitty way.

Let's face it: there is Scribunto, because there was a need for it. So wiki users have many, many possibilities in their hands. It officially buried the "you should not program" legacy for good. But Scribunto is heavy artillery. Restraining ParserFunctions just for the sake of restraining it, is a way of thinking that has become obsolete for something like ten years.

Pi zero (talkcontribs)

A technique I'm trying out with, so far, good results is to support complex, powerful parsing operations through an embedded custom lisp implemented, of course, in Scribunto, which is how I use Scribunto and, where necessary, JavaScript: as a means to empower wiki markup. {{evalx}}.

Od1n (talkcontribs)

I'm just interested in filling the obvious gaps related to the #if functions so whe have much cleaner templates. Very simple, future-proof, and damn useful. My point is not disserting on Algol or integrating a custom Lisp...

Pi zero (talkcontribs)

Point taken. But, to be fair, #ifnot and #ifand can be written straightforwardly using ordinary #if. The existing syntax of magic words and template calls in wiki markup is limited in how readable it can be, by the comparatively heavy syntactic overhead of the notation delimiting double-braces {{}} and separating pipes |. It's not entirely obvious that the cost to readability of adding more magic words is made up for by the gain in readability &mdash if there is one of writing {{#ifnot:{{cond}}|...}} instead of {{#if:{{cond}}||...}}, and {{#ifand:{{cond1}}|{{cond2}}|...}} instead of {{#if:{{cond1}}{{cond2}}|...}}; the differences get buried in the heavy syntactic overhead.

Now, if you want to take about helpful improvements to magic words, there was a proposal, way back I think, to add a magic word that provides the name of the page on which the magic word occurs regardless of what pages it's transcluded on. That would be immensely useful in writing templates that (1) are easier to read because the markup explains itself instead of hardcoding a page name that you then have to decipher to figure out what's going on, and (2) don't break if you move them, along with all their subpages, because they can name their subpages relative to themselves. The bug request was, I believe, classified as a WON'T FIX based on some rather unconvincing excuse about parser state.

Od1n (talkcontribs)

Your example above is wrong. {{#ifand:{{cond1}}|{{cond2}}|...}} is NOT the same as {{#if:{{cond1}}{{cond2}}|...}}. Please double check my presentation of #ifand above. That's precisely the kind of errors I've encountered countless times ;-)

Same goes for {{#if:<expr>||...}}. First contributor makes it right, following contributor goes too fast and deletes the extra pipe because he thinks of a mistake.

About your second paragraph, though an interesting point, it is off-topic again...

Pi zero (talkcontribs)

Yup, sure enough, I got #ifand wrong, which I can only agree is a fair practical demonstration of the utility of #ifand. I also concede it's easy to forget the double-pipe for #ifnot; I've sometimes made that mistake myself, and have learned to recheck pathologically against it. So, okay, I'm convinced. You're right, adding these magic words would indeed lead to a practical reduction in markup errors and, despite the IP's comment above, it's kind of absurd to claim they'd encourage doing stuff with wiki markup instead of Scribunto because they're the sorts of things one would routinely do in really, really simple logic that nobody in their right mind would resort to Scribunto for. For what my agreement is worth.

Od1n (talkcontribs)

Glad I have convinced you :-) It would be great to get supplementary approvals, as the hardest part of this proposal is in fact to have it accepted, by demonstrating its benefits and proving a clear consensus.

Technical 13 (talkcontribs)
  • NOT {{#ifeq:{{{arg|}}}||| ...do since not true... }} works just fine, and there is no reason add an ifnot.
  • NOT {{#ifeq:{{{arg1|}}}|{{#if:{{{arg2|}}}| ...do since both true... }}}} or {{#if:{{AND|{{{arg1|}}}|{{{arg2|}}}}}| ...do since ALL true... }}}} where {{AND}} is a template that will allow multiple inputs and return true if all inputs are true or false if one is false.
  • As you said, OR is easy, but what about XOR? Since it is a much more complicated example, that could be done with a template as well {{XOR}}. Both of the AND and XOR templates if created are generic enough that they might benefit from being coded in Lua (Scribunto) which would easily allow infinite parameters to be passed. The current request here for a ifnot is too easily done with what is existing, and the request for an ifand is too limited in scope only allowing two arguments to be tested and would be much better resolved with a module allowing infinite and then the parser only has to test for one true or false based on the return of the module. Similar for my suggested XOR module, it wouldn't work well as a parser function but would be a great Scribunto default module (they would even make great intro to Lua tutorial modules).
Od1n (talkcontribs)

Your examples are complicated as hell. Ah, and the first is wrong.

But I had considered the {{and}} idea for a moment. Even if the most common use case is with no more than 2 conditions. Though, the name is already taken on numerous wikis, the English wiki for instance. Also, such a template would be much longer and complicated than the short, straightforward PHP implementation.

Then, I think {{xor}} would be less useful. Why not, but let's focus of the main topic for now.


Long story short, trying to do it using templates quickly gets complicated whereas in PHP it is incredibly short and straightforward. And it integrates smoothly for the users.

Od1n (talkcontribs)

Also an ambiguity: should {{and|0|0}} be true or false?

As it complements #if, #ifand alleviates this ambiguity: {{#ifand:0|0}} is true, as {{#if:0}} is true.

Pi zero (talkcontribs)

@Technical 13: You're trying to apply a traditional concept in programming language design, but one that doesn't apply well to this situation. It's traditional to try to minimize the number of keywords. However, number of keywords trades off against the overhead cost of structural syntax. In a language with low overhead for structured expressions, it often makes sense to use a really minimal set of keywords, and build slightly more complex strutures to compensate. But the overhead for structured expressions is high in wiki markup, with relatively heavy delimiters and separators, and high likelihood of error when fancy structure calls for consecutive separators. The more effective strategy for wiki markup is to build uniform structure into the set of keywords itself, as there's much lower overhead in providing uniform variation in keywords than in trying to build big cumbersome structured expressions to make up for a minimal keyword set.

Nnemo (talkcontribs)

I support the proposal by Od1n at 200 %. Especially for ifand. In fact, I would even prefer having and. Having to nest several if to do and is horrible !

Reply to "Suggestion: new functions #ifnot, #ifand"