Re: [stack] Combining Combinators

> Your compose is not a combinator, of course, it is a level one
entity. So I
> conclude that you really intend as your example combinator the
> combination: compose i.

Good catch. That makes what I was saying come closer to making sense :)

> Let us see. Suppose I replace the [map] in your example by [cons]:
...
> But: here is at least one quoted
> level one function, [cons], which can serve as the argument to
> your combination: compose i. So this example shows that your
> combination is not a level three entity of the kind I was looking for.

From here, I see two options:
1. You've convinced me, I'll look around for a proof.
2. `cons' and other list operators are really combinators!

Since (unless I am misunderstanding Joy semantics) lists are also
functions, `cons' can also be thought of as a combinator which expects
a function and composes it with the next token on the stack. The only
sensible definition for combinator I can think of is `a function which
fails if it does not receive a quoted function at the appropriate
position on the stack', which certainly holds true of cons and other
`list' operators.

Of course, all of this semantics is really up to the language
designer. If `cons' cannot be considered a combinator, but only a
first-level list function, you'll have convinced me to start on a
proof of nonexistence.
 
> Nice try, Daniel. Welcome to the group, and stay with us.
Thanks!

~Daniel

PS
A nit-picky correction of your program run:

[1 2 3] [2 *] [1 +] [cons] compose i  ==
[1 2 3] [2 *] [1 +] [cons] [concat] swap concat i  ==
[1 2 3] [2 *] [1 +] [concat] [cons] concat i  ==
[1 2 3] [2 *] [1 +] [concat cons] i  ==
[1 2 3] [2 *] [1 +] concat cons ==
[1 2 3] [2 * 1 +] cons ==
[[1 2 3] 2 * 1 +]

I think this is how it would actually go, and my test run seems to agree.