## LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

 Options: Use Classic View Use Monospaced Font Show Text Part by Default Condense Mail Headers Topic: [<< First] [< Prev] [Next >] [Last >>]

 Sender: Mailing list for the LaTeX3 project <[log in to unmask]> Date: Wed, 22 Sep 2010 17:25:39 +0200 Reply-To: Mailing list for the LaTeX3 project <[log in to unmask]> Message-ID: <[log in to unmask]> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <[log in to unmask]> Content-Type: text/plain; charset=iso-8859-1 From: Frank Mittelbach <[log in to unmask]> Parts/Attachments: text/plain (112 lines) 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). yes  > 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 yes/no 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 does  \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) | etc.  > So wouldn't it be better if this was changed? I would say no, not now anyway but opinions may differ frank