MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
References: <4D22486F.5000506@morningstar2.co.uk>
            <19748.47294.93978.108113@morse.mittelbach-online.de>
            <4D24EC4B.1080307@morningstar2.co.uk>
Message-ID:  <19748.64800.644068.699289@morse.mittelbach-online.de>
Date:         Thu, 6 Jan 2011 00:22:08 +0100
Reply-To: Mailing list for the LaTeX3 project
              <LATEX-L@listserv.uni-heidelberg.de>
Sender: Mailing list for the LaTeX3 project <LATEX-L@listserv.uni-heidelberg.de>
From: Frank Mittelbach <frank.mittelbach@LATEX-PROJECT.ORG>
Subject: Re: \box_if_empty:N(TF)
To: LATEX-L@listserv.uni-heidelberg.de
In-Reply-To:  <4D24EC4B.1080307@morningstar2.co.uk>
Precedence: list
Status: R

Joseph,

 > 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

well, as I said the whole box module is crap, but it is not quite clear what
is a non-crappy version in my opinion.

You are right, at this point in time you can only set boxes and so "clearing"
or "unsetting" is only getting rid of the token space which these days is not
so much an issue. In fact already 2e tried to avoid the clearing issue and
only provided \usebox on the user level, but back then space was still more
curial so internally  freeing space was often essential

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

you sure? that shouldn't be the case. It is supposed to be set eq to
\c_empty_box which in turn should be a void box in fact the plain TeX \voidb@x
right now

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

and what happens with vboxes? I mean yes you could provide two modules one for
hboxes and one for vboxes and artifically provide \vbox_new:N and \hbox_new:N
but I'm not sure that flies well. and having a vbox becoming an empty hbox via
"clearing" it doesn't feel right to me.

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

That alone makes me believe that you can't rid yourself of the underlying TeX
concepts and you have to offer a test for void and if you do then the
"clearing" would be best also doing a "void"

 > (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?)

That is what it should do (and i think does): it should produce an assignment
that assigns the permanently void box \c_empty_box (wrong name) so that the
box register afterwards is void

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

as I said, I don't see any good use cases for Heiko's "empty" test. That is
not to say that there aren't any, though. But to make "clearing" -> empty hbox
just to allow for Heiko's test is probably overkill :-) as "clearing" -> void
and testing for void is much much simpler

cheers
frank