On Wed, Jul 17, 2013 at 2:45 AM, Bruno Le Floch <[log in to unmask]> 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
|