On 05/08/2009, at 3:38 PM, Joseph Wright wrote:

> \DeclareDocumentCommand \foo { o[default] m } % now has a default!

Is the syntax to use square brackets or braces? (I thought the latter,  
which is why I ask. As always, I prefer braces; what if the default is  
to contain brackets?)

Lars mentions that he thinks the optional argument is unnecessary; I'm  
not fussed either way, but I like the simplicity of being able to  
write {o m} and having a standard boolean test to check whether it's  
present or not.

> The current xparse implementation lets you create your own specifier
> letters. This is probably very risky:  what if two packages use the  
> same
> letter?  I'd drop this idea.

One comment I have here is that in the future I don't see many people  
defining weird combinations of arguments due to the prevalence of  
keyval-style argument processing instead. I'd even think about  
dropping coordinate-style parenthesis input like "(x,y)" based on  
this. (Which can be emulated easily enough with "d()" and a clist  
mapping in the input.)

On the other hand, I've been keen on the idea of an optional braced  
argument. If it's an all-or-nothing decision about including  
marginised option types, then I'd rather keep 'c' and also add 'n' (or  
whatever) to represent that. Alternatively, I could write a separate  
package for defining functions to accept a variable number of  
arguments. We don't need to cram every possible functionality into  
\DeclareDocumentCommand.

> Will has suggested that we should insist optional arguments follow
> directly on, with no spaces, to mean that:
>
> \foo*{arg}  % #1 = TRUE, #2 = "arg"
> and
>
> \foo   *{arg} % #1 = FALSE, #2 = "*"
>
> are treated differently. The idea here is that it makes LaTeX syntax
> more "regular", useful for translation to other formats.  I think he's
> right, but wonder how others see it.  The current xparse allows both
> space-skipping and non-space-skipping tests.  I'd certainly say we
> should go with only one: either spaces are allowed or they are not.


Re-reading your approach in xparse-alt, I believe what is currently  
implemented there is the best approach. It applies sensible defaults  
and allows overrides; to whit:

{m o}    does not skip spaces
{m o m}  does skip spaces
{m !o}   does skip spaces
{m ^o m} does not skip spaces

Since (a) can't always skip spaces, and (b) never skipping spaces  
leads to inconsistencies, and (c) only need to ignore spaces when the  
optional argument is last -- I strongly think xparse-alt has it right.

Will