Mime-Version:
1.0 (Apple Message framework v935.3)
Content-Type:
text/plain; charset=ISO-8859-1; format=flowed; delsp=yes
Date:
Thu, 3 Sep 2009 10:47:42 +0930
Content-Transfer-Encoding:
8bit
|
On 03/09/2009, at 4:56 AM, Joseph Wright wrote:
> One question occurs to me about xparse "processors". I've provided one
> that splits on a comma, \xparse_process_comma_split:n. I wonder what
> the
> behaviour of this type of function should be if the input is not of
> the
> correct form. At the moment, if you apply a processor to an optional
> argument and no value is given, the special \NoValue token is left
> alone. The normal behaviour for this function is:
>
> \xparse_process_comma_split:n { 1,2 } => {1} {2}
>
> but what should happen with
>
> \xparse_process_comma_split:n { 12 }
>
> A the moment you get "{12} \NoValue" so that exactly two results are
> returned. Should you get perhaps just \NoValue, or something else?
What if I wanted to use more than two 'coordinates'?
\xparse_process_comma_split:n { 1,2,3 } => {1}{2}{3}
In which case:
\xparse_process_comma_split:n { 12 } => {12}
In general terms, I think it should be the responsibility of the
underlying function that is reading the output {12} to pad the braces
if necessary and call an error if wrong input is given.
On the other hand, if the function were given a more specific name
then {12}\NoValue would also be an acceptable output.
Just my 2¢
Will
|
|
|