> I know you've written about this before, but I think I've lost the > post (or rather, never received it and read it through the archives at > some stage) where you go into detail about your thoughts on this > matter. I found them (Oct 2007). A selection follows: ================================== There are two _different_ points: 1) a set of macros for dealing with \expandafter and other expanding tricks, 2) incorporating these macros in the names of lots of variants. Point 1 is great - they are wonderful. Point 2 is, imo, more dubious. Besides some basic combinations, I think it's better having small building blocks, which a programmer can rememeber easily and combine when necessary. Provinding such a huge set of macros trying to be clever about what can be necessary is not a good idea. For example, the pair N/c is easy to remember and used very often, but then we have o, O, f, p, w, x, c, T, F (the latter with uppercase inconsistently, as braces are alowed) and so on. [...] And long ago I wrote a full package (tensind, iirc) with the new syntax, and it was a nightmare (unfortunately I lost the file...). Now we have loops, which if fine, and very likely some of the issues has been solved thanks to the macros added recently. In fact, I think providing more tools (and not more variants) is the way to go. Another idea I had is to write a module for the switching mechanism I implemented in mem/labmda/polyglot (kinda «namespaces» but not exactly the same). [On being able to deduce the arguments a command takes from its name.] On the contrary, the arguments should be easily deduced from the logic of the command and the way it's used. [...] ------------------------------- Long ago [years] I pointed out the current scheme is mixing two different things in the parameters: syntax, ie, \macro vs. \csname macro\endcsnameand, and expansion. Then I proposed a new schema, which I've lost but which iirc was based in lowercase = \macro and uppercase = \csname macro\endcsname; eg: n \name N {name} o \pointer O {pointer} In particular, one thing I missed was the very importart O variant, which now is avaliable as C, again with an inconsistent identifier. (I proposed a new type named dormant, but I only remember three things: its name, my doubts it would be useful, and that David (Carlisle) found it interesting - no idea what it was intended for.) > from the uppercase codes perhaps N is the only one really > needed Agreed. In fact, the new C and E (added my Morten, iir) are more useful (and even essential, I'd say). So, let's remove the current O and X and devise a new naming schema. > once more: the basic concept in expl is that all commands > (other than those denoted via :w) have a fixed set of > arguments, say 3 ...:nnn and all variants are conceptually > available for free. This is the concept I like, but I would propose a different approach: - write the type when it belongs to the "mechanical" logic of the commands; - use an auxiliary macro when it belongs to the logic of the problem; - don't use parameter to diffentiate uses. Thus \macro:new:n \name {...} \macro:new:N {name} {...} \macro:new:o \pointer {...} \macro:new:O {pointer} {...} These are "mechanical" variants (note I'm using the scheme above, and a way to clearly identify the module, [...]; I'm aware I'm missing the p/N part). How {...} is manipulated belongs to the logic of the problem, thus: \arg:exp:nx\macro:new:n{...} would make a full expansion of ... (or something similar; again, I'm aware this is better carried out with \edef, which excludes the prefix - this is just a preliminary example). This would allow a more generic manipulation of arguments without the danger of a combinatorial explosion which could be easily extended if there are the necessity of new ways to manipulate arguments: eg, the current E, i = ignore, etc. ----------------------------- >> \use_none:nnnnnnnnn >> \use_none:nnnnnnnnnn This is one of my points. The argument specifiers work fine if there are 1 or 2, maybe 3, which can be read easily, but when we have 4 or more, the eye and the brain will have problems to catch them quickly (or even slowly, as this example). [Things have changed since, but I still think debugging code where a single letter is sooo important and cannot be deduced straightforwardly from the context is not a good idea. I'm not advocating those long names one can find in Java, of course, but in the recent years some lessons has been learned about code readibility and maintainability.] ================================== That's all, folks. Javier