Re: [stack] unary functions from X to Y?

----- Original Message ----- 
From: "Chris Double" <[email protected]>
To: <[email protected]>
Sent: Sunday, March 08, 2009 6:23 PM
Subject: Re: [stack] unary functions from X to Y?


> On Mon, Mar 9, 2009 at 5:58 AM, William Tanksley <[email protected]> wrote:
>> Actually, a queue is a bad choice for the future structure. XY uses it
>> because it wanted an easy to do 'dip', but 'dip' doesn't require a
>> persistent structure. When used only to view and modify the future, XY
>> treats its queue as a stack -- which is the correct approach.
> 
> XY doesn't need access to the end of the queue for dip either. It
> could implement it using patterns:
> 
> ; pdip { [a f] f / a } ;
> 1 2 4 [ + ] pdip
> => 3 4
> 
> Once you have dip is there any need for a retain stack or the ability
> to modify the end of the queue?

well, you need patterns for dip, and i eventually decided that i preferred
the tradeoffs embodied in XY 0 - eliminate patterns, enhance shuffle notation,
and add the ( and ) primitives.  the little example i give in the doc is:

        10 20 30 {x ([x])} 40 50
    10 20 [10 20] [30] [40 50] 40 50

{x ([x])} is a shuffle, not a pattern, and ( quotes the stack and ) quotes the 
queue.

in XY 0 (www.nsl.com/k/xy/xy0.xy) i define dip as:

; swap          {ab ba} ;
; slip          => / <= ;
; dip           swap slip ;

so i guess the question is, can one define dip in XY 0 without => or <=?  i
don't know the answer to this.

but as i said, i wasn't thinking specifically of dip, but more generally, of
what it means to "cache" something in a framework where the computation can
access "all of time".  my thought was that placing something at the farthest
point in the future (i.e. at the end of the queue) comes closest to the naive
idea of a cache.  

> 
>> I think Forth's system is terrible, since it
>> negates the benefits of easy factoring; but XY's system makes it hard to
>> look as far into the future as Forth's system can. But what about
>> partial continuations -- neither language provides those, although both
>> come close.
> 
> XY provides partial continuations in the library. Since XY allows
> complete control of the queue any sort of control structure becomes
> possible. F is similar in that it provides an operator $. It expects a
> quotation on the stack with stack effect ( stack queue -- stack queue
> ). It calls it with the current stack and queue, and replaces the
> existing stack and queue with the result. The other queue/stack
> manipulations are built on that. Too much flexibility?
> 
> Chris.
>