Received: from mx0.gmx.net (mx0.gmx.net [213.165.64.100]) by h1439878.stratoserver.net (8.14.2/8.14.2/Debian-2build1) with SMTP id p05MCP3v012160 for ; Wed, 5 Jan 2011 23:12:26 +0100 Received: (qmail 29542 invoked by alias); 5 Jan 2011 22:12:20 -0000 Delivered-To: GMX delivery to rainer.schoepf@gmx.net Received: (qmail invoked by alias); 05 Jan 2011 22:12:20 -0000 Received: from relay2.uni-heidelberg.de (EHLO relay2.uni-heidelberg.de) [129.206.210.211] by mx0.gmx.net (mx109) with SMTP; 05 Jan 2011 23:12:20 +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 p05MAZKT022395 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Jan 2011 23:10:36 +0100 Received: from listserv.uni-heidelberg.de (localhost.localdomain [127.0.0.1]) by listserv.uni-heidelberg.de (8.13.1/8.13.1) with ESMTP id p05J3ubw002376; Wed, 5 Jan 2011 23:10:33 +0100 Received: by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 16.0) with spool id 816078 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Wed, 5 Jan 2011 23:10:33 +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 p05MAXcq029735 for ; Wed, 5 Jan 2011 23:10:33 +0100 Received: from lon1-post-1.mail.demon.net (lon1-post-1.mail.demon.net [195.173.77.148]) by relay2.uni-heidelberg.de (8.13.8/8.13.8) with ESMTP id p05MAKG1022332 for ; Wed, 5 Jan 2011 23:10:23 +0100 Received: from cremornelane.demon.co.uk ([80.177.25.195] helo=palladium.local) by lon1-post-1.mail.demon.net with esmtp (Exim 4.69) id 1PabYi-0000OX-XF; Wed, 05 Jan 2011 22:10:20 +0000 User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 References: <4D22486F.5000506@morningstar2.co.uk> <19748.47294.93978.108113@morse.mittelbach-online.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <4D24EC4B.1080307@morningstar2.co.uk> Date: Wed, 5 Jan 2011 22:10:19 +0000 Reply-To: Mailing list for the LaTeX3 project Sender: Mailing list for the LaTeX3 project From: Joseph Wright Subject: Re: \box_if_empty:N(TF) To: LATEX-L@listserv.uni-heidelberg.de In-Reply-To: <19748.47294.93978.108113@morse.mittelbach-online.de> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-GMX-Antispam: 0 (Mail was not recognized as spam); Detail=5D7Q89H36p77e5KAPs1l6v/Sb97LojnDtMgfETrECMLUO9erHzOJe7j3G660N4yBY6XHH YPYtmQj6mbYUTZ3LnaFANLWrKE7/wIDhnv+VrW0hxOapLRUwuY9oBqo5h+Dh9B42XlFTMTKlXDju GaV8Q==V1; X-Resent-By: Forwarder X-Resent-For: rainer.schoepf@gmx.net X-Resent-To: rainer@rainer-schoepf.de Status: R X-Status: X-Keywords: X-UID: 6524 On 05/01/2011 18:30, Frank Mittelbach wrote: > well, I think we can clearly state that the l3box module is far from being > what it should be, both in the sense of being incomplete as well as in the > sense of being partly wrong or containing badly named commands. The above > probably being an example of the latter. > > However, I'm not sure that "void" is the best word either. Ok, there is the > meaning "voiding something" ie making it invalid and to some extense that is > what a void box register is: you can't do most of the operations on it. But > there is also the meaning of void that is closer to empty and that is what I > think makes both void and empty a bad choice as there is clearly also > something like an empty hbox (\null) or \vbox{} ie a box that has no content > but is set in terms of what input it could have had. > > maybe \box_if_unset:NTF is closer to its meaning. > > A similar question goes for \box_use_clear:N ... that boxed isn't "cleared" it > is unset too afterwards. First, a comment on the entire \box_use_clear:N (or whatever) concept: I'm not a fan. Yes, this is the what TeX does, but it's far from consistent with every other type of variable. I strongly favour sticking to \box_use:N. As boxes are set (you can't add to them), even \box_clear:N is not really as important as say \tl_clear:N I had a look back through the current code, to think about things more generally. One thing that stuck me is that \box_new:N gives a void box, \box_use_clear:N gives a void box but \box_clear:N gives an empty (h)box. To be honest, I'd have thought we might be better with: - \box_new:N creates a box which is empty (an hbox) - \box_clear:N makes the box empty (an hbox) - \box_use_clear:N is either renamed as you suggest or is simply dropped (unless there is some pressing need for it) This would then mean that new boxes would be 'empty' using Heiko's test, and that the only void/unset/whatever boxes would be 'special' ones such as \l_last_box in some circumstances. (Alternatively, should things be the other way around, with \box_clear:N giving a void box? Is this doable without introducing something into the typesetting stream?) > Heiko's test for emptyness is testing for something quite different, isn't it? > Not sure there is an application for it, but perhaps there is (but probably > only if you provide other complex box manipulation commands as well) I guess it depends on what is decided about the above, but in general I can only see a need to test for void boxes coming from TeX (such as the \l_last_box case I've mentioned). -- Joseph Wright