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>
            <19921.39458.647973.867958@morse.mittelbach-online.de>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-363264706-1305582688=:59964"
Message-ID:  <894329.59964.qm@web82005.mail.mud.yahoo.com>
Date:         Mon, 16 May 2011 14:51:28 -0700
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: Paul Thompson <patjah@SBCGLOBAL.NET>
Subject: Re: xparse and space skipping
To: LATEX-L@listserv.uni-heidelberg.de
In-Reply-To:  <19921.39458.647973.867958@morse.mittelbach-online.de>
Precedence: list
Status: R

--0-363264706-1305582688=:59964
Content-Type: text/plain; charset=us-ascii

I really wish that the positional thing was somewhat deprecated in favor of a 
named argument approach, which would replace the limit of 9 at some point.

 Paul Thompson 


Professor and Senior Scientist
Director, Methodology and Data Analysis Center
Sanford Research
900 W Delaware
Sioux Falls, SD    57104


O: 605-312-6462
M: 618-974-0473
H: 605-332-1587
F: 605-328-0401


909 N. Charleston Circle
Sioux Falls, SD 57110
605-332-1587


________________________________
From: Frank Mittelbach <frank.mittelbach@LATEX-PROJECT.ORG>
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
Sent: Mon, May 16, 2011 4:41:54 PM
Subject: Re: xparse and space skipping

> 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

--0-363264706-1305582688=:59964
Content-Type: text/html; charset=us-ascii

<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:verdana,helvetica,sans-serif;font-size:10pt">I really wish that the positional thing was somewhat deprecated in favor of a named argument approach, which would replace the limit of 9 at some point.<br><div>&nbsp;</div>Paul Thompson <br><br><div>Professor and Senior Scientist<br>Director, Methodology and Data Analysis Center<br>Sanford Research<br>900 W Delaware<br>Sioux Falls, SD    57104</div><br><br><div>O: 605-312-6462<br>M: 618-974-0473<br>H: 605-332-1587<br>F: 605-328-0401</div><br><br><div>909 N. Charleston Circle<br>Sioux Falls, SD 57110<br>605-332-1587<div><br></div><div style="font-family:verdana, helvetica, sans-serif;font-size:10pt"><br><div style="font-family:arial, helvetica, sans-serif;font-size:13px"><font size="2" face="Tahoma"><hr size="1"><b><span style="font-weight: bold;">From:</span></b> Frank Mittelbach
 &lt;frank.mittelbach@LATEX-PROJECT.ORG&gt;<br><b><span style="font-weight: bold;">To:</span></b> LATEX-L@LISTSERV.UNI-HEIDELBERG.DE<br><b><span style="font-weight: bold;">Sent:</span></b> Mon, May 16, 2011 4:41:54 PM<br><b><span style="font-weight: bold;">Subject:</span></b> Re: xparse and space skipping<br></font><br>
 &gt; On 16/05/2011, at 3:39 PM, Joseph Wright wrote:<br> &gt; <br> &gt; &gt; To me, that means<br> &gt; &gt; <br> &gt; &gt;&nbsp; \foo[...]{...}<br> &gt; &gt; <br> &gt; &gt; is a possible, but I'd hope not<br> &gt; &gt; <br> &gt; &gt;&nbsp; \foo{...}[...]<br> &gt; <br> &gt; I think there are enough examples on CTAN where people have needed to<br> &gt; extend the optional argument syntax to indicate that the 2e model above is<br> &gt; too restricted for user purposes.<br>--text follows this line--<br>A simple syntax with unnamed positional arguments (optional or mandatory or<br>mixed) as 2e provides it has its uses and they go beyond a single optional<br>argument. But clearly this is a syntax that very fast gets difficult to use or<br>rather to remember. It all depends on how strong the arguments are "naturally<br>ordered" and how often such commands are used.<br> &gt; <br> &gt; Having said that, I do agree in some cases (such as \makebox[][]{}) an<br>
 &gt; overload of optional arguments is also a bad idea, where a keyval interface<br> &gt; makes more sense.<br><br>I guess there are worse ones but yes, those kind of commands are good examples<br>were such a syntax is fast reaching its limits especially as the commands are<br>seldom used. But if a command is used often enough you can keep a consise<br>syntax and still have it fairly complex.<br><br>Anyway, I'm not arguing key/val no key/val. I'm quite a fan of the letter (sometimes)<br><br> &gt; Dropping trailing optional arguments just doesn't feel right to me; in the<br> &gt; interests of disclosure, however, at least two of the packages I've written<br> &gt; (pstool and mlist) use them, so I'm clearly biased :)&nbsp; Their interfaces<br> &gt; could certainly be revised but I don't think (yet) in hindsight that the<br> &gt; way the commands work therein is necessary a bad idea. <br><br>I wouldn't drop them either (not for xparse anyway) and I think
 that Lars'<br>suggestions needs a closer look at to perhaps provide the best of both worlds<br>even here.<br><br>frank<br></div></div></div>


</div></body></html>
--0-363264706-1305582688=:59964--