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

William Tanksley wrote:
> > XY offers a queue representing the future of a computation, but really  
> > all concatenative languages can be viewed in terms of having such a  
> > queue; some languages simply don't make it programmer-accessible. I  
> > think it therefore reasonable to add a queue to our tuple.
> 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.

On further though, I was wrong.

XY's queue is correctly viewed as the future of the entire program. So
is Forth's return stack. There are two major differences:

1. XY offers the ability to append and remove from the end of the
program. Forth doesn't; you can only modify future behavior for the near
future.

2. XY allows manipulation of functions down to the primitives level: in
other words, XY treats functions as transparent. Forth treats them as
opaque, and only allows you to add or remove them from the return stack
as an entire unit.

Both choices are interesting; but neither one seems to be fundamentally
different from the other. XY offers much easier access to the end of the
program (but you can get that in Forth by picking through the entire
return stack); and Forth offers much easier access to a
function-by-function description of what's about to happen (but you can
get that in XY by picking through the start of the queue). It would be
perfectly possible to add a function to Forth to append a new return
address to the bottom of the stack; it would be a total function change
to make XY treat functions as opaque.

I think the basic lesson is that Forth and XY are doing the same thing,
but using different models of function transparency.

-Wm