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

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.
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).

By the way, are the words "cleave" and "spread" actually standard use? 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). Yet that's the opposite of how Factor uses
the words. Does anyone know the reason for the naming convention?

> One problem with cleave in a stack-based language is that you need one  
> version for every number of items you want to pass to the cleave. This  
> is because the entire state of the program is passed to every function  
> and you need to "tell" the cleave how many items it cases about. This  
> is not the case in FP.

This is perfectly true, and I admit is a very interesting problem. FP
has its own converse form of the same problem: when you need to combine
multiple flows into one function you need to tell the language. FP has a
very nice syntax for that, of course.

It occurs to me, in passing, that if the problem is merely telling the
notation *how many* inputs it cares about, the solution might be to add
tally marks to the notation. A 2cleave might look like "<<( *,
+ )>" (meaning that each branch takes 2 params and when all is done each
branch pushes 1 result onto the main stack). I chose those tally marks
to make it look like a forked dataflow -- this is a cleave. I don't have
a suggestion for denoting a spread; the obvious idea of using / to tally
the items falls short because it's not obvious how many items go to each
branch.

> 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. But that's something that I've
complained about in the past: I think the elements of a cleave should
execute independent of each other.

> Finally, construction in FP always returns N elements where N is the  
> number of functions used in the construction. This is *much& easier to  
> deal with than cleave in a stack-based language where the output of  
> each cleave is essentially concatenated together into a flat stack.  
> For example, say you have the program 'hd [foo, bar]'. If you know  
> that 'bar' terminates, you can simplify this program to 'foo' without  
> knowing the arities of 'foo' and 'bar'. You cannot do this with cleave  
> in a stack-based language. Similarly, you get nice properties like  
> distributivity that allows you to convert '[foo, bar] baz quux' to  
> '[foo baz, bar baz] quux', and so on.

I have to disagree --- not about those properties being present in FP,
but about your implied claim that there are no complimentary properties
in concatenative languages. There's an algebra available to them too,
even without knowledge of specific dataflow behavior; Manfred has worked
out some of the details already, and there's more to do. In particular,
the algebra of some of the syntax proposals is open to work. Factor's
cleave isn't distributive, but if the two branches are put infra their
own stacks there is a distributive property.

> Hopefully that ramble makes some sense. I've done a lot of thinking  
> about why cleave works better in FP, but I'm still having a bit of  
> trouble articulating it.

I'm glad you're exploring it; thanks to your careful explanations I've
gained an appreciation for FP and the various APL's dataflow
capabilities. 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.

Do concatenative languages have any advantage? I can see two distinct
differences (which may amount to advantages in some situations): first,
concatenative dataflow points in the same direction as program execution
or reading; and second, merging two concatenative dataflows requires no
explicit syntax.

I'm not claiming these are innate advantages; I'm just saying that
they're differences.

> - John

-Wm