Hello!
As many of you probably know, during last weeks (and also a lot of
time in 2009 and 2010) I have been working on the WikiScripts
extension (formerly InlineScripts), which allows to embed scripts into
pages.
The language it uses, as well as the instruction of how to use it, are
here: <http://www.mediawiki.org/wiki/Extension:WikiScripts>. Any clean
up of the docs would be appreciated.
(the rest of the mail probably should be read after reading the
documentation; right now it's short, because I'm lazy!)
The reason why we want our own language at all:
* Code maintainability. Right now we have horrible templates like the
legendary {{Citation/core}} nobody can really understand.
* I personally hope that it will be more performance-wise and easier
to optimize (due to fact that it has pretty straightforward
context-free grammar).
* It allows us to increase potential complexity of the code,
introducing things like string functions
The reason why we use our own language is:
* We can restrict is as we want (for example, the for( ; ; )
instruction is not present);
* We can make it platform-independent since it is written in PHP
* Based on some experience with writing those scripts and my generic
experience as well, I have added some nice features absent from
different languages, mainly the append keyword (see docs).
The reason why from InlineScripts it was changed to non-inline model:
* This is the only way we can adequately implement functions.
Previously I wanted to implement them as calling another template
directly from script, but parser overhaul seems useless, and this way
we have a better control over it.
* We can add syntax highlighting
* We can add the code editor
* It is easier to track inclusions that way
* Greater potential for global scripts
== The plan ==
Right now the extension is almost ready. There are certain features I
would like to see there (some are listed below), but no
backwards-incompatible dramatic changes. However, you may want to make
them, so here is my plan
1. We settle down all issues we will not be able to change later due
to b/c. I made a list of some below, you may want to add more. Before
we settle them, we cannot move further.
2. At this point I want someone at WMF review the language description
and make sure it is OK with them.
3. Once the details are settled, we may start doing
internationalization, documentation, cleanup and testing.
4. Probably some live test deployment here.
5. ???
6. PROFIT. WMF-wide deployment here.
== The questions ==
Here are some questions I found worth discussing. We need to discuss
them before we move on:
1. Case sensitivity. Right now the language is case-sensitive. We may
want to change that, since case-insensitivity is more user-friendly.
2. Transclusion from wikitext. I have added two hooks ({{#invoke:}}
and {{s:}}) and will probably add two more for global scripts
({{#globalinvoke:}} and {{g:}}). Any better ideas for hook names are
welcome.
3. Library. Right now I developed a set of conventions in order to
make the function naming more consistent and modular (with ability to
add new modules by extension).
4. Your question here.
== Stability and performance ==
Right now my benchmarking shows that a simple template which uses
{{#switch}} is as effective as a simple module using associated
arrays. You may benchmark yourself and put the results on the wiki. If
we find the problems with performance on the real use cases during
live trial (or before, or after), we have a lot possible performance
tweaks, including:
* Function output caching;
* Built-in optimizer;
* Separate cache for scripts (there aren't as many as templates), in
order to increase hit rate;
* Rewrite of parser in C;
* Rewrite of whole interpreter in C (probably not necessary, 50% to
75% of time is parsing);
* Rewrite of whole MediaWiki in <s>Python</s><s>C</s>
HipHop-compatible PHP!
As of stability, we have built-in platform-independent limits (like
evaluation count) and most of insecure features (recursion, infinite
loops) are disabled (you can still make a deep nested loop, but you
better write the scripts as if Domas knew where you live).
== Future ==
Some possible future tweaks:
* switch construction
* Built-in code editor (with highlighting and auto-ident)
* AJAX-based debugging stuff right in the edit form (syntax check,
calling the function from the edit form instead of preview, etc).
* Global scripts! That would be (probably) easier than global
templates; the only tricky part would be tracking changes and
invalidating local caches.
* Your suggestion submitted here:
https://bugzilla.wikimedia.org/enter_bug.cgi?product=MediaWiki%20extensions…
--vvv