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

 Options: Use Forum View Use Proportional Font Show Text Part by Default Condense Mail Headers Message: [<< First] [< Prev] [Next >] [Last >>] Topic: [<< First] [< Prev] [Next >] [Last >>] Author: [<< 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]> Subject: Re: expl3 variant expansion forms MIME-Version: 1.0 Content-Transfer-Encoding: 7bit In-Reply-To: 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