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