Received: from mail.proteosys.com ([213.139.130.197]) by nummer-3.proteosys with Microsoft SMTPSVC(6.0.3790.3959); Thu, 13 Dec 2007 21:45:52 +0100 Received: by mail.proteosys.com (8.13.8/8.13.8) with ESMTP id lBDKjk1C006138 for ; Thu, 13 Dec 2007 21:45:46 +0100 Received: from listserv.uni-heidelberg.de (listserv.uni-heidelberg.de [129.206.100.94]) by relay2.uni-heidelberg.de (8.13.8/8.13.8) with ESMTP id lBDKaq0X003642 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Dec 2007 21:36:52 +0100 Received: from listserv.uni-heidelberg.de (listserv.uni-heidelberg.de [129.206.100.94]) by listserv.uni-heidelberg.de (8.13.1/8.13.1) with ESMTP id lBDFsqx2013882; Thu, 13 Dec 2007 21:38:48 +0100 Received: by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 15.0) with spool id 234804 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Thu, 13 Dec 2007 21:38:48 +0100 Received: from relay2.uni-heidelberg.de (relay2.uni-heidelberg.de [129.206.210.211]) by listserv.uni-heidelberg.de (8.13.1/8.13.1) with ESMTP id lBDKcmna008079 for ; Thu, 13 Dec 2007 21:38:48 +0100 Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.172]) by relay2.uni-heidelberg.de (8.13.8/8.13.8) with ESMTP id lBDKaKDZ002948 for ; Thu, 13 Dec 2007 21:36:24 +0100 Received: by ug-out-1314.google.com with SMTP id 30so1085750ugc.1 for ; Thu, 13 Dec 2007 12:38:28 -0800 (PST) Received: by 10.67.15.8 with SMTP id s8mr3896708ugi.42.1197578308580; Thu, 13 Dec 2007 12:38:28 -0800 (PST) Received: from macintosh.local ( [89.150.77.105]) by mx.google.com with ESMTPS id x23sm427260ugc.2007.12.13.12.38.25 (version=SSLv3 cipher=OTHER); Thu, 13 Dec 2007 12:38:26 -0800 (PST) Content-Type: multipart/mixed; boundary=----------wi1AV4iqcyOUdZT25p4rBS MIME-Version: 1.0 References: User-Agent: Opera Mail/9.24 (MacPPC) Message-ID: Date: Thu, 13 Dec 2007 21:38:23 +0100 Reply-To: Mailing list for the LaTeX3 project Sender: Mailing list for the LaTeX3 project From: =?iso-8859-1?Q?Morten_H=F8gholm?= Subject: Re: xparse and xdoc To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE In-Reply-To: Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-ProteoSys-SPAM-Score: -102.599 () BAYES_00,USER_IN_WHITELIST X-Scanned-By: MIMEDefang 2.57 on 213.139.130.197 Return-Path: owner-latex-l@LISTSERV.UNI-HEIDELBERG.DE X-OriginalArrivalTime: 13 Dec 2007 20:45:52.0252 (UTC) FILETIME=[266DF3C0:01C83DC9] Status: R X-Status: X-Keywords: X-UID: 5125 ------------wi1AV4iqcyOUdZT25p4rBS Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 Content-Transfer-Encoding: 8bit On Thu, 13 Dec 2007 15:01:13 +0100, Lars Hellström wrote: Hi Larsm > For various reasons,[1] I've decided it is time to start on a new > version[2] of my xdoc package. Since this was in some parts written with > LaTeX3 in mind, this meant I for the first time in several years had to > take a closer look at the codebase. > > Some things I like, other things I don't like. > > To start off on a positive note, I now appreciate \IfBooleanTF and will > probably use it quite a lot in the rewrite. That \BooleanTrue and > \BooleanFalse are no longer available with user catcodes is a bit of a > pity (since I suspect they'll occationally be needed), but perhaps > they'll resurface. Did someone delete them? Apparently I did... No problem to add them and they should be there as they fit well with \IfBooleanTF. > Less nice is that the documentation doesn't say whether \IfBooleanTF is > expandable. I think we can agree that this is something needing attention in all of the experimental code. > Examining the implementation, I can see that it is (good), but that the > companion \IfNoValueTF is not. [...] > OTOH, I don't need to test for those well-maybe-it's-\NoValue-in-a-macro > situations that \IfNoValueTF currently aim to handle, so I'd prefer it > if you provided a simple expandable \IfNoValueTF conditional (perhaps > preserving the current one as \IfLeadingNoValueTF or something if you > really think it will be useful). In want of this, I'm been using the > incantation \ifx\NoValue#1\@empty which could probably serve as a > definition. The complicated tests are there due to comments in old versions of xparse: % However this makes testing for this token slightly complicated as in % that case the test %\begin{verbatim} % \def\seen{#1} % \def\containsNoValue{\NoValue} % \ifx\seen\containsNoValue %\end{verbatim} % will be true if |#1| was |\NoValue| but false if if |#1| itself % contains a macro which contains |\NoValue|; a case that happens % unfortunately very often in practice. The implementation was unfortunately fragile as it assumed one could safely expand one level and then check. I recall the *first* time I tried it on production code and performed \IfNoValueTF{\Big}{}{} which then blew up with a much too familier ! Argument of \bBigg@ has an extra } If we also wish to have a fast test just testing if the first token is \NoValue then I'd define it as \def_long_new:Npn \IfLeadingNoValueTF #1{ \tlist_if_head_eq_meaning:nNTF {#1}\NoValue {}{} } which is relatively safe even if some weird \if:w thing comes first. Yes, the name for the tlist function is ridiculously long, I know. But at least it is precice (I had cases where I wanted to check charcodes, can't remember where though). > The first thing is (not surprisingly) \catcode changes. xparse.dtx lists > this as an open issue and suggests the format specifier > g{} > for this, but also deems it problematic because g is envisioned as > signaling an \url-style argument which can be delimited both by braces > and by some arbitrary character. I think the latter is overkill and > anyway fairly rare, but fiddling with catcodes and the like is common > (e.g. \index, \glossary) enough to warrant support, even though such > fiddling is not unproblematic. However, the catcode trickeries I do, I > do mostly for compatibility with doc, so it would not be a total > disaster if this was lost, but several existing documents would need > editing. + [postprocessing argument] The example file attached implements three new argument types: k = comma (komma in Danish and c was taken ;-) Takes {aaa,bbb,ccc} and transforms into {{aaa}{bbb}{ccc}} g {arg} = executes arg first. d = detokenizes the arguments. Was this what you had in mind? It's just a first take on this - will continue tomorrow. [snip rest for tonight] > What else? \predicate_p:n caught my attention. On one hand, it is a very > nice feature, but on the other its syntax feels like begging for > trouble. || and && for boolean OR and AND in LaTeX? In a mail to Frank I wrote I know using || and && is begging for trouble... On the other hand && is easy to guard against and || brings up the question of when to make characters active. Even though there is a long tradition for using \MakeShortVerb in the preamble, it's the sort of thing I am always worried about and it raises the question of "proper" catcode defences. I considered using control sequences such as \def:Npn \c_or: {OO} \def:Npn\c_and: {AA} and one can do that, no problem. As long as they just expand to something we know what is. > That's just _so_ out of style, although perhaps comforting for > programmers coming from mainstream languages. Also, I wonder whether > (apparently legal) constructions like > > \predicate_p:n{ \boolA && \boolB || \boolC && \boolD } > > does what anyone would expect. What would you expect from that? When one knows AND and OR then one also knows that the expressions can be ambiguous when you mix both operations without delimiting subexpressions. The documentation doesn't say so explicitly but the example there shows such a subexpression. > Separate predicates for the AND of a list of predicates and the OR of a > list of predicates respectively seems preferable. We have had a few different implementations. The one in the December 2006 release on CTAN provides \prg_if_predicate_and_p:nn {}{} \prg_if_predicate_or_p:nn {}{} \prg_if_predicate_not_p:n {} plus some for multiple ANDs and ORs \prg_if_predicate_ors_p:n { ... } \prg_if_predicate_ands_p:n { ... } Two things were wrong with this implementation. Firstly: it evaluated everything and that doesn't fit with the minimal evaluation often needed. One place in xor it led to an error because when a certain switch was false, a register also being tested had been undefined. Even the \..._or_p:nn function evalutated both arguments. Secondly: code written with these functions had a tendency to be incomprehensible. At first there were only the former three mentioned above which made it even harder to see what was being tested in comparison to what when, say, three or four tests where performed, hence the multiple Ands and Ors versions were added. > OTOH, "Ask not what Them can do for you, ask what you can do for Them!" Indeed! :-) Thanks, I will take a look at that tomorrow because as you say: > Well, there's more that could be said, but this is already a very long > mail. Cheers, -- Morten ------------wi1AV4iqcyOUdZT25p4rBS Content-Disposition: attachment; filename=xparse-d-g-k-types.tex Content-Type: application/x-tex; name=xparse-d-g-k-types.tex Content-Transfer-Encoding: Base64 XGRvY3VtZW50Y2xhc3N7YXJ0aWNsZX0KXHVzZXBhY2thZ2VbVDFde2ZvbnRlbmN9 Clx1c2VwYWNrYWdle3RyYWNlLGwzY2xpc3QseHBhcnNlfQoKXEV4cGxTeW50YXhP bgoKClxkZWZcc2hvd2dyYWJiZWR0b2tlbnN7XHNob3d0aGVcbF94cGFyc2VfZ3Jh YmJlZF9hcmdzX3Rva3N9CgpcZGVmX25ldzpOcG4gXHhwYXJzZV9hZGRfYXJnX3R5 cGVfazogewogIFx4cGFyc2VfYWRkX3JlbWFpbmluZ19tX2FyZ3M6CiAgXHRva3Nf cHV0X3JpZ2h0Ok5uIFxsX3hwYXJzZV9ncmFiYmVkX2FyZ3NfdG9rcyB7XHhfcGFy c2Vfazp3fQolIGNvbnRpbnVlIHdpdGggcGFyc2luZyB0aGUgc2lnbmF0dXJlCiAg XGxldDpOTiBceHBhcnNlX3JlYWRfYXJnX3R5cGVfb3JfZ3JhYl9kZWZhdWx0Om4g IAogIFx4cGFyc2VfcGFyc2Vfc2lnbmF0dXJlOm4KfQpcZGVmX25ldzpOcG4gXHhf cGFyc2Vfazp3IHsKICBcZ3JvdXBfYmVnaW46IAogIFxjaGFyX3NldF9jYXRjb2Rl Om5ue2BcLH17MTJ9IFx4X3BhcnNlX2tfYXV4OncKfQpcZGVmX25ldzpOcG4gXHhf cGFyc2Vfa19hdXg6dyAjMVxsX3hwYXJzZV9ncmFiYmVkX2FyZ3NfdG9rcyMyewog IFxncm91cF9lbmQ6CiAgXHRva3NfY2xlYXI6TiBcbF90bXBhX3Rva3MKICBcY2xp c3RfbWFwX2lubGluZTpubiB7IzJ9ewogICAgXHRva3NfcHV0X3JpZ2h0Ok5uIFxs X3RtcGFfdG9rc3t7IyMxfX0KICB9CiAgXHRva3NfcHV0X3JpZ2h0Ok54IFxsX3hw YXJzZV9ncmFiYmVkX2FyZ3NfdG9rc3t7XHRva3NfdXNlOk5cbF90bXBhX3Rva3N9 fSAKICAjMVxsX3hwYXJzZV9ncmFiYmVkX2FyZ3NfdG9rcwp9CgoKXGRlZl9sb25n X25ldzpOcG4gXHhwYXJzZV9hZGRfYXJnX3R5cGVfZzogewogIFx4cGFyc2VfYWRk X3JlbWFpbmluZ19tX2FyZ3M6CiAgXHRva3NfcHV0X3JpZ2h0Ok5uIFxsX3hwYXJz ZV9ncmFiYmVkX2FyZ3NfdG9rcyB7XHhfcGFyc2VfZzp3fQogIFxsZXQ6Tk4gXHhw YXJzZV9yZWFkX2FyZ190eXBlX29yX2dyYWJfZGVmYXVsdDpuICAKICBceHBhcnNl X2dyYWJfZGVmYXVsdF9hcmc6bgp9ClxkZWZfbmV3Ok5wbiBceF9wYXJzZV9nOncg IzF7CiAgXGdyb3VwX2JlZ2luOgogICMxCiAgXHhfcGFyc2VfZ19hdXg6dwp9Clxk ZWZfbmV3Ok5wbiBceF9wYXJzZV9nX2F1eDp3ICMxXGxfeHBhcnNlX2dyYWJiZWRf YXJnc190b2tzIzJ7CiAgXGdyb3VwX2VuZDoKICBcdG9rc19wdXRfcmlnaHQ6Tm4g XGxfeHBhcnNlX2dyYWJiZWRfYXJnc190b2tze3sjMn19CiAgIzFcbF94cGFyc2Vf Z3JhYmJlZF9hcmdzX3Rva3MKfQoKJSBEZXRva2VuaXplIGlucHV0ClxkZWZfbG9u Z19uZXc6TnBuIFx4cGFyc2VfYWRkX2FyZ190eXBlX2Q6IHsKICBceHBhcnNlX2Fk ZF9yZW1haW5pbmdfbV9hcmdzOgogIFx0b2tzX3B1dF9yaWdodDpObiBcbF94cGFy c2VfZ3JhYmJlZF9hcmdzX3Rva3Mge1x4X3BhcnNlX2Q6d30KICBcbGV0Ok5OIFx4 cGFyc2VfcmVhZF9hcmdfdHlwZV9vcl9ncmFiX2RlZmF1bHQ6biAgCiAgXHhwYXJz ZV9wYXJzZV9zaWduYXR1cmU6bgp9ClxkZWZfbmV3Ok5wbiBceF9wYXJzZV9kOncg IzFcbF94cGFyc2VfZ3JhYmJlZF9hcmdzX3Rva3MjMnsKICBcdG9rc19wdXRfcmln aHQ6TnggXGxfeHBhcnNlX2dyYWJiZWRfYXJnc190b2tzewogICAge1x0bGlzdF90 b19zdHI6bnsjMn19fQogICMxXGxfeHBhcnNlX2dyYWJiZWRfYXJnc190b2tzCn0K CgpcRGVjbGFyZURvY3VtZW50Q29tbWFuZFx0ZXN0a2V5e21rbX17fSUgbm8gZGVm aW5pdGlvbiwganVzdCBhIHRlc3QKXERlY2xhcmVEb2N1bWVudENvbW1hbmRcdGVz dGd7bWd7XGNhdGNvZGVgXCU9MTJccmVsYXh9bX17fQpcRGVjbGFyZURvY3VtZW50 Q29tbWFuZFx0ZXN0ZHttZG19e2AjMS0jMi0jMyd9Cgpcc2hvd1x0ZXN0a2V5Clxz aG93XHRlc3RnClxzaG93XHRlc3RkCgpcYmVnaW57ZG9jdW1lbnR9CgpcdHJhY2Vv bgoKXHRlc3RrZXl7YWFhfXtiYmIsY2NjLGRkZCxlZWV9e2ZmZn0KClxzaG93Z3Jh YmJlZHRva2VucwoKXGNhdGNvZGVgXCw9MTMKClx0ZXN0a2V5e2FhYX17YmJiLGNj YyxkZGQsZWVlfXtmZmZ9Cgpcc2hvd3RoZVxjYXRjb2RlYFwsCgpcc2hvd2dyYWJi ZWR0b2tlbnMKClx0ZXN0Z3thYWF9e2JiYiUlZGRkLGVlZX17ZmZmfQoKXHNob3dn cmFiYmVkdG9rZW5zCgpcdGVzdGR7YWFhfXtiYmIkX1xlcnJvciRkZGQsZWVlfXtm ZmZ9Cgpcc2hvd2dyYWJiZWR0b2tlbnMKClx0cmFjZW9mZgoKXHN0b3A= ------------wi1AV4iqcyOUdZT25p4rBS--