Lars Hellström writes:

 > 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


The more precise claim is that there is a way to test if #1 is a certain
quark or becomes a certain quark after a limited number of expansions (ie is a
cs that has the quark as it replacement text or is a cs that contains a cs
that ...).

 > 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 is not a claim, but an implementation strategy (the one used)

Here is my claim 3:

 The properties are implemented in the most efficient way possible as they
 will be used at the core of the expl3 kernel when doing parsing or
 manipulating more complex data types such as property lists etc.

 > 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.

The implementation indeed leads to the interesting feature of quarks but so

 \newcommand\foo{Hello \foo}

Has either resulted in a "main problem"? Yes, there is the story from the mid
'80 that some student at Heidelberg Univerity ran up a bill of several
thousand deutsch marks on his account using TeX one night because the account
was billed per CPU cycles of the main frame and his TeX program didn't
finish. Actually it was a different TeX problem that caused it but a quark
would have produced the same effect.

But seriously, would that be a problem these days and in particular would we
have to face it other than perhaps as a developer? Fact is: it hasn't been a
problem for us yet and while I grant that the amount of expl3 productive users
is probably quite small they aren't nil, especially not with Joseph and Will
and now some others dishing out packages that use the kernel (which in turn
uses quarks internally quite a lot).

 >  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.

maybe there will be bugs, but if quarks are used as intended then their use
will be well confined. We have long played with it (and also with alternative
solutions like the one you propose) and my conclusion was that it can stay
... it is however not the day to day programmers tool of choice and I wouldn't
suggest using it outside its intended scope which is parsing and structure
return information like \q_no_value returned by the kernel. I may be wrong
though but for me that should first be proven prior to chaning the design here
(so write a lot of package using expl3 and make a lot such mistakes and then
complain again :-).

 > 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 approach violates claim 2 and consequentially then claim 3

 >    \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.)

this kind of test is being confined to functions (or should be) the fact the
the code doc explains that this is how you can test for it is not intended to
mean that this is how you should test for it at top-level more this is how you
built tests for it such as

%                  \quark_if_nil:N   / (TF)(EXP) |


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

I would say no, not now anyway but opinions may differ