MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Message-ID:  <CANQYN6y1=9vQAK-oe3w1JH87ziwWP1mPkhb0Q3bDzdKRdZ7gRw@mail.gmail.com>
Date:         Thu, 2 Feb 2012 13:24:05 -0500
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: Bruno Le Floch <blflatex@GMAIL.COM>
Subject: Trees, was Re: Mapping Functions Versions for All and Some
To: LATEX-L@listserv.uni-heidelberg.de
Precedence: list
Status: R

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