## 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 >>]

Joseph Wright skrev 2010-09-21 21.21:
> Hello all,
>
> The documented use for different quarks in expl3 is broadly as follows:
> - \q_stop and \q_mark for delimiting arguments, with \q_stop used
> mainly
> - \q_nil as a nil pointer

\begin{remark}
Which seems a very odd concept to have within TeX, but should probably
be interpreted as "something that would have been a nil pointer, had
LaTeX been implemented in LISP" (which it of course isn't, but
allegedly Lamport drafted LaTeX in some sort of LISP pseudocode).
\end{remark}

> - \q_no_value to indicate the absence of a value at all
>
> However, the use of these quarks in expl3 has been rather less well
> defined, with \q_nil in particular used in places where \q_stop is most
> appropriate. We've therefore revised the applications, and the SVN
> version of expl3 is now much more systematic in this regard.
>
> In the main, this change should not affect the code others are using as
> these are mainly internal features. However, one place that the
> difference may impact is \tl_head:w and \tl_tail:w. These now terminate
> with \q_stop not \q_nil.
>
> There will be a CTAN update of expl3 and xpackages soon (by the
> weekend, I hope). This will include these changes (along with others:
> see my other e-mails).

Since I was successful regarding the boolean syntax, I think I'd better
try reraising a point regarding quarks as well.

Claim 1. The main property required for a quark is that it is a control
sequence that is distinct from everything that could reasonably be
constructed from normal materials; in particular, it must be such that
the delimited argument in a \def\macro#1\quark{...} grabs material up
to precisely that quark (and no other quark).

Claim 2. The only other property employed is that it is possible to
test a sequence #1 of tokens for being \quark_X by doing
\def\temp_a{#1} \ifx \temp_a \quark_X

Claim 3. These properties are obtained by defining a quark as a macro
that expands to itself. Since the control sequence is contained in its
own definition, the resulting macro contains the information of which
quark it is, and it is thus distinct from other quarks.

This does however lead to the main problem with quarks, that the
documentation sternly warns about: if you ever were to attempt a full
expansion of a quark then TeX would get stuck in an infinite loop. This
dire consequence will of course encourage programmers to get the
details right whenever they work with quarks, but in my experience
these are the kind of details many people have hard to get right
(sometimes because they're applying the data model of LISP to a TeX
language which is quite different), so There Will Be Bugs. It would
therefore be nice if the bugs could have less draconic consequences.

The idea I have proposed is to change the definition of quarks from
effectively

\def\q_nil{\q_nil}
to
\def\q_nil{\string\q_nil}

(this \string should probably be called \quark_protect:N or some such,
but the primitive names are less obscure in a discussion) as a mistaken
expansion of the latter does not lead to an infinite loop; even in
corny contexts such as

\expandafter \expandafter \q_nil

(spaces added after control sequence to distinguish from string of
character tokens) expansion safely terminates via

\expandafter \string \q_nil
\string \string \q_nil
\string\q_nil  % No space after \string, since this \string
% is not a control sequence
\string\string \q_nil
\string\q_nil% Only "other" tokens.

Claim 1 continues to hold for this modified definition. Claim 2 can be
restored if the test for being \quark_X is changed to

\def\temp_a{\string#1} \ifx \temp_a \quark_X

(I get the impression that this kind of test should anyway be handled
by a expl3-provided command rather than explicit user code, so the
number of places to change wouldn't be very large.)

So wouldn't it be better if this was changed?

Lars Hellström