LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Sender:
Mailing list for the LaTeX3 project <[log in to unmask]>
Date:
Tue, 30 Apr 2013 11:42:44 +0200
Reply-To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Message-ID:
Subject:
MIME-Version:
1.0
Content-Transfer-Encoding:
8bit
In-Reply-To:
Content-Type:
text/plain; charset=ISO-8859-1; format=flowed
From:
Lars Hellström <[log in to unmask]>
Parts/Attachments:
text/plain (53 lines)
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 should
>> be used:
>>
>>    \DeclareDocumentCommand { \foo }
>>      {>  { \SplitArgument { 2 } { ; } } m }
>>      { \my_command:nnn #1 }
>>
>> As the output of '\SplitArgument' is some number of brace groups lumped
>> together into a '#1', it seems like a test for '-NoValue' would need to 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 affect
> 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 lot
> of effort.)

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

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

Lars Hellström

ATOM RSS1 RSS2