Hello Marc,
[For those who don't have the previous email handy, this is a reply to
an email from Marc van Dongen to LaTeX-L on February 9th.]
Sorry I didn't get back to you earlier. I got very busy, both inside
(I think with the new version of l3fp, which will be put on CTAN soon)
and outside LaTeX.
> : The \prg_quicksort: family of functions have been deprecated, and will
> : be removed from l3kernel on or before 2012-05-31.
> :
> : Non-expandable but clearer functions are available in the experimental
> : l3sorrt, recently added to the LaTeX3 CTAN bundle.
>
> I'm attaching a clear and (unless I'm missing something) an expandable
> version of quicksort.
The reason earlier functions were not clear is that:
(1) they allowed arbitrary delimiters between the items,
(2) they allowed customization of the comparison tests,
(3) they allowed customization of how items were output,
(4) they were in fact defining a whole set of functions for a given
set of delimiter/comparison/output.
If you drop all that like you did, the situation is much simpler, and
indeed, can be done in a few dozen lines (I haven't tried, but it
would simply be a matter of taking the older code and simplifying it
in a given case).
Thinking about it again, we may want to ressucitate the concept of
expandable sorting (not in l3kernel, rather in l3sort, which is in the
l3experimental bundle). However, I would advocate only providing such
a sort for token lists (i.e., no delimiters), with a custom test, but
with a fixed output: \exp_not:n. If further processing is needed, one
would do
\prg_new_quicksort:Nn \my_quicksort:n
{ <comparison code> }
% ...later
\exp_last_unbraced:Nf \my_further_processing:n
{ \my_quicksort:n { < token list > } }
That should be simpler than the previous \prg_define_quicksort:nnn,
and hopefully a bit clearer too.
> I started implementing it when I saw your email. It was good fun.
> The actual definition takes 24 lines. The implementation is not
> stable. Please feel free to use/adapt/bin/etc.
As a side note: you are misusing in that code argument specifiers,
denoting 'o' for an argument within brackets, and 'n' for a braced
argument is incorrect. Firstly, "[...]" form a document-level syntax,
while "{...}" should be used at the code level (for instance, because
TeX takes care of matching them). Secondly, the signature, at a code
level, is used to denote how arguments are expanded prior to being
given to a base function (whose signature should only contain 'n' and
'N' in normal cases).
Best regards,
Bruno
|