somebody just mailed me a suggestion privately about interpreting the arg spec at runtime and this way resolving the variant problem (I suggest you use the list next time it is easier for all people involved ... there aren't stupid questions or if, then why is it better if only I read them? :-) Something like this is certainly possible, here is a simple approach that one could implement fairly easily (i think): Provide: ======= \DefineBaseCommand \foo 3 { <do something with args> } defining \def \foo ! #1#2#3 { \csname exp_args:N#1#2#3 \endcsname \foo__base } or \def \foo ! #1#2#3 { \csname ::#1 \expandafter \endcsname \csname ::#2 \expandafter \endcsname \csname ::#3 \endcsname \::: \foo__base } and \def \foo__base #1#2#3 { <do something with args> } then \foo!noo etc would all work. With some changes to the expand module and by making : catcode 12 again you would have a self-extending system that would understand \foo:noo my initial thoughts on this: Pros ==== - no need to define variants explictly Cons ==== - all execution will be slower because of additional processing - use of base function would be very inefficient or inconsistent to the rest, eg \foo:nnn would do all kind of unnecessary things to eventually call \foo__base instead of just "being" \foo__base. - using wrong number of arguments would give really strange errors - one need to understand the base function argument spec which may have args that expect no braces. E.g., doing :oo on a function which expects NN as a base would lead again to very strange and doiffiult to understand errors. cheers frank