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

John Nowak wrote:
> 2. Stack-based concatenative languages are well-suited to a linear  
> implementation; see Henry Baker's "The Forth Shall Be First" paper. I  
> may, however, be the only one interested in this.

You are not the only one; I've been interested in that since I read it,
way back in the mists of memory.

> 3. First-order stack-based languages are well-suited to a graphical  
> representation once you apply a type discipline. This would mesh very  
> well with a linear implementation.

I agree, although "type discipline" isn't as strictly important as
static stack effects.

It would be very interesting, also, to consider a few different ideas:

1. A graphical architectural mode for a concatenative language: would
answer questions about which modules can be used by which other ones,
which modules are sources/sinks/transformers, for which other ones...
Can analyze source code for violations, or produce an architectural
diagram from source code.

2. A graphical presentation for a concatenative language: read in source
code, show various diagrams.

3. A graphical augmentation for a concatenative language: while editing
source code, show arrows that point back to where data comes from and
forward to where it's being consumed. (Can Emacs do this kind of thing?)

#3 would be especially useful while editing normal text, I would think.
One wouldn't use that in an applicative language (where simply
colorcoding the variable names is sufficient), but it'd be nice in an
applicative language.

#2 could be a different way to program, and could help with security
analysis.

> The syntax also makes algebraic rules for a concatenative language  
> very simple. For example, you can express the distributivity of  
> multiplication nicely without the need for infix operators:
>     A B + C *  ==  A C * B C * +  ==  [*] papply bi +

That's good! I'd say that it would be good exercise to always start and
end without variables... So that little derivation could be written:

  + swap * == A B + C * == A C * B C * + == [*] papply bi +

(I'm not assuming commutativity of multiplication here.)

As for commutativity...

 swap + == +

Well, that's TOO easy.

> You can also manipulate programs easily by prefixing them or suffixing  
> them. For example, if some program 'A' equals some program 'B', then  
> program 'F A' equals program 'F B' for any program 'F'. There is no  
> real equivalent for this prefixing rule in most programming languages.  
> (The suffixing rule is easy to translate though, e.g. 'A' -> 'A F' is  
> roughly the same thing as 'a' -> 'f(a)'.)

That works well for applicative statements, but not so well for programs or expressions.

> - John

-Wm