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