On 11/20/07, Mark Clements <gmane(a)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