headers
Gabriel Wicke | 1 May 2012 20:51
Favicon

Re: Lua: parser interface

On 05/01/2012 09:15 AM, Tim Starling wrote:
> In summary: the Lua function is called with a single argument, which
> is an object representing the parser interface. The object is roughly
> equivalent to a PPFrame.

+1 for the abstract frame object.

> The object would have a property called "args", which is a table with
> its "index" metamethod overridden to provide lazy-initialised access
> to the parser function arguments with a brief syntax:
> 
> {{#invoke:module|func|name=value}}
> 
> function p.func(frame)
>    return frame.args.name --- returns "value"
> end
> 
> There would be two methods for recursive preprocessing:
> 
> * preprocess() provides basic expansion of wikitext

An alternative to a wikitext-specific preprocess() method and plain-text
argument values could be a conversion / expansion method on an opaque
'parser value' object:

  frame.args.name.expandTo( 'text/x-mediawiki' ) --- returns "value"

This would make it possible to work with other formats apart from wikitext.

I recently added an API like this in Parsoid (the method is called 'as'
(Continue reading)

Permalink | Reply |
headers
Tim Starling | 2 May 2012 04:01
Picon

Re: Lua: parser interface

On 02/05/12 04:51, Gabriel Wicke wrote:
>   frame.args.name.expandTo( 'text/x-mediawiki' ) --- returns "value"
> 
> This would make it possible to work with other formats apart from wikitext.

I can see how that would make sense when you're writing a parser, but
given the target audience for the Lua API, I think I would prefer to
provide an abbreviated interface.

How about frame.args.name as an abbreviation for
frame:getArgument('name'):expandTo( 'text/x-mediawiki' ) ?

And how about frame.plainArgs.name as an abbreviation for
frame:getArgument('name'):expandTo( 'text/plain' ) ?

> I recently added an API like this in Parsoid (the method is called 'as'
> there), and liked the way that worked out for parser functions. I am
> currently using the 'text/plain' type to retrieve a text expansion with
> comments etc stripped, and 'tokens/x-mediawiki' for expanded tokens
> (~list of tags and strings). 

I know you're not really asking for a review of Parsoid and its
interfaces, but I worry as to whether your use of text/plain to
indicate wikitext with comments stripped is appropriate.

In MediaWiki, PPFrame::expand() takes any combination of 5 boolean
flags, and modifies its behaviour based on which of the Parser's 4
output types is selected, so if you were to match it for flexibility,
you would need 128 MIME types.
(Continue reading)

Permalink | Reply |
headers
Platonides | 2 May 2012 12:28
Picon

Re: Lua: parser interface

Is it possible to hook Lua function calls? If so, I'd make a template
expansion a "call" to a function with that name.
That was the interface I envisioned when thinking how I'd do it if
making the language from scratch to suit wikitext
(I drafted some code, but didn't reach to a barely mature level).
Permalink | Reply |
headers
Victor Vasiliev | 2 May 2012 13:04
Picon

Re: Lua: parser interface

On Wed, May 2, 2012 at 2:28 PM, Platonides <Platonides <at> gmail.com> wrote:
> Is it possible to hook Lua function calls? If so, I'd make a template
> expansion a "call" to a function with that name.
> That was the interface I envisioned when thinking how I'd do it if
> making the language from scratch to suit wikitext
> (I drafted some code, but didn't reach to a barely mature level).

Do you mean a situation when you have template X and call to function
X is a transclusion of template X? I have also thought about that as
well. Not all titles are legitimate Lua function names, but there are
more serious issues with that.

This is close to how the first implementation of InlineScripts was
done in 2009. As it turned out, this approach has numerous
disadvantages, the main of which are performance issues (introducing
overhauls by calling the functions through parser instead of direct
call; this is actually a big problem when you have many function
calls), inability to return non-string data (like arrays) and
impossibility of exporting multiple functions from one template.
That's why I strongly believe that all code should be in modules and
modules should be interacting only through Lua itself.

—Victor
Permalink | Reply |
headers
Gabriel Wicke | 2 May 2012 14:55
Favicon

Re: Lua: parser interface

On 05/02/2012 04:01 AM, Tim Starling wrote:
> How about frame.args.name as an abbreviation for
> frame:getArgument('name'):expandTo( 'text/x-mediawiki' ) ?

Yep, that looks good to me. Maybe the specialized wikitext argument
variant could be called 'wikitextArgs' so that the general variant can
be used for ParserValues instead of the getArgument method?

> And how about frame.plainArgs.name as an abbreviation for
> frame:getArgument('name'):expandTo( 'text/plain' ) ?

Adding more xxxArgs methods does not seem to scale that well, and would
introduce a lot of extra method names to remember. It would also
encourage users to pick one representation when they would not need to
care about it, especially if they just pass through some content.

> I know you're not really asking for a review of Parsoid and its
> interfaces, but I worry as to whether your use of text/plain to
> indicate wikitext with comments stripped is appropriate.

I am not that happy with the text/plain bit too. text/x-mediawiki with a
separate progress or 'processing stage' component might be better, as it
would not conflate processing stage with the format. I am using a
numerical 'rank' value to track progress internally in Parsoid, but a
string would likely be user-friendlier for an external API like this.
There is an example for this further down in this post.

> If I were to provide Lua with a richer interface to PPFrame::expand(),
> I would be inclined to support at least some of those flags via named
> options, rather than rolling them up into a single string parameter.
(Continue reading)

Permalink | Reply |

Gmane