MIME-Version: 1.0
References: <4EA7DB88.7020906@residenset.net>
Content-Type: text/plain; charset=ISO-8859-1
Message-ID:  <CANQYN6zcUN2_kJ8eUmA1Y6FX-rNUj6bFo_LMMbBgGSPY=TaCTQ@mail.gmail.com>
Date:         Wed, 26 Oct 2011 06:59:16 -0400
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: S combinator and such
To: LATEX-L@listserv.uni-heidelberg.de
In-Reply-To:  <4EA7DB88.7020906@residenset.net>
Precedence: list
Status: R

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