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