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, 11 Aug 2009 21:17:38 +0200
Reply-To:
Mailing list for the LaTeX3 project <[log in to unmask]>
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 (155 lines)
Nice to see more people joining the discussion.

Manuel Pégourié-Gonnard skrev:
> Joseph Wright a écrit :
>>> Just to confirm -- have I got this thing sort of right? :)
>>>
> For the sake of the discussion, I'll assume you got it right, but I'd also like
> a confirmation myself.
> 
>>> With this sort of example, it seems pretty clear that this can save a
>>> lot of code that's just shuffling arguments around. (In the same way
>>> that manual optional argument processing consists of lots of
>>> intermediate functions that simply pass their arguments around.)
> I agree. And it makes such a feature totally fit with the goal of xparse:
> allowing the macro writer to go straight to the point without worrying too much
> about user syntax.
> 
>> That was my understanding also.  The question is then whether we
>> want/need to support this for all argument types or just one (or more)
>> specific ones (or of course at all).
>>
> I think that if you want to support this in xparse then it should be accessible
> for all argument types. In my opinion, argument parsing and argument
> preprocessing are orthogonal things, and the syntax should reflect this
> orthogonality.

Well, they are certainly orthogonal, but a nice discovery in xdoc2l3 
was that a single concept could cover both: the processor.

> Besides, if you start offering preprocessing for one argument type, soon you'll
> find out that someone needs it for another type, and either you will create new
> type to fill the gaps, or you will see a collection of packages offering partial
> solutions to the problem (a bit like in LaTeX2e you see a lot of partial
> approaches for multiple optional arguments).

Some excerpts from my posting "Re: xparse and xdoc -- syntax" to this 
list at 2008-02-05 00.13 may help to clarify the idea:

\begin{excerpts}

Since I wanted to stay close to the xparse syntax, I stuck with the 
idea of having each argument type be denoted by a single character, 
followed by zero or more arguments. Since the main new argument type I 
introduced was "composition of processors", I chose the syntax

   @{<processors>}

for this; @ happens to be the function composition operation (\circ) in 
at least Maple. Like functions under composition, the processors are 
going to act on the argument in order right to left; this turned out to 
simplify the translation of these specifiers into actual code.

For the individual processors, I again chose the "single character 
followed by zero or more arguments" syntax, with the choice of 
character being influenced by xparse argument specifiers. Thus there is 
for example

   O{<default>}     Look ahead for a left bracket. If there is one, grab
                    the entire optional argument and place it within
                    braces. Otherwise insert <default> within braces.

   o                Look ahead for a left bracket. If there is one, grab
                    the entire optional argument and place it within
                    braces. Otherwise insert \NoValue and skip all
                    following processors.

   S{<char>}        Look ahead for a <char>. If there is one, gobble it
                    and insert \BooleanTrue, otherwise insert
                    \BooleanFalse.

With these, I can implement several (existing or proposed) xparse 
argument specifiers as mere shorthands for @{...} constructions:

   m                is  @{}  (no processors, just grab an argument)
   o                is  @{o}
   O{<default>}     is  @{O{<default>}}
   S{<symbol>}      is  @{S{<symbol>}}
   s                is  @{S{*}}

To really see the power of this, it is however necessary to have some 
processors which do things to mandatory arguments. Those that there are 
implementations for in the code above are:

   h                         convert argument to a "harmless character
                             sequence", i.e., any problematic character
                             is encoded as \PrintChar{<ASCII code>}

   t                         argument is \stringed

   x{<bool>}{<pre>}{<post>}  argument gets expanded; more precisely, if
                             <bool> is true then
                                <pre>{<argument>}<post>
                             gets expanded and otherwise
                                <pre><argument><post>
                             gets expanded

   .{intrange}{<min>}{<max>} Argument must be some <number>, at least
                             <min> and at most <max>.

The . here is syntactic sugar for "multiletter processor name follows"; 
as with xparse specifiers currently, it would be possible to write 
{intrange}{<min>}{<max>} instead, but having an unbraced character at 
the beginning of a processor specifier makes it easier to read.

With the above, Morten's d specifier (grab and \detokenize) would be a 
shorthand for

   @{ x{\BooleanTrue}{\detokenize}{} }

and it would have the optional counterpart

   @{ x{\BooleanTrue}{\detokenize}{} o }

\end{excerpts}

Combinations I'd like to use in my tclldoc package are:

   @{ h }
   @{ h o }
   @{ x{\BooleanFalse}{\TD@convert@colons}{::\relax} h o }


> As a user/programmer, I expect the l3 tools to solve problems in a uniform and
> rational way, thought not necessarily exhaustive.
> 
>> In the first case, the interface currently used by xparse doesn't really
>> work (I think). You need to go with something like xdoc2l3, where each
>> specifier has a "processing" argument. My worry with that is, as I've
>> said before, that it may be overly complex as a replacement for \newcommand.

The intent was that m, s, and friends should be available for command 
arguments that are simply that, whereas programmers who want something 
more exotic would have the ability to construct it from simple 
processors, using @{...} or something similar.

If you want, it's the same type of idea as with the unix pipeline: 
create simple utilities that do one thing each, and make it possible to 
hook them together. Also provide shorthands for the most common 
combinations.

> Couldn't this processing argument be optional? If we go with the proposal of
> - o (optional argument without default value)
> - O{default}
> then the processing argument would be the only optional argument to all
> specifiers, so this shouldn't cause any confusion.
> 
> This should be a way of preserving the simplicity of xparse (basic) syntax while
> offering part of the power of xdoc2l3.

Could be, but I think treating grabbing and preprocessing as distinct 
tasks is unnecessarily complex; they can be put under the same 
syntactic hat.

Lars Hellström

ATOM RSS1 RSS2