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

John Nowak wrote:
> William Tanksley wrote:
> > For example, applicative languages make it easy to implement a very
> > limited amount of parallel control flow: the parameters of a function
> > are evaluated independently, so in theory they could be evaluated in
> > parallel. One possible solution is to invent control structures that  
> > are
> > explicitly parallel; indeed, this has been done for at least one very
> > interesting language, Factor.

> Representing stack-based code in a graphical manner exposes  
> essentially all of the parallelism you'd get in an applicative  
> language.

That's a fair statement; actually, of course, graphical representation
gives you a LOT more control over parallelism than an applicative
language alone can give. The same is true for explicitly parallel
control structures.

> There are areas where applicatively languages are better  
> (primarily implementing existing algorithms and math equations),

Algorithms are no challenge for concatenative languages. Equations are
more of a challenge, since there's a bigger translation step most of the
time. (However, I did actually use a concatenative notation in one math
class -- sorry, I forget the author, and the title was "Modern Algebra",
which tells Google nothing.)

>  but I  
> don't think parallelism is one of them. Well, at least not in any way  
> that matters; if you're talking about implicit parallelism, your  
> compiler is going to be figuring it out for you anyway.

You're right. The parallelism in the arguments of functions is almost
always accidental; a compiler that took advantage of it would probably
break many programs.

> Talking about "human factors", I really think an interface that would  
> draw out your data flow in real-time as you coded (which is trivial to  
> do in a flat language), complete with type labels, etc, would make a  
> huge difference. You'd name the inputs and outputs to your function as  
> you do in Forth/Factor, but you could think about these labels as  
> names for "ports". The diagram would represent a push-based, strictly- 
> downward dataflow program. As soon as I get the time, I'll try and put  
> something together; I have the unfortunate obligation of working to  
> feed myself lately. The idea would be to make concatenative  
> programming accessible to artists and incorporate some functional  
> reactive programming ideas.

Factor has a nice emacs mode; I wonder if something like that could be
coded in Emacs (which would allow it to use the very nice FUEL
Factor-Emacs integration)?

I see:
http://www.xemacs.org/Documentation/21.5/html/xemacs-faq_5.html#SEC165

...which says that Emacs 19 doesn't support background images, but
XEmacs does. A generated background pixmap would seem to be a reasonable
way to get that kind of diagram... Not perfect, but a decent proof of
concept.

> - John

-Wm