some thoughts on XY [was Re: [stack] Re: unary functions from X to Y?]

XY went through several versions.  i'm not sure which one chris
has implemented.  the version i was most satisfied with is what
i called "XY 0".  a precis of the languages is written up here:

http://www.nsl.com/k/xy/xy.txt

XY 0 has:

        ->      queue           [X^z Y] -> [X z]
        <-      stack           [X^z Y] -> [z Y]

        =>      cache           [X^z Y] -> [X Y^z]
        <=      uncache         [X Y^z] -> [X^z Y]

        /       use             [X^z Y] -> [X z,Y]
        \       mention         [X z^Y] -> [X^z Y]

        `       enclose         [X^z Y] -> [X^{z} Y]
                disclose        [X^{z} Y] -> [X^z Y]

        (       stack*          [X Y] -> [X^[X] Y]
        )       queue*          [X Y] -> [X^[Y] Y]

in particular, note enclose/disclose, which makes a function from 
a quotation and vice-versa:

    2 [+]`
2 `[+]
    `
2 [+]

i think that XY functions are similar to what john has called "function 
objects."  the concatenation of two quotations is a quotation whose 
parts are the parts of the concatenated quotations, but the concatenation 
of two functions is a quotation whose parts are the functions:

  [2 +]` [3 +]` ,   // concatenate two functions
[[2 +]` [3 +]`]
  #:                // count
2

(there are other possibilities, e.g. the concatenation of two functions
is a function which concatenates the results of applying the functions,
&c.)

XY has three reserved names:  _x, _y, and _z, which represents the past, 
present, and future of the computation as it is perceived by the executing
pattern:

        _x      the stack minus the elements mapped to the template
        _y      the queue minus the current pattern
        _z      the current pattern

XY 0 disposes of these (and patterns as well) and replaces them with ( 
and ), which can be used to retrieve the same information (but don't 
ask me how.)

i will speculate that it can't be that difficult to modify the evaluator
to produce functions instead of verbs.  e.g. instead of:

    2 [+] *:        // first of [+]
  2 +

we could have:

    2 [+] *:
  2 `+

the main idea behind XY was to find a structure which could be used
to "transcend" the search for alternate bases, e.g. do we use {dup,
dip, pop} or {nip, tuck} or ... ?  in the first place, i could never
remember how the more exotic operations worked.  and there was also
this problem:  although a quotation like [pop dup swap] contains 
all the information about the before and after state of the stack,
any program which tries to analyze the meaning of that quotation 
will have to look up the stack effects in some table.  stack operation
words are "opaque".

also, it seemed to me that the various forms of shuffle-notation (which
are not opaque if their parts are available) are not quite powerful 
enough to define all the stack operations (e.g. dip) without turning into 
full-blown lambdas with named arguments.  

once i had introduced the queue as a first-class entity on par with the 
stack, these questions became irrelevant, and some new opportunities appeared,
e.g. the ability to define various forms of the continuation control.  
and the idea of having both the past and future of the computation
available to the computation was philosophically appealing.

----- Original Message ----- 
From: "Chris Double" <[email protected]>
To: <[email protected]>
Sent: Friday, March 06, 2009 2:15 AM
Subject: Re: [stack] Re: unary functions from X to Y?


> On Fri, Mar 6, 2009 at 8:02 PM, John Nowak <[email protected]> wrote:
>> I was not aware of 'abort'; you are certainly right it seems. As I
>> know very little about XY, I'll have to take your word for it
>> regarding '=>'.
> 
> '=>' is a it like >r in factor except it doesn't use a separate retain
> stack. It takes 1 item off the stack and places it at the tail of the
> queue. If it's not popped off later with '<=' it gets executed when
> the queue reaches that point.
> 
>> I suppose I should actually use XY one of these days... at least
>> before I make any more claims about it. Until then, please consider my
>> proposal void.
> 
> I have mostly working JS implementation:
> 
> http://tech.groups.yahoo.com/group/concatenative/message/4305
> 
> It doesn't do the projection thing mentioned above however.
> 
> Chris.
> -- 
> http://www.bluishcoder.co.nz
>