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

On Dec 11, 2007 3:37 AM, Manfred Von Thun <[email protected]> wrote:
> 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?

No, unfortunately we can't assume that. Otherwise I would have to
compile each word, to find out exactly what it does.

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

That is an interesting approach.

> 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.

I am hoping for that the operators can be oblivious of their nesting.
I think there could be problems though with dynamic construction of quotation:

[a b peek m ...] quote dip.

> 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.

Any transformation that I am looking at is only for compilers. Hard to
understand code is completely acceptable.

> 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.

Did you consider the primitive construction:

dip == swap cons i

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

- Christopher