Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Thread-Topic: xparse and xdoc
Thread-Index: Acg9khwgL8YQSIdTTlmX5KFKI/PqYgAlLvOQ
References: A<a038e4e0eb2e79b6112fd170b3bb85ba@residenset.net>
Content-Transfer-Encoding: 8bit
Message-ID:  <9343542E664B894484613D106D7D3F5F84AB36@s-yellow.net.silverstroke.de>
Date:         Fri, 14 Dec 2007 08:58:20 +0100
Reply-To: Mailing list for the LaTeX3 project
              <LATEX-L@LISTSERV.UNI-HEIDELBERG.DE>
Sender: Mailing list for the LaTeX3 project <LATEX-L@LISTSERV.UNI-HEIDELBERG.DE>
From: Jonathan Sauer <Jonathan.Sauer@SILVERSTROKE.COM>
Subject: Re: xparse and xdoc
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
Precedence: list
Status: R

Hello,

> [...]
> I can think of at least three advantages of this kind of 
> postprocessing:

4.	Arguments can be checked (i.e. a numeric argument to be
	in a given range, not empty etc.)

> [...]
> Implementation-wise, a postprocessor could simply be something which 
> fits the syntax
> 
>    <postprocessor> <token register> <grabbed argument>

I would prefer the approach

	<postprocessor> <continuation> <grabbed argument>

where the postprocessor has the task of calling <continuation> (a macro,
possibly with additional parameters) with the <grabbed argument>. That
way, postprocessors can be chained (i.e. first check if it is empty and
replace with zero, then check that the value is not negative). The
final continuation would pass it on to the "real macro" or store it in
a token register.


> Lars Hellström

Jonathan