From MediaWiki.org
Jump to navigation Jump to search
MediaWiki 拡張機能マニュアル
OOjs UI icon advanced.svg
リリースの状態: 安定
実装 タグ , パーサー関数 , データベース
説明 implements a programming language which is basically PostScript without graphics
作者 RV1971talk
最新バージョン 0.9 (2010-01-05)
MediaWiki 1.13.3 以降
ライセンス GPL
ダウンロード SourceForge

ExtStackFunctions::$mAuthKey, ExtStackFunctions::$mCompress, ExtStackFunctions::$mCompressArg, ExtStackFunctions::$mDecompress, ExtStackFunctions::$mEnableQuery, ExtStackFunctions::$mPrologNamespace,

translatewiki.net で翻訳を利用できる場合は、StackFunctions 拡張機能の翻訳にご協力ください
使用状況とバージョン マトリクスを確認してください。


The StackFunctions extension implements a programming language which is basically PostScript without graphics.


This extension can be considered as an alternative to the combination of Winter or ParserFunctions with StringFunctions and some other extensions that exist or could be written. Advantages are:

  • When using conditional expressions with ParserFunctions, wikitext in the false-branch is parsed before evaluating the condition. If that text contains complex templates, such superfluous parsing may take much time. With StackFunctions, wikitext is parsed only if needed for the output.
  • To execute loops, you would need either inefficient auxiliary templates with a limited number of runs or LoopFunctions which also have limits. StackFunctions is able to execute loops with any number of iterations and any depth of nesting in a relatively efficient way.
  • If you have text which on the one hand you'd like to display between <pre>..</pre> and on the other hand to use as an argument to ParserFunctions, you need to build more or less complex structures using #tag. StackFunctions can handle this in a much easier way.
  • StackFunctions offer a Turing-complete programming language which can be used to implement any algorithm (with more or less effort in a more or less efficient fashion) without need for additional extensions.
  • StackFunctions easily handle complex data structures like arrays and dictionaries, which may also be nested to any level.
  • My personal experience is that StackFunctions generally tend to execute faster than a combination of other existing extensions, especially when the latter solution would need a large number of auxiliary templates which are evaluated many times.



Preliminary Remark: programming with a stack processor like this is a matter of taste. You might alternatively find it extremely cool or totally unusable. You have been warned.


As a parser extension, the syntax is:

<sf par1=val1 par2=val2 ... >

This syntax is usually the preferrable one because:

  • You don't have to bother with the problems listed below for the parser function syntax.
  • From theory it is likely that this executes faster than the parser function syntax because the code is not parsed before passing it to StackFunctions. (However, I didn't yet write so much code that I can confirm this from observation.)

If you want to evaluate magic words, templates or parser functions, you can do this within the code via the statusdict and parsetemplate/showtemplate operators.

The only things that cannot be done with this syntax are:

  • Usage of template parameters {{{1}}}, {{{2}}}, ... in StackFunctions code in a template.
  • Using the output of StackFunctions code as a template parameter or parser function parameter.
  • Print section headings. They will be printed, but won't be counted correctly for the TOC.


As a parser function extension, the syntax is:

{{#sf: your_stackfunctions_code|par1|par2|...}}

When using this syntax, you must pay attention to some issues. The basic rule is that any {{..}} structures are parsed by the MediaWiki parser before any StackFunctions code is executed. There is a number of consequences:

  • Take care not to have any {{ or }} in your code. If you have consecutive braces, put a space in between.
  • You cannot use a literal | character inside {{#sf: ..}} because the parser would interpret it as a separator for an additional parameter passed to #sf:. Within a string constant, you can write its octal representation \174 instead.
  • If you put a magic word, template or parser function in a string literal, it will first be evaluated and then the result passed to the StackFunctions code. Use statusdict or parsetemplate/showtemplate if you want to evaluate it only while executing the StackFunctions code. In particular, you should do so within conditional branches so that the parser spends time only on those templates which are actually needed.
  • When using html tags within string literals, take into account that the MediaWiki parser will interpret them before invoking StackFunctions which is probably not what you want. Use \074, \076 instead of <, > to avoid this.


Code in the two syntax forms is executed at different times. In the 1.13.3 MediaWiki parser, first all code in the xml-like syntax is executed, then all code in the function syntax. This implies that, for instance, an object put on the stack by code in function syntax will never be seen by code in xml-like syntax. As this behaviour depends on the internal realization of MediaWiki, you should not trust it remains the same in the future. Therefore I strongly discourage mixing the two syntaxes on the same page (including all templates used on it).

Further reading[edit]

StackFunctions are basically an implementation of PostScript without graphical operators, with a few modifications and with some MediaWiki-specific extensions. I'm not going to explain PostScript here; you might refer to the following sources about PostScript:

Extension:StackFunctions/Reference explains all differences from PostScript, including additional operators and features. Whatever is not mentioned there should work just as in PostScript.

Have a look at Extension:StackFunctions/Internals if you'd like to learn more about the way StackFunctions internally works.


言語: English  • 日本語