Re: [stack] Concatenative macros?

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.

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'?


[email protected] wrote on 01/11/2007 03:18:57 PM:

> [email protected] <[email protected]> wrote:
> > i think i like this.
>
> I just noticed a problem with my idea. Help me...
>
> > Billy wrote on 01/11/2007 01:02:12 PM:
> > > I propose:
>
> > > i1 [A]-A
>
> [...snip...]
>
> > i2 a-A
> > In my notation, this is the general form of 'i'; it executes anything,
> > list or non-list.
>
> I'm wrong about i2. It won't correctly execute a list, because if i1
> works, the result of executing a list MUST be the list itself. (Try
> passing a list containing a list, such as [[2]], to 'i'.)
>
> So my notation can't express Joy's 'i', because my notation can only
> execute lists, not atoms.
>
> Unless, of course, we choose to allow me to define Joy's 'i' as:
>
> i == [ atom? ] [ a-A ] [ [A]-A ] ifte.
>
> That may be acceptable, since Joy's i wasn't originally intended to
> work that way (it just happened, from what I recall).
>
> What do you think?
>
> -Billy
>