LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Sender:
Mailing list for the LaTeX3 project <[log in to unmask]>
Date:
Thu, 13 Oct 2011 04:12:19 -0400
Reply-To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Subject:
MIME-Version:
1.0
Message-ID:
In-Reply-To:
Content-Type:
multipart/mixed; boundary=00151747844216eb3404af29b3f8
From:
Bruno Le Floch <[log in to unmask]>
Parts/Attachments:
text/plain (1597 bytes) , alt-booleans.tex (4 kB)
On 10/12/11, Philipp Stephani <[log in to unmask]> wrote:
> 2011/10/12 Lars Hellström <[log in to unmask]>:
>>  True = \lambda xy . x
>>  False = \lambda xy . y
>>
>> These may look strange, but turn out to be two objects that are very
>> familiar to us: \use_i:nn and \use_ii:nn respectively (or \@firstoftwo and
>> \@secondoftwo, for those who still think in 2e terms (like me)).
>
> This is in fact used by etoolbox's toggles.

Yes. I think most of those who had to decide how to implement booleans
have thought about that possibility in the past (together with the
obvious \iffalse/\iftrue, Morten's 01/00, the current LaTeX3
\char"0/1, and probably some others). But it is definitely good to
raise it from time to time.

I just reimplemented (see attached) the boolean expression parser
building upon Lars' suggestion, slightly modified: a predicate shall
f-expand to " { <code> } " such the <code> is a TF conditional
(expandable or not). The difference with Lars is that I require the
braces around <code>. In other words, the predicate must grab all its
arguments and hide itself between braces, so that we can look ahead to
see what operator follows.

If all the tests are expandable, the expression will be expandable. If
some tests are not expandable, the expansion will stop there, and
perhaps bad things will happen in expansion contexts, since tests
further down the line will be run... But in a typesetting context,
everything should work nicely.

It also seems that the reimplementation is somewhat faster (perhaps
30-40%). And the amount of code is the same.

Do we want that?

Regards,
Bruno


ATOM RSS1 RSS2