Hello Lars,

The Church Boolean discussion is not forgotten, just on the
back-burner with so many things at the same time. It seemed to bring
some performance improvements, but there were some awkward parts to it
in the way I initially tried to implement them. In your last email on
the topic a few months back, you had a better approach some working
code, which I didn't get to benchmark carefully. I definitely need to
get back to boolean expressions, since at the moment
(...)&&(...)||(...)&&(...) treats && and || with the same priority,
which is wrong. Perhaps that will mean switching to Church booleans,
perhaps not: there are a lot of issues to consider, including
bootstrapping expl3, having a nice interaction with (future) fp
expression, no breaking change, etc.

> PS: Since I'm posting anyway, I suppose I should mention this too in case
> anyone is interested: After my autumn experiments with Church booleans, I
> went on to implement a fully expandable package for <integer> to <balanced
> text> mappings using 2-3-trees. I didn't quite finish it before getting
> sidetracked by other projects (in this case, actual research), but insertion
> of entries is there and works. Next would have been popping off entries;
> together the two would suffice for making a prioriqueue, which I would
> imagine can be useful in places.

I'm interested in what you have to say about 2-3 trees. I implemented
sorting based on splay trees, which I think I will also use for
Unicode character property lookup in l3regex eventually. None of that
code is in the svn yet.

What do you mean by converting one <integer> to a <balanced text>?
Could you give a couple of examples if you have time?

Sorry I didn't get back to you earlier: writing the ~4000 lines of
l3str+l3regex, plus some combined work with Joseph on xparse took me
most of the past 4 months.

-- 
Regards,
Bruno