User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; sv-SE; rv:1.9.2.28)
            Gecko/20120306 Thunderbird/3.1.20
MIME-Version: 1.0
References: <517E353C.5050701@morningstar2.co.uk>           
            <CAFXs3kQUtzoSoPY-9mSkxQmpJZqaVCuhC5FviFxi-J1Bp+kyWw@mail.gmail.com>
            <517F75E8.7090900@morningstar2.co.uk>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Message-ID:  <517F9214.9030103@residenset.net>
Date:         Tue, 30 Apr 2013 11:42:44 +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: =?ISO-8859-1?Q?Lars_Hellstr=F6m?= <Lars.Hellstrom@RESIDENSET.NET>
Subject: Re: Behaviour of \SplitArgument with missing input
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <517F75E8.7090900@morningstar2.co.uk>
Precedence: list
Content-Transfer-Encoding: quoted-printable
Envelope-To: <rainer.schoepf@GMX.NET>
Status: R

Joseph Wright skrev 2013-04-30 09.42:
> On 29/04/2013 19:50, scott heard wrote:
>> Hello, forgive (and correct) me if I misunderstand how this command sh=
ould
>> be used:
>>
>>    \DeclareDocumentCommand { \foo }
>>      {>  { \SplitArgument { 2 } { ; } } m }
>>      { \my_command:nnn #1 }
>>
>> As the output of '\SplitArgument' is some number of brace groups lumpe=
d
>> together into a '#1', it seems like a test for '-NoValue' would need t=
o be
>> moved into '\my_command:nnn', i.e. from the xparse interface, into
>> "programmer code".  As `\IfNoValueTF' is an xparse command, that doesn=
't
>> feel correct.  If this is a reasonable interpretation/usage, then my
>> personal opinion would be that empty brace groups (or something else)
> would
>> be preferable to -NoValue-'s.
>> scott
>
> That's a separate but related point, and the one I eluded to in my
> original e-mail. I've been asked about how one is expected to test for
> the '-NoValue-' in the use case outlined, and to provide a code level
> interface or (I guess) some guidance on what the team feel is 'correct'
> in terms of testing.
>
> I thought it was best to pin down what is the 'correct' behaviour of
> \SplitArgument first. However, it is a fair point that this might affec=
t
> the desired behaviour. I'd like to see what people feel is needed from
> \SplitArgument. (It might turn out we'd prefer to have a different but
> code-level testable marker, for example, although that sounds like a lo=
t
> of effort.)

IMHO, the notion that "one cannot use \IfNoValueTF at the code level beca=
use=20
that is a high level command" is utterly bizarre. That many low-level=20
features should not be exposed in a high-level context is one thing, but=20
also doing the converse is usually a sign that one's design is flawed=20
somewhere. When a sensible representation of a fundamental concept (missi=
ng=20
value, boolean true, boolean false, etc.) can be exposed at the high leve=
l,=20
then that representation should be used also at the low level to the exte=
nt=20
possible.

To me, it is intunitively correct that a \SplitArgument { 2 } { ; } on {b=
ar}=20
should yield two NoValues, since clearly two more pieces of data were=20
expected but not provided. It also seems that you may want to provide som=
e=20
variant of \SplitArgument that supplies default values when nothing expli=
cit=20
is given. For \ang{<degree>;<minute>;<second>}, one would probably want 0=
=20
(i.e., fixed value like for classical \newcommand) as default. For=20
\cline{<from>-<to>}, one would probably want the other value to be the=20
default (a classical feature of \section and friends). So that might be t=
wo=20
siblings of \SplitArgument.

Lars Hellstr=F6m