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

John Nowak <[email protected]>
Newsgroups gmane.comp.lang.concatenative
Message-ID <[email protected]>
On Feb 18, 2009, at 3:07 AM, Don Groves wrote:

> Then the teacher says to repeat the problem with the object sitting

> on the floor next to the teacher's desk. The only acceptable answer
> is to pick up the object and place it on the desk -- the rest of the
> problem is already solved!
>
> Now, while this method of problem solving can be used in any
> programming language, concatenative languages are built upon
> this foundation. So, concatenative languages enable a programmer
> to use provably-correct formal methods by their very nature.

Interesting point. Two questions:

1) How much of this is due to the "flatness" of concatenative  
languages? In a flat concatenative language, it's as easy as it could  
possibly be to concatenate, splice, and otherwise manipulate programs.  
Nothing gets in your way.

2) If flatness helps, do first class quotations make things more  
difficult? Instead of being able to split at any point, quotations  
mean that you can only split within a certain context. I'm assuming  
the answer here is "yes", but I've not attempted to show this yet.

If a large part of what makes concatenative languages well-suited to  
formal methods is their flat nature, then that would be a strong  
argument for the stack as the proper datatype for a concatenative  
language. My experiments with other datatypes have all resulted in a  
much more "nested" language with many additional functional forms.  
William has correctly remarked that they don't even "feel"  
concatenative.

If first class quotations make things more difficult, then that would  
be a strong argument for trying the second order approach I've  
described previously; it keeps most of the benefits of the higher  
order approach while offering a trivial translation to a first order  
(i.e. "flat") program.

- John
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.