LATEX-L Archives

Mailing list for the LaTeX3 project


Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

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

Print Reply
Mailing list for the LaTeX3 project <[log in to unmask]>
Tue, 9 Sep 2008 20:44:05 +0200
Mailing list for the LaTeX3 project <[log in to unmask]>
text/plain; charset=us-ascii
Frank Mittelbach <[log in to unmask]>
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

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

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