MIME-Version: 1.0
References: <CANQYN6x2P2Mr+1LC5gCeUPHxTxRzmfVfPep8-oJ+VnW=5pvf1Q@mail.gmail.com> <20120202131844.GA16372@csmvddesktop>
            <20120202133153.GA16604@csmvddesktop>
            <CANQYN6wtf_6eoyTh6gcwotRYgCthr-mST34MCh7XYMe7uOwq1g@mail.gmail.com> <20120203151218.GA30208@csmvddesktop>
            <4F2BFFA6.1020306@morningstar2.co.uk>
            <20120203155926.GA30436@csmvddesktop>
            <CANQYN6wtqjfifERhYTfEYUh7WB+y1ayUV6BXrCcbYhzDZXzsBw@mail.gmail.com> <20120205160826.GA6939@csmvddesktop>
            <CANQYN6wbQcAVDMh23BCpThRc9Q3NE4Vn94HuC_CTesRLb5LHyw@mail.gmail.com>
            <20120206054259.GB9462@csmvddesktop>
Content-Type: text/plain; charset=ISO-8859-1
Message-ID:  <CANQYN6yCEc4nz8o6O9bni2qrw_Hao211a274h1zeLOgvKNqz2g@mail.gmail.com>
Date:         Mon, 6 Feb 2012 04:26:24 -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: Mapping Functions Versions for All and Some
To: LATEX-L@listserv.uni-heidelberg.de
In-Reply-To:  <20120206054259.GB9462@csmvddesktop>
Precedence: list
Status: R

Hi Marc,

> I've incorporated most of your changes but some don't work, most are
> related to regex. BTW, some of your suggestions in relation to regex
> are not documented. For example, \u.

Update your l3experimental bundle. This is a very recent feature. It
appears to be documented (and hopefully working) in the version on
CTAN (and it got partially reimplemented since then on the svn I
think).

> As it stands, the output that's generated by \meaning looks OK, but it
> isn't. I don't know enough of plain TeX to know why, but I suspect it
> has to do with (regex) substitutions that involve \#1. The following
> paragraph explains why.

The output isn't correct because it produces strings of characters
with category code "other", somewhat like \verb does:
\verb+\def\foo#1{#1}+ will just typeset those characters. In the same
way,

    \regex_replace_once:nnN { .* } { \\def\\foo\#1\{\#1\} } \l_tmpa_tl
    \tl_show:N \l_tmpa_tl % seems ok, but
    \tl_use:N \l_tmpa_tl
    \cs_show:N \foo % didn't define \foo!

will simply typeset \def\foo#1{#1}. You need to use

    \regex_replace_once:nnN { .* } { \c{def} \c{foo} \cP\# 1 \cB\{
\cP\# 1 \cE\} } \l_tmpa_tl
    \tl_show:N \l_tmpa_tl % looks the same
    \tl_use:N \l_tmpa_tl
    \cs_show:N \foo % defined \foo!

after updating your l3str bundle (probably by updating the whole
l3experimental bundle).

> : (5) Of course you know it, this code will run exponentially slowly for
> : large input. That is difficult to solve (but doable; I can give
> : details) if you want an expandable function which expands to the value
> : of your recursion. For a non-expandable function of the form
> : \recursion_get_value_f:nN { <index> } <int var> (dunno how the
> : function should be called), getting a linear-time solution should be
> : easier: it involves storing the intermediate results as you get them.
>
> Thanks. I know the solution. As soon as everything works, I want to
> provide a flag, which the user can use to tell whether or not to cache
> the previously computed values.

I think you are missing something here. If you want \f{4} to _expand_
to the result, then you cannot perform any assignment, since
assignments cannot be made expandably. So caching is (almost) out of
the question. It may be better to take an approach such as

\DeclareDocumentCommand{\f}{om}
  {
    <compute f(#2) using assignments, store the result in
\l_recurrence_result_int>
    \IfValue{#1}
      { \tl_set:NV #1 \l_recurrence_result_int }
      { \int_use:N \l_recurrence_result_int }
  }

Then,

   \f{4} % typesets 5
   \f[\tmp]{4} % stores 5 in \tmp.

> Thanks. I now understand. When I'll provide my remaining comments about
> the expl3 documentation I'll once more give some comments about that
> part of the documentation. I think the documentation is right but it's
> not clear for somebody who is new to the matter. (Or for that sake,
> somebody like me who doesn't know enough low-level TeX. It would be
> nicer if the documentation could be explained without reference to TeX.
> I think it should be possible.)

That would be helpful. Our goal is indeed to make the documentation
clear to someone who doesn't know TeX programming.

> That doesn't work. If I use
>
>     \cs_new_nopar:cpx {\recurrence_case_name:n {\l_recurrence_case_count_int
> - 1}} ##1{
>
> I get a run time error, even for f{0}. I haven't had the time to look into
> it but
> I'll do it when everything else works. (Saving the variable is my least
> concern.)

It works if you define \recurrence_case_name:n using \int_eval:n
internally (take the definition of \recurrence_case_name:N and replace
\int_use:N #1 by \int_eval:n {#1}, IIRC).

> \cP\# doesn't work. I get the following error:
>
>     Illegal parameter number in definition of \regex_replacement_tl:n.

This bug was fixed a couple of weeks ago after Enrico Gregorio pointed
it out to me.

> l_recurrence_name_tl is indeed the one. I tried \u{l_recurrence_name_tl}
> but then the substitution didn't work at all.

As said above, \u is recent, update to the latest CTAN release.

> I tried \c{\u{l_recurrence_name_tl}:n} as well but again, the substitution
> didn't work at all.

idem.

Regards,
Bruno