Extension:WikiScripts/Brainstorming

Script syntax

Syntax of scripts is similar to JavaScript. Supported control structures:

• if ( cond ) { ...}
• if ( cond ) { ... } else { ... }
• for ( x in y ) { }
• try { ... } catch ( e ) { ... }

Control structures which are in JavaScript but are not supported:

• for ( start ; condition ; increment ) { .. }
• while
• with
• Statements without a terminating semicolon

Supported operators

Comparison 

!== != ! <= < >= > === ==

Assignment 

= += -= *= /=

Arithmetic 

** * / + - %

Logic 

& | ^

Conditional 

? :

Grouping 

( )

Member access 

[ ]

TODO

Question to discuss:

• Extension title
• Transclusion model (inline, seperate pages; if seperate pages, do we want them to be modules or something else? How do we transclude those into templates?) (currently most important)
• What is the performance weak point of scripts? Variants:
  • Scanner (text -> lexemes)
  • Parser
  • Interpreter (evaluator) (more difficult to bring out of PHP than others)

To implement:

• typeof instruction
• Limit reporting
• Benchmarking
• More tests?
• Basic functions
  • function foo() { ... }
  • Scope?

Possible transclusion models

Inline

• • Use ordinary transclusion to get more code
• could implement as a parser function fairly straightforwardly?

Of course some folks might do this sort of thing in an article ;) but mostly we'd expect to see it within templates

{{#script: foreach(params) { // add some table rows } }}

• • It is currently implmented as tag (<wikiscript>) that works!

Separate pages

• Separate "script" namespace? Allows code highlighting, editing, etc.
• Module layout: can we access functions in a separate page directly from other pages? If so, what is the syntax? Should it be OOP JS style?
  • pagemodule('Script:Some_module').foo(); ?
  • `Some module`.foo() ?
• Transclusion method from main page:
  • Separate parser function interface: {{#callscript: some module:foo | a = b }}
  • Invoke code through templates, so code has access to template arguments?
• File level code? main() function?

JavaScript-like vs JavaScript subset vs JavaScript

There are some advantages to a JavaScript subset -- easier to implement than full JS, but could be 'upgraded' to real JS in future, or at least have the scripts offloaded to a dedicated service running a JITed JS system (eg, a Node.JS server that uses the V8 engine, same as in Chrome)

Something that isn't *exactly* JS could still potentially be compiled to JS and used similarly though, so this isn't a strict dichotomy.

Disadvantages of passing things to JS engine:

• We are bound by all the disadvantages of JS
• We will have to make two our parsers (PHP and offload server) compatible => we will have to write JS subset interpreter in PHP (since if something is going certain way in JS, we will have to do it that way)
  • to me this is an advantage -- multiple implementations will confirm compatibility :D
    • One would be "main" and force us to do whatever it wants
      • our specification will be "main" and all implemenations will have to match it
        • Our own branch of Node.JS?
          • Just code to standard JS and have a good library. Or if it's a JS-like language that's compiled to JS, we have even more control.
• Double-parsing / parsing + filtering

Mainly it's the environment ("standard library") rather than the language itself that tends to be compatibility issues. By definition we'll be controlling the environment one way or another, so we ought to be able to minimize it.

The question we still do not know is where do we have a problem (parser or evaluation). If it is the earlier, the problem may be easily solved by yacc-generated parser (we have the grammar!) + PHP module/whatever.

(For me, code maintainability is an even bigger reason than performance to be making new scripting infrastructures. Complicated template structures [what do you mean by that?] {{{{{{##{#}#}FODJFODJOIJ}#P#IP{{{I###ifthis}:}}}}}}{#switch}}{{{{{{}{}}}}}{}F}D}SF}}}}}SD}DF}D}FS}}}}}}}}} are hard to understand and reason about; which may also make them harder to profile. It certainly makes them harder to write and maintain.) (OK, got it) :))

It's certainly true that using an external bit or interpreter will likely add overhead, so performance will need to be considered in design and implementation.

Performance criteria depend on applications.

Applications brainstorming

• Cite templates
  • often come in large numbers; *should* generally be not changing their expansions so shouldn't actually need ot be rerun until their input changes. Consider script+parameter caching?
  • Native extensions can also be faster, so many of the calc/string manipulations in them could be replaced.
    • Not only faster, but you can also have different user-preference-dependant foramts. No more citation format holywar! +1
  • Citation templates do actually have wiki-specific presentation logic. They are kind of like skin templates like TAL etc., they take a set of parameters and convert them to presentable wikitext. So it does make sense, on some level, to allow them to be configurable by the wiki's users.
  • Citation templates have programming-like issues associated with them, like backwards compatibility of input parameters. The need for backwards compatibility makes it difficult to replace a frontend template like Template:Cite web with a generic extension.

• Geographical templates: calculate distances on sphere etc.
  • math can be straightforward, but may be easier to read & maintain in a script form
  • If we add cos and sin into language, they will abandon imitating it in parser function
    • i hope there's not an effing template {{#switch}} implementation of log tables...
      • There is a taylor series implementation of cos and sin etc. using ParserFunctions teehee
        • Wait, I just checked and apparently they are already in ParserFunctions (since when?)

• Infobox templates
  • lots of conditionals
  • can benefit A LOT from looping over structured data (vs making 30 optional numbered fields image1 image2 image3 image4...)
  • tend to be particularly large & hard to read

• Anything requires casting strings to certain format. The usual use cases given in favour of enabling StringFunctions.

• Anything where you have multiple things to do with same strings (e.g. {{coolstuff|a|b|c}}).

• Loops are extreme benefits
  • In-wiki calendars

• A Russian user earlier wished for a template to parse a date specified in Russian, and to use the result to calculate the age of a person. It had a lot of clever features like country-specific old style date adjustment. This was already implemented using Template:Padleft but apparently it's a bit ugly.

• Exceedingly clever stuff that we haven't thought of yet