Re: [stack] Code Transformation Problem (possibly monadic?)

On 9/12/07 8:32 AM, "Christopher Diggins" <[email protected]> wrote:

> I have the following problem, and I would be most grateful for any help:
> Given the following sequence of instruction:

> a b m [c m d e] f g
> 
> I want an automated transform (no matter how inefficient, it just has to be
> algorithmic) to rewrite the code so that each instruction applies to the
> stack below the top value, except for "m".
> 
> [..]
> 
I don¹t know whether this will help with the second m inside the square
brackets.
Are we to assume that f is a combinator which executes the preceding
quotation?
Also, I¹m not offering an algorithm either.

So I¹ll change the problem to
>     a b m [1 2 3] f g

I once toyed with the idea of some Joy operators which work hand in hand
with the dip combinator. Dip has to maintain a list (the dip stack) of
temporarily
hidden items that had to be removed from the Joy stack for the duration
of executing the quotation that was given to the dip combinator. When that
execution has finished, the previously dipped value has to be restored from
the dip stack to the Joy stack. During the execution of the quotation the
value that has been temporarily removed from the stack cannot be accessed.

But why not allow at least read access? Invent a new operator peek, which
can only be used inside a quotation. Its effect is to push a copy of the
dipped
value on top of the Joy stack. Example:

> 5 [10 peek /] dip  ==> 5 2
> 
Your example, as amended by me, then becomes:
> 
> [a b peek m [1 2 3] f g] dip
> 
This peek operator would not work if one wanted to access the dipped value
from an enclosing dip. (Maybe that is what your example is driving at). So
a more versatile version of peek would push not just the most recently
dipped value, but a list of all currently dipped values. Then the desired
value
might be the second, third, .. item on this list.

Maybe even a poke operator would be useful: it could pop a value off the
Joy stack and use that as a replacement for the top value of the dip stack.
I don¹t know how nested dips could be handled cleanly without thereby
introducing a rather treacherous programming device resulting in hard
to understand code.

I did not pursue these ideas because dip uses a particular internal register
(dump1, from memory), but some other operators also use it. This was just
bad planning, and I could have introduced a new dump just to handle dip.

At any rate, some versions of peek and poke might find their way into
some concatenative language that uses the dip combinator.

> - Manfred



[Non-text portions of this message have been removed]