MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
References: <4DCA93CC.5020605@morningstar2.co.uk>
            <19920.15087.714131.100464@morse.mittelbach-online.de>
            <447088.31292.qm@web24704.mail.ird.yahoo.com>
            <BANLkTinwYoQLJzWWfq0E47OJi-V3+8kQTQ@mail.gmail.com>
            <4DD0BFB3.7070007@morningstar2.co.uk>
            <27DAD3FD-9C28-4707-9454-FBB65B66A56D@gmail.com>
Message-ID:  <19921.39458.647973.867958@morse.mittelbach-online.de>
Date:         Mon, 16 May 2011 23:41:54 +0200
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: Frank Mittelbach <frank.mittelbach@LATEX-PROJECT.ORG>
Subject: Re: xparse and space skipping
To: LATEX-L@listserv.uni-heidelberg.de
In-Reply-To:  <27DAD3FD-9C28-4707-9454-FBB65B66A56D@gmail.com>
Precedence: list
Status: R

 > On 16/05/2011, at 3:39 PM, Joseph Wright wrote:
 > 
 > > To me, that means
 > > 
 > >  \foo[...]{...}
 > > 
 > > is a possible, but I'd hope not
 > > 
 > >  \foo{...}[...]
 > 
 > I think there are enough examples on CTAN where people have needed to
 > extend the optional argument syntax to indicate that the 2e model above is
 > too restricted for user purposes.
--text follows this line--
A simple syntax with unnamed positional arguments (optional or mandatory or
mixed) as 2e provides it has its uses and they go beyond a single optional
argument. But clearly this is a syntax that very fast gets difficult to use or
rather to remember. It all depends on how strong the arguments are "naturally
ordered" and how often such commands are used.
 > 
 > Having said that, I do agree in some cases (such as \makebox[][]{}) an
 > overload of optional arguments is also a bad idea, where a keyval interface
 > makes more sense.

I guess there are worse ones but yes, those kind of commands are good examples
were such a syntax is fast reaching its limits especially as the commands are
seldom used. But if a command is used often enough you can keep a consise
syntax and still have it fairly complex.

Anyway, I'm not arguing key/val no key/val. I'm quite a fan of the letter (sometimes)

 > Dropping trailing optional arguments just doesn't feel right to me; in the
 > interests of disclosure, however, at least two of the packages I've written
 > (pstool and mlist) use them, so I'm clearly biased :)  Their interfaces
 > could certainly be revised but I don't think (yet) in hindsight that the
 > way the commands work therein is necessary a bad idea. 

I wouldn't drop them either (not for xparse anyway) and I think that Lars'
suggestions needs a closer look at to perhaps provide the best of both worlds
even here.

frank