LATEX-L Archives

Mailing list for the LaTeX3 project


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
Mailing list for the LaTeX3 project <[log in to unmask]>
Tue, 30 Apr 2013 19:20:11 +0200
Mailing list for the LaTeX3 project <[log in to unmask]>
text/plain; charset=ISO-8859-1
Michiel Helvensteijn <[log in to unmask]>
text/plain (40 lines)
On Tue, Apr 30, 2013 at 4:06 PM, Joseph Wright
<[log in to unmask]> wrote:

> On where '-NoValue-' 'lives', ...etc...

Your problem is that xparse has been trying to cater to two different
target groups. It's meant to create document-level commands. But it's
not clear what kind of environment it's meant to create them from.

On the one hand, the LaTeX3 methodology recommends the use of xparse
for document level commands (rather than the LaTeX2 \newcommand or the
TeX \def). On the other hand, xparse doesn't offer a LaTeX3 syntax! It
was obviously designed to be used independently from expl3. I do
understand. The xparse functionality is useful to both LaTeX3
programmers and other LaTeXers.

As I see it, the 'correct' way to go about this is to follow your own
methodology (I'm a fan of self-reference):

*  Create a LaTeX3 library which provides xparse functionality; let's
call it l3xparse. I'd expect to see functions like
\xparse_new_document_command:Nnn, \xparse_split_argument:nn,
\xparse_if_no_value:n(TF). Actually, a lot of potential \xparse_...
functions probably already exist under a different name, like
\bool_if:n(TF) for \IfBoolean(TF).

*  Expose l3xparse with a thin layer of document-level commands. The
result will be what you now call xparse. The cool thing is, you can
actually use l3xparse to create that thin layer around itself.

Whether the 'no value' placeholder should be different between the two
packages is a separate issue. Syntax wise it doesn't matter, since it
should never be visible in the code. But I'd probably still make it
different, if only to make bugs easier to trace.