Re: [stack] utility of the retain stack

John Nowak <[email protected]> wrote:
> (I've recently
> been able to extend the intersection-based type system to a higher
> order language, so this second-order restriction may not last anyway.)

Even a fan of lower-order logic like myself can applaud this result. Good luck!

> The solution seems to be to introduce a retain stack a la Forth (and
> Factor). Here, we indicate the value of the retain stack by placing it
> to the right of the dot. '+r' copies the top element of the retain
> stack to the data stack:

Interestingly, Factor just eliminated its retain stack words. This
makes sense for them, since they've always been higher-order.

I really like the return stack (which is a retain stack on which
return addresses are stored) in Forth. When combined with the
appropriate vocabulary, it gives the low-level programmer the ability
to abstract control flow and data manipulations in an immense number
of ways. Without doubt, it's the most flexible and general approach
known.

The main problem is that it's very low-level. As you noted, it's
possible to use a typechecker to enforce proper usage, but it's more
more graceful to abstract it so that it's impossible to make those
errors. "dip" is one way of doing that. (Technically, locals are a
different abstraction of the same thing, but they're not really a
comfortable "fit" for a concatenative language.) Factor's "fry"
vocabulary is another solution.

It would be interesting to explore whether any better solutions exist.

> Considering how much simpler this is than the version without the
> retain stack, I'm wondering if Joy and Cat are missing something by
> not offering that second stack. Here's how the retain stack version
> might work in Joy:

I think Joy has a good reason to not offer the retain stack. It's
certainly not essential; it's merely handy. And Joy is an experimental
language in very many ways.

But I think you've pointed out an essential weakness of dip.

> - John

-Wm