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

John Nowak wrote: 
> 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.

I've seen your arguments; and I have to agree that it's clear that
there's a lot of benefits to providing syntactic support for multiple
dataflows, which is something that a fully concatenative language simply
cannot give.

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

I don't see this as significant in any way; the whole idea of a
concatenative language is brand new, and most of them were purely
practical in emphasis.

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

Strange how that works :-). No, I think we've got the basics down. I
agree with everything you said ... but you haven't shown that there's
_nothing_ equally compelling and useful for a stack, merely that we know
of nothing. I'm gonna keep hunting :-), but I'm glad you're explaining
your work here even if it's not (perhaps) _strictly_ concatenative.

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

Cowan pointed out that English has two different words with the same
'cleave' spelling, with opposite meanings. Cowan, I did know that
meaning of 'cleave', and thought about it, but I can't think of any way
to apply it sensibly to this particular problem. Can you explain how it
helps?

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

According to Factor, yes. That doesn't make it "The Definition", it's
just how it's defined for them.

> surprisingly tricky. My banana combinator is one suggestion, but it  
> requires each function return a single value which isn't always good.  

Correct; it's a kind-of-smart combinator. This is the big thing I don't
like about stack-copying behavior... Aside from the fact that
implementing it without an immutable stack is _hard_, it also assumes
the output for every operation is a single value at the top of the
stack.

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

I think we may indeed have reached the edge of how useful cleave/spread
can be in stack-based languages. That's an interesting thought! There
are still (at least) two obvious reasons to keep thinking about stack
languages, even if that's true:

1. There might be an advantage to being able to merge and mix up
dataflows without syntax -- by definition, languages with syntactic
dataflow can't do that.

2. There might be an operator more appropriate for stack languages.

#1 seems absolutely certain, so let's make it a bit harder by requiring
that any advantage ALSO be reasonably "structured". It's no good if the
only advantage is the ability to be able to write spaghetti
dataflow :-).

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

Interesting point -- I didn't even notice. That's actually a close
equivalent to how your banana notation works: in a "strict"
concatenative sense you'd write it as quotations plus a combinator, but
there's an alternative syntax that makes the structure of your intention
much clearer.

Naturally, I'm now wondering if the entire advantage of FL syntactic
dataflow is lost if you take away the alternate syntax -- and,
conversely, whether there's an "alternate syntax" for concatenative
languages which would provide them with something equally nice.

If there is, I rather suspect you're working on something that will lead
to it. I especially like the variant of your language (is it still
called 'fifth'?) which uses juxtaposition to denote composition.

> - John

-Wm