Re: [stack] function/object ambiguity + quotation alternative

On Mar 5, 2009, at 1:03 PM, William Tanksley wrote:

> John Nowak wrote:
>
>> William Tanksley wrote:
>>
>>> I agree that this would be a great way to structure the banana
>>> combinator. I don't know why this would only work on Joy -- your
>>> banana combinator doesn't ever copy the stack, or at least it  
>>> doesn't
>>> require a stack copy.
>>
>> It does require a stack copy in a naive implementation because an
>> identical stack is given to every function. Factor can typically  
>> avoid
>> the stack copy thanks to its stack inference.
>
> I'd simply not perform the stack copy -- if the programmer wants to
> preserve the stack, they can do that by writing programs that have the
> inputs and outputs that the combinator documents as required.

The banana combinator gives all functions access to the "same" stack.  
You have no choice but to copy the stack or to infer the stack effects  
of all functions in the combinator and pass them the appropriate sub- 
stacks.

> That's a good habit. In fact, NOT doing it is such a disastrously  
> bad habit that I don't understand why we're desiring to protect  
> programmers from the consequences thereof.

I'm not solely suggesting you do it to protect programmers from  
mistakes; I'd also suggest you do it because it allows for more things  
to be conveniently expressed.

> I concede that copying the stack is not "a bad habit". I overspoke.  
> I disagree that it's useful

I'm going to be irritating and claim that you're not being imaginative  
enough. Here's a function I often use in Joy programming:

    S [x0..xN] [F] map/w  ==  S [[S x0 F] first .. [S xN F] first]

Essentially, each application of the function gets access to one  
element of the list and the entire stack. Unlike the 'map' combinator  
in Factor however, the function does not need to be careful to copy  
things around on the stack so that successive invocations of the  
function get the same view of the stack. Not only does this make  
reasoning easier, but you also can do nice things like this:

    5 [1 2 3] [+] map/w  ==  5 [6 7 8]

This is just one example of course. You can probably think of others.

> If you want that guarantee, you can use 'case' instead of 'cond'.

Case is less general than cond.

> If you're using 'cond' you're going to either use 'dup' (although  
> I'd argue
> that there's nothing superfluous, and certainly not "a lot") or you're
> working your way through the stack for some other reason.

Yeah, you can make it work. I'd prefer to just have it guaranteed.  
Having one conditional alter what the next one sees is never  
desirable. If you want that, use nested conditionals and make it  
explicit. Ruling out undesirable behavior is a good thing. If you're  
using a language like Joy where "copying" the stack is cheap, I can't  
see why you *wouldn't* want a 'cond' that works such a way.

> This is precisely why I don't like stack copying combinators: they  
> claim
> to be smart about removing "accidental" side effects. How does it know
> which effects are accidental?

That's not what I'd say their claim is; see the 'map/w' example above  
or the banana combinator:

    4 3 2 (| + , - |)  ==  4 5 1

- John