MIME-Version: 1.0
References: <CACKZBPWfcegW+5axif=KqKc_cAzpRU5dZq2U4Ti9q8A+zaq+FA@mail.gmail.com>
            <CANQYN6x3Hp5L0NoxnfEXF8Uk1GGFTOuZajeeuGCJpRSHp8HREQ@mail.gmail.com>
            <CACKZBPUuynMgXVtaOwTGQO-0PVt=4i4fG9-LBcPTnxsz2bMMUA@mail.gmail.com>
            <CANQYN6yN7TP9CsQkWAdM8TYMDEwqBKtKFGpy5N3Zm97GhvfcTw@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Message-ID:  <CACKZBPXR4-qZR-h7yZNApO+7MniX7ww0=wuxwJgKSq1-vr9fwQ@mail.gmail.com>
Date:         Wed, 17 Jul 2013 11:39:40 +0200
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: Michiel Helvensteijn <mhelvens@GMAIL.COM>
Subject: Re: Request for argument specifiers which generate unique csnames
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <CANQYN6yN7TP9CsQkWAdM8TYMDEwqBKtKFGpy5N3Zm97GhvfcTw@mail.gmail.com>
Precedence: list
Envelope-To: <rainer.schoepf@GMX.NET>
Status: R

On Wed, Jul 17, 2013 at 2:45 AM, Bruno Le Floch <blflatex@gmail.com> wrote:

> A: Argument specifiers and variants
> ===========================
>
> Well, there are very many conditionals in expl3, and experience has
> shown that the specifiers T and F are useful for visibility (they
> would be even if we only provided the TF versions of conditionals and
> not both T and F too).

Oh, I love T and F.

Slightly off-topic question: why are there no FT variants? I've
encountered situations where it would have made the control flow a lot
more readable. This is certainly not critical but also, I expect,
quite painless to add.

> What about D?  Well, it would be more natural to label all of those
> functions as :w and be done with it

I don't see why it should be an argument specifier at all, since it
says nothing about the arguments. Just use a notation outside the
public interface conventions, like `\name::`.

> A new variant type :Z
> had better (1) alter "expl3 user"-accessible parts of TeX's memory as
> little as possible, hence behave mostly as a pipe that takes some
> tokens as an input and returns other tokens, (2) either be such that
> most N-type arguments (all?) or most n-type arguments can be turned
> into Z-type, (3) so far at least we only have variants which perform
> some kind of expansion.

Such requirements are fine so long as they serve a purpose other than
"well, that's just how we do it".

I agree that the 'purity' or 'side-effect freedom' of these variant
types is a noble goal to strive for, but if more and more (legitimate)
exceptions are made (such as :x and the fp-stuff), it becomes somewhat
meaningless to hold on to this restriction and you'd be better off
properly documenting and regulating side-effecting variants.

Don't get me wrong though. I agree now that :u and :U should not be
argument specifiers. I still think :r might make a nice one, but I do
understand that you wouldn't add such a feature without evidence that
people (other than just me) would find it useful.

> If there was no alternative to providing an argument specifier :r,
> then I might have been in favor of adding it.  However, any
> non-expandable specifier which is a variant of :n can be very well
> approximated using a function that sets a temporary token list, then
> using :o (or :V) expansion.  Namely, if :Z (here, :r) is a variant of
> :n,
>
>     \foo:NnZx \a { AB } <Z-arg> { ghi }
>     % is equivalent to
>     \tl_set:NZ \l_same_for_all_expansions_tl <Z-arg>
>     \foo:Nnox \a { AB } \l_same_for_all_expansions_tl { ghi }

But this is the case for :x too.

> B: Baby-steps towards objects
> =======================

I don't have time to process this section right now. But I will,
because I'm very interested.

>> \with:Vn \l_variable_tl {
>>     \bla:n { \do_not_expand_me bla bla bla #1 bla bla }
>> }
>
> This situation does not need unique identifiers.  Simply

Oh, indeed. This was just a "hello world"-level example of `\with`.

>> Here's how I currently implement my `\something_map_inline`s. I use
>> the non-expl3 version of `\with`, because expl3 doesn't have :U.
>>
>> \cs_new_protected:Nn \something_map_inline:Nn {
>>     \with {Unn} [map_inline] [#2] {
>>         \cs_set:cpn {##1} ####1####2 {##2}
>>         \something_map_function:NN #1 {##1}
>>     }
>> }
>
> I'm not fond of the fact that ##1 and ##2 in the body of \with are not
> at all on the same footing, since ##1 is the unique name and ##2 is
> the original #2.

I don't understand. When are different parameters ever on the same
footing? `\with` simply allows you to pass any 8 (expl3) or 7
(non-expl3) values, expanded however you like, into a block of code
with one command.

> Also, passing arbitrary parameters (here #2)
> surrounded only be square brackets is very fragile, as it tends to
> break if #2 contains some ].

Ah, easy enough to fix. ;-)

\cs_new_protected:Nn \something_map_inline:Nn {
    \with {Un} [map_inline] [{#2}] {
        \cs_set:cpn {##1} ####1####2 ##2
        \something_map_function:NN #1 {##1}
    }
}

> I see that, but I think the ptr package should actually be responsible
> for building its own unique names.

Well, if another package already encapsulates unique-name-creation,
why reinvent the wheel?

Best,

--
www.mhelvens.net