MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
References: <48C3DAD1.6030004@morningstar2.co.uk>
            <4B6A6CEE-A06F-4EAC-B618-3B637A5902E4@gmail.com>
            <18630.50165.621679.420173@morse.mittelbach-online.de>
            <20080910071805.GH11109@gracvn.ikra.med.uni-muenchen.de>
Message-ID:  <18631.39243.851035.135331@morse.mittelbach-online.de>
Date:         Wed, 10 Sep 2008 11:54:19 +0200
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: Frank Mittelbach <frank.mittelbach@LATEX-PROJECT.ORG>
Subject: Re: expl3 variant expansion forms
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <20080910071805.GH11109@gracvn.ikra.med.uni-muenchen.de>
Precedence: list
Status: R

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