LATEX-L Archives

Mailing list for the LaTeX3 project


Options: Use Classic View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

Topic: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Sender: Mailing list for the LaTeX3 project <[log in to unmask]>
Date: Wed, 10 Sep 2008 11:54:19 +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 (66 lines)
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):


 \DefineBaseCommand \foo 3 { <do something with args> }

 \def \foo ! #1#2#3 { \csname exp_args:N#1#2#3 \endcsname \foo__base }


 \def \foo ! #1#2#3 { \csname ::#1 \expandafter \endcsname
                      \csname ::#2 \expandafter \endcsname
                      \csname ::#3 \endcsname
                      \::: \foo__base }


 \def \foo__base #1#2#3 { <do something with args> }


 \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:


  - no need to define variants explictly


  - 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.