LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

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
Sender:
Mailing list for the LaTeX3 project <[log in to unmask]>
Date:
Thu, 20 Nov 2008 14:08:36 +0100
Content-Disposition:
inline
Reply-To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Subject:
MIME-Version:
1.0
Content-Transfer-Encoding:
7bit
In-Reply-To:
Content-Type:
text/plain; charset=ISO-8859-1
From:
Morten Høgholm <[log in to unmask]>
Parts/Attachments:
text/plain (77 lines)
On Thu, Nov 20, 2008 at 2:58 AM, Will Robertson <[log in to unmask]> wrote:
> On Thu, Nov 20, 2008 at 8:00 AM, Joseph Wright
> <[log in to unmask]> wrote:
>> Hello all,
>>
>> I've been writing a talk about LaTeX3, and something struck me.  Why is it
>> \exp_after:NN and no \exp_after:NO?

Because the O type specification is "read a single token, expand it
once, return it in braces"

I tried to address the situation with the E specifier, which is the
same as O except the braces are removed.

I outlined a different, more generic approach in August:

---------------------------------------------------------------
"Returning expanded tokens without braces"
Arguments are almost always returned with braces and while this is a
good thing overall, it is sometimes not desired. However, there is no
good way to specify that you do not want it returned in braces. You
can resort to adding extra arguments in front using
\use_arg_ii_iii:nnn or similar to remove the braces which is just
obfuscating the code and completely against the idea of the expansion
module.

The point, I think, is that we are mixing up two things here: One is
how arguments are read and the other is how they are handed back to
us. Right now, N is supposed to be read as single token and returned a
single token. o, d, x, f are brace group both when read and when
returned. O, X are single token when read and brace group when
returned.

Here's a crazy idea. What if in the argument specifiers, we use a
special symbol for denoting that the next argument is to be returned
without braces? Such as for example \exp_args:N!o or so which would
pass N unchanged and then ``unbrace'' the result of the o expansion.
Can't use +, -, / or * unfortunately as TeX relies on them having
catcode 12 for calculations. Then this would mean that the o argument
is returned without braces. The way it could be implemented is simple:
  \def_long_new:Npn\::o!#1\:::#2#3{% omit braces around #3
    \exp_after:NN\exp_arg_next:nnn\exp_after:NN{#3}{#1}{#2}
  }
  \def:Npn \exp_args:N!o { \::o! \::: }
Perhaps better would be if it would work like this:
  \def:Npn \exp_args:N!o { \::! \::o \::: }
I.e., this ``unbracer'' modifier is an argument type of its own. If we define
  \def:Npn\::! #1{ \cs_use:c{\cs_to_str:N #1 !} }
  \def:Npn \exp_args:N!o { \::! \::o \::: }
and \::o! as above we get this behavior which feels more natural and
would work with the general mechanism of defining these things.
---------------------------------------------------------------

If the above is implemented, \expandafter would be \exp_args:N!O.

However, it is my feeling that for most practical purposes you only
wish to remove braces from the very last item in the expansion chain.
Therefore, a simpler naming scheme such as
  \exp_args_u:NO
  \exp_args_u:NNo
  etc.
could be employed.

> I guess \exp_after:NN is an edge-case of the naming scheme. In fact,
> it should probably be called \exp_after:ww because in a case like
> this:
>  \foo\expandafter{\bar}
> the opening brace doesn't really qualify as a "N" type argument.

True, \expandafter is really a ww type. I think it would be better to
sort out the unbracing of an argument after it has been through its
expansion steps. It is a typical thing to do for which we currently
use \exp_after:NN in its raw form - I'd like to get away from that.

-- 
Morten

ATOM RSS1 RSS2