Re: [stack] Advantages of cat, joy ..?

On Mar 21, 2009, at 2:45 PM, William Tanksley wrote:

> John Nowak wrote:
>
>> Getting rid of the stack though is necessary to make cleave more  
>> useful.
>
> Hmmmmmm. Is that a well-supported conclusion? It seems a little  
> strong.

I'm confident in that claim. I've given some sporadic explanation for  
this claim previously; I can try and condense my explanation if you'd  
like.

As far as evidence in the wild, I think it's telling that FP,  
Squiggol, J, etc, have all had something like "cleave" from the very  
beginning. Stack-based languages went a long time without it, and now  
that they have it, they require many variants of it.

Again, if you want me to explain myself in full, I don't mind. Perhaps  
expressing my confidence that I'm right isn't enough to convince  
anyone...

> It also seems to presume the need to "make cleave more useful" (as  
> opposed to finding a more useful operation, or redefining cleave in  
> a more useful way).

Good point. That said, I've tried to come up with some better  
alternatives for stack-based languages (the "banana" combinator, etc),  
but I still fact the stack-based nature of things makes it difficult.

> By the way, are the words "cleave" and "spread" actually standard use?

I don't think so. I've no idea where the terms originated.

> I always get them backwards, because it SEEMS to me that "cleaving"  
> dataflow should separate one datum from another, while "spreading"  
> data should take the same data and make it available to more code  
> (like spreading butter over bread).

Now you'll have me doing it too! Indeed, your explanation does make  
perfect sense.

>> Another benefit of the FP approach to construction is that functions
>> in the construction cannot interact. This is not the case with cleave
>> as I've pointed out previously.
>
> Not the way you and Factor define it, no.

Or in Joy or Cat. The obvious definition for 'bi' is '[keep] dip i'.  
This doesn't get you independent evaluation. Actually getting it is  
surprisingly tricky. My banana combinator is one suggestion, but it  
requires each function return a single value which isn't always good.  
Your suggestion for having a prelude and postlude to construct and  
destruct individual stacks works, but I think it's less pleasant than  
how things work in FP. We've been over this though, so I'm sure you'll  
find that I'm just repeating myself now.

> The nice thing about these languages is that they provide
> explicit syntactic support for the programmer to keep multiple  
> distinct
> dataflows. In a concatenative language, there's syntactic support for
> only one dataflow; because most problems need more, you wind up having
> to do some amount of shuffling.

This is a good point. In fact, they often offer multiple syntaxes for  
the same data flow. For example, FL has a "general prefix" syntax  
where 'g f h' == 'f.[g,h]'. You can use whichever feels more  
appropriate. Writing '+.[a,+.[b,c]]' is pretty awkward, but luckily  
you have the equivalent expression 'a + b + c'.

- John