Re: [stack] Concatenative macros?

[email protected] <[email protected]> wrote:
> i don't quite follow the reasoning here, but it has always
> seemed to me that joy's 'i' (and other combinators as well)
> was unduly restrictive in requiring a *quotation* to
> execute.  and in fact i've never built that restriction
> into any of my languages.

I think that Joy's 'i' will work with a bare function (i.e., 2 2 [+]
car i == 4). Manfred mentioned that he'd never thought of that while
he was building it, and it was accidental (but nice) that it worked.

> the way i've always thought of 'i' was that it took its
> operand x and:  if x is a quotation push the contents of
> x onto the queue, else push x onto the queue.  so
>       [[2]] i
> pushes [2] onto the queue, and it winds up on the stack.
>       3 i
> pushes 3 onto the queue, and it winds up on the stack.
>       [+] i
> pushes + onto the queue, and then it's executed.

> so once again, why can't you interpret i1 and i2 in that
> framework?  in other words, what's wrong with your
> redefinition of 'i'?

You're right. But it's still true that [A]-A and a-A are not *both*
definitions of 'i'. Using your semantics, the problem is that the
second one will execute the list (which will unquote it), but won't
execute any of the things inside the list (functions will be dumped
onto the stack).

Compare the results of [+ -] a-A to the results of [+ -] [A]-A.

So my definition didn't cover the cases well enough, and (at least)
one of my examples was bad. I think I'm going to claim that the
definition of i is a-A, and leave it at that; the meaning of [A]-A
will be to perform 'i' on every item in the list (which is not the
same as performing 'i' on the list).

In other words, uppercase on the left *means* that each item in the
uppercased variable gets 'i' applied to it.

Okay, I think I'm satisfied... This problem was only in my example,
not in my notation.

-Billy