Re: [stack] improved parallel combinator

On Jan 7, 2009, at 4:58 PM, John Nowak wrote:

> On Jan 7, 2009, at 3:51 PM, William Tanksley, Jr wrote:
>
>> But it also occurs to me that a general-purpose word is possible: let
>> me call it "multistack". The idea is that both (- -) and (| |) split
>> data and control flow into multiple stacks, run arbitrary code on
>> those stacks, and then combine the results onto the main stack;
>
> As a result of this, you cannot
> implement 'cleave' with your multistack combinator.

Actually, I don't think you can implement 'parallel' either because  
the first quotation is applied directly to the main stack. 'parallel'  
can actually leave less elements on the stack than it started with as  
in '(| 3drop , id |)'. This doesn't seem possible with 'multistack'.

I should note that your 'multistack' is trivial in a more FP-style  
context. Here, the gatherer's result is used directly for all elements  
in the list. For example, if you just wanted the top two elements for  
each quotation, you'd some function 'R x y -> x y' instead of 'R x y - 
 > R x y x y'. In other words, your gatherer would return *exactly*  
two elements, not two *more* elements. The combiner's results would be  
grouped into a list rather than flattened into a stack. As a result,  
the types involved for 'multistack' with two quotations in the list  
would be as such:

    Gatherer: a -> b
    Quote1:   b -> c
    Quote2:   b -> d
    Combiner: (c -> e) /\ (d -> f)
    Final:    a -> (d, f)

Assuming the combiner is directly supplied, you can remove the need  
for the intersection even if you have higher order functions. (This  
goes for the stack-based version as well.) In either case, you don't  
need row variables or concatenation.

This is probably a good example of why I'm interested in dropping the  
stack-based approach.

- John