Re: [stack] recursion is too hard

On Mar 12, 2009, at 11:05 AM, William Tanksley wrote:

> My preference is to rethink the combinator to not _need_ to be so  
> smart.
> The first "smartness" these combinators have is that they share the
> stack between all the executions (some of your variants copy the  
> stack,
> which I absolutely hate).

They wouldn't copy it in a real implementation. I only explain it that  
way because you can understand it without getting into types.

> The first thing I'd want is to _completely_ isolate the functions from
> each other by running each infra their own fresh stack. The problem  
> then
> becomes how to get the data into each combinator, and how to pull it
> out.
>
> My first knee-jerk solution is to have the programmer provide two
> _additional_ quotations, one that runs before each quotation on the  
> main
> data stack to return a tuple that'll be used as the infra stack and  
> the
> other one to run after after each quotation on the result stack of  
> each
> quotation and return a tuple that'll be expanded onto the stack after
> the entire execution.

The problem is that this is just a pain in the ass to use.

Ideally, we'd have a 'spread' that just "does the right thing". One  
way to do this is to allow each quotation access to *only* one value.  
The results of the quotations would then be concatenated to the main  
stack. More precisely, it would work as such:

    S {T} cat  ==  S T
    S `x `y [F] [G] jn-spread  ==  S {`x F} cat {`y G} cat

This is simple and doesn't require you to explain things in terms of  
types. The downside is that F and G can't access the rest of the  
stack. The only way to make this happen is to use "smart" combinators  
that only make sense if you know the types. Such combinators would  
need to inspect the types of the functions they were given in order to  
work properly. I can give a description of how this might work if  
anyone is interested, but it's downright tedious to explain so I won't  
do it here.

Instead of the type-introspective approach, an easy workaround is to  
provide a 'spread-with' word that takes another argument which is a  
stack to use in both quotations:

    S x y {T} [F] [G] jn-spread-with  ==  S {x T F} cat {y T G} cat

It's true that neither of these suggestions would make writing a  
Factor-style map that uses the entire stack as an accumulator easier  
to write. The type-introspective version would, but given that I don't  
even want to explain it, I can't imagine I'd endorse using it.

I should also note that none of these suggestions are currently  
typeable because they would require row variable concatenation.

- John