MIME-Version: 1.0
References: <AANLkTikP4qMZiiQhF5+vKg36BVuvuHnexsPgnX0bbdw6@mail.gmail.com>
            <AC73355F-F48E-4223-A179-9B61AD638910@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Message-ID:  <AANLkTik91tvdTe2H9aYsuS7_Vzhx0LwC61gOiW-AEZ_x@mail.gmail.com>
Date:         Mon, 21 Feb 2011 06:20:42 -0500
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: Bruno Le Floch <blflatex@GMAIL.COM>
Subject: Re: Fully expandable "x" argument (was "expandable \uppercase...")
To: LATEX-L@listserv.uni-heidelberg.de
In-Reply-To:  <AC73355F-F48E-4223-A179-9B61AD638910@gmail.com>
Precedence: list
Status: R

> I am especially interested in this last part with the e-type argument,
> especially its relationship to LuaTeX's \expanded primitive (also available
> in pdfTeX >= 1.5, if it's turning up in TL this year?). Do you think that
> we'd be able to add 'e' as an argument type using your code above where
> necessary and replace it with \expanded if it's available? Or will there be
> edge cases to cause us headaches?

No headaches, I think :). It all depends on whether the test
`\token_if_expands:N` that I used (not `\token_if_expandable:N`
provided by l3token) is reliable. The only other fine point that I see
is renamed versions of `\noexpand` and `\unexpanded`. Currently, I
only detect `\noexpand`, `\unexpanded`, `\exp_not:N` and `\exp_not:n`,
but I can do some rewrite to use the meaning rather than the string
representation of the tokens.

Of course, I will need to read some documentation (if it exists) on
`\expanded`, to know how it behaves exactly (protected control
sequences?)

> Another function I'd like to see based on this work: expandable nestable
> function mapping. E.g.,

I'm very interested in knowing what should be added, thanks.
Expandable nestable function mapping requires the conversion to carry
around an argument (the function to map), so every function in the
package needs one more argument. I'll do that some time this week.
That will naturally gives something like

\tl_map_function_item_brace_space:nNNN {ab~{cd~{}}~} \foo_i:N
\foo_ii:n \foo_iii:

=>

{
    \foo_i:N a \foo_i:N b \foo_iii:
    \foo_i:n {
         \foo_i:N c \foo_i:N d  \foo_iii:  \foo_ii:n {}
    }
    \foo_iii:
}


> (I haven't looked into doing it non-expandably, which would be more robust.)

My claim is that expandable is just as robust as non-expandable if
- we have access to the full argument (i.e. no peeking ahead)
- there is no token of catcode 1 other than a true "{"
- there is no token of catcode 10 and character code other than 32 (space).

If these conditions are satisfied, then everything can be done
(except, of course, assignments). It will just be much slower in most
cases.


Note that the third condition is actually much less than it seems
because catcode 10 tokens in the input are automatically converted to
"true" spaces:

     \def\space{ }
     \ExplSyntaxOn     \def\tilde{~}
     \ifx\space\tilde   \show\true    \else  \show\false  \fi

shows "\true".

Regards,
Bruno