Hello Lars, First, sorry for the delay on the other thread about Church booleans. Quite a lot of things cropped up in parallel these days. (And I personally have more non-LaTeX things to do than expected.) It is not forgotten. Inasmuch as I like the Church boolean idea, my first reaction to combinatory logic is "why would we need this in (La)TeX?" I have to admit, though, that I never studied lambda calculus carefully enough to understand any practical use for it (the only course I took that used it mostly mentionned category theory and Yoneda's lemma). > much easier to understand when one transcribes the whole thing into LaTeX > macros. :-) I can imagine that to be true, given the paper that David already mentionned earlier in the thread. > My thought with this mail is mainly to ask whether there are any more of > these (or other standard combinators) that are defined in LaTeX3 already. No. Most often, the cases where those kinds of macros are useful in LaTeX are when you try to control expansion, and that's taken care of by the l3expan module. Maybe some of the functions from that module look a little bit like that (not quite, though). > I seem to recall some discussion to the effect that the C combinator might be > named \use_i_biii_bii:nnn, but I haven't seen any occurrence in the source > of such _bii_ names (then again, maybe I'm not looking close enough). There was such a discussion. I think I was the one to use that in some code I submitted to the scrutiny of LaTeX-L a few months ago. The code itself got refactored in a much cleaner way (IIRC, that's the ancestor of the \tl_act... family of expandable functions). That particular naming scheme is not used currently. However, I have to admit that I introduced and removed \use_i_bii:nn #1#2->#1{#2} a couple of times when coding the (future) floating point module. It might still be floating around there. > Continuing such a naming scheme, one would arrive at maybe > > \use_i_biibiii:nnn for the B combinator > \use_i_biii_biibiii:nnn for the S combinator > > which does not seem entirely practical... I agree, both with what the names could naturally be, and with the fact that it is totally unpractical. A better choice is ad-hoc names such as \combinator_S:nnn. After all, that's how other people call it, not "Apply 1st to 3rd to 2nd applied to 3rd" ("A1t3t2at3"?). In general, a function which does complicated things to its argument should probably get a name specific to the module which uses it. In the floating point module I definitely have functions such as #1#2#3#4#5#6#7#8 -> {#1#2#3#4}{#5#6#7#8} which I won't call \use_B_i_ii_iii_iv_E_B_v_vi_vii_viii_E:nnnnnnnn, but rather \fp_aux_brace_iv_iv:nnnnnnnn, or something like that. > the primary intent for which is that #1{#4} should behave as a Church > boolean, and thus select whether to apply #2 or #3 to the second #4. I > suspect \Lift, \Twiddle, \Compose, and maybe some additional macro could be > combined into an S combinator, but it is not immediately clear to me how. I don't have enough lambda background to figure that one out (and I've still got a few things to change in l3regex before I leave for two weeks). > three years was a lot of time in TeX history, back then. It still is. The engines themselves change, nowadays :). > Somewhat relatedly, it occurs to me that the process of converting > lambda-terms to combinator formulae /might/ be the beginning of an approach > to having "named command parameters" in (high-level) LaTeX without radical > modifications of the TeX engine -- the idea being that the named parameters > are (upon macro definition) removed from the replacement text as a matter of > lambda elimination (conversion of a lambda term to an equivalent > combinatorial term). Whether that would be practical is of course an > entirely different matter. ;-) Care to elaborate?? I can write a fully robust, but entirely unpratical, conversion from named parameters to numbered parameters: pass the definition through ted.sty (or some adaptation thereof). Locate all #. Read the corresponding names. Convert to digits. Build the token list back (that piece is easy, see l3trial/cs-input/cs-input.dtx). For more than 9 arguments, things are harder, but also feasible. I'd argue, though, that it is useless. If you want named parameters, key-value input is much more powerful. Regards, Bruno