[Wikitext-l] Parser: is *anything* a valid magic word? (from wikitech-l)

Steve Bennett stevagewp at gmail.com
Wed Nov 21 03:26:00 UTC 2007


On 11/20/07, Mark Clements <gmane at kennel17.co.uk> wrote:
> Really, this isn't really about logic in that sense, it's about changing the
> way refer to things.  Part of this is to make a logical distinction between
> the 3 different entities that have a different syntax and a different
> purpose (parser directives, built-in variables and automatic links).

Put like that, it's a compelling argument: those three terms are very
descriptive.

> links, so the term 'automatic links' might be better, and again removes a
> bit of the mystery.

Yep. It could possibly be even better, but I'm not sure how. "Implicit
link"? "Bracketless link"? Dunno. I hate them anyway. :) ("Evil
bracketless link"?...hmm)

> Yes.  It occurred to me, shortly after writing that post, that they should
> not be referred to as "built-in variables", but rather as "built-in
> templates".  That is the term I shall use from now on.

Some of them really behave like variables in a template, but with two
braces instead of 3. "Template" really implies a calculation of some
kind to me. But either is ok.

> > Can "built-in variables" take arguments, and if so, how are they treated?
>
> This is resolved if we refer to them as "built-in templates" instead.

So, they can take arguments, and the syntax is with a pipe like a
normal template. So what is {{DEFAULTSORT:foo}}?

> Hmmm.... well here you've found an exception (and there may be others).
> DEFAULTSORT is a parser directive, but it uses the template-style syntax.

No, it uses a colon. It just happens that Wikipedia has a template
called {{DEFAULTSORT}} which calls {{DEFAULTSORT:{{{1}}}}}. *groan*

> This is partly a symptom of the problem I am describing (lack of a formal
> definition of these items) but is also probably down to the fact that the __
> syntax doesn't support arguments as easily (though I don't see why not).
>
> We need to think about how to resolve this e.g. can we re-define
> DEFAULTSORT:
> __DEFAULTSORT|Sort key__ seems plausible.
> __DEFAULTSORT|{{PAGENAME}}__ seems a little, well, odd... but maybe that's
> just because it's new.

Well, the page name is the default sort key anyway. But, yes.
__FOO|Arg|Arg__ looks ok to me. Would <nowiki> work, if you need to
pass in a __ somewhere?

> Or do we change the syntax to remove all double-underscore directives, and
> change them all to use template syntax?  In this case parser-directives
> could be distinguished by being prefixed with an underscore (e.g.
> {{_NOTOC}}).  Or we could make them into built-in parser functions
> {{#NOTOC}}.

Hmm...well, we're not supposed to be changing anything at all at the
moment. Perhaps we could at least set up a list of all the magic words
at the moment, set up a proposed syntax change, and how they would all
map, and see what it looks like. Of course we could implement the
change in the current parser, to avoid the restriction on changing
syntax and parser at the same time :)

> These last ideas are just off the top of my head mind, and need further
> consideration.  Any syntax changes would of course need to retain existing
> functionality (as 'deprecated' syntax) to preserve backwards compatability.

That's a problem. I was originally asking about "anything being a
magic word" because if anything can be, then parsing is harder.
Changing to a more uniform structure but supporting the old terms
doesn't help much. Though in practice I don't think it will prove to
be a huge problem.

Steve



More information about the Wikitext-l mailing list