References: <AFA791BD-820C-4762-AF99-680B5A3DFA07@gmail.com>           
            <4936E30A.5080209@morningstar2.co.uk>           
            <87ljuxlybp.fsf@fawkes.hogwarts>           
            <039B3783CD514B509970052B8B93789E@JavierPC> 
            <27990a880812040533x3316ce17n3e5ae0777b9590c@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original
Content-Transfer-Encoding: 8bit
Importance: Normal
Message-ID:  <BF79113EB8AF459685A8FDDCF46774BF@JavierPC>
Date:         Sun, 7 Dec 2008 10:08:42 +0100
Reply-To: Mailing list for the LaTeX3 project
              <LATEX-L@LISTSERV.UNI-HEIDELBERG.DE>
Sender: Mailing list for the LaTeX3 project <LATEX-L@LISTSERV.UNI-HEIDELBERG.DE>
From: Javier Bezos <listas@TEX-TIPOGRAFIA.COM>
Subject: Re: expl3 "token list" terminology
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
Precedence: list
Status: R

> 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