## LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

 Options: Use Classic View Use Monospaced Font Show Text Part by Default Condense Mail Headers Topic: [<< First] [< Prev] [Next >] [Last >>]

 Sender: Mailing list for the LaTeX3 project <[log in to unmask]> Date: Tue, 9 Sep 2008 20:44:05 +0200 Reply-To: Mailing list for the LaTeX3 project <[log in to unmask]> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit In-Reply-To: <[log in to unmask]> Content-Type: text/plain; charset=us-ascii From: Frank Mittelbach <[log in to unmask]> Parts/Attachments: text/plain (57 lines) I don't really think that it is necessary or even desirable to define all types of variant expansion forms (in all permutations) up front just for the sake of it. Ideally when I write \foo:ABC where ABC is some form of arg spec, eg "xoc" "noo" or ... then what should happen is that automagically the arguments should be get properly expanded and then the corresponding base function (ie \foo:nnn should be called passing the correctly expanded arguments). And that should work for any permutation that you can think of. Unfortunately, TeX can't autogenerate functions if they are missing because we are missing a callback function that gets called in case of "undefined csname". So either  - we provide all variants up front  - we do all our parsing ourselves (so that we can detect missing functions)    but that makes a lot of processing very slow but it would be an option  - get thatm missing functionality into a TeX successor and use it  - or we do simply do the last step (generation of missing functions) manually currently the concept is the latter:  - there is only one single unique way of providing a variant from a given    base function, eg, having the base function \foo:nnn I'll get \foo:noo by    doing:   \def:Npn \foo:noo {\exp_args:Nnoo \foo:nnn }  - so either the variant is defined in expl3 or a package could define it    andone can be sure that two package would define it in exactly the same way    so the double definition wouldn't hurt (a simple def is extremly fast and    assuming nobody makes a mistake the definitions would always be the same)  - (one oculd also think of providing a more abstract interface for defining    variants from base functions) so far the approach was to not provide all possible permutations but wait until it becomes clear that certain forms are actually needed and if so gradually move them from packages to the core language. it is certainly questionable where to draw the line here, but for functions with 3 or more arguments the number of permutations become huge and in many cases most of them are useless. So rather than providing everyting for the sake of uniformity I would suggest to allow for gaps (as they can be very very easily filled ... for any developer who understood the construction method). cheers frank