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

On Feb 16, 2009, at 5:49 AM, John Nowak wrote:

>
> On Feb 16, 2009, at 8:17 AM, chris glur wrote:
>
>> What the point of it all ?!

To John's excellent summary below, I would add only one thing,
which he gets close to but doesn't say explicitly, and that is that
the primary aim of formal methods is to demonstrate program
correctness. If they can also make programs easier to read and
make programmers more productive by some metric, such as
working volume of code per programmer hour, that is icing on
the cake.

But the cake is a provably correct program, or at least the ability
to demonstrate that the code is transformationally correct, i.e., if
it is correct at some point, then it is correct at any later point.
Concatenative methods appeal to me as the best path toward
this goal.

Also, it takes some time using a concatenative language before
you see the productively gains in your own work. I'll just say that
in my nearly 40 years of programming, Forth was clearly the most
productive language I used (in terms of that metric above).
--
don


>> 1. The formal methods you mention are certainly a big element. The
> pointfree, concatenative nature of the code makes it very easily to
> manipulate programs. This property has not been taken advantage of  
> yet.
>
> 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.
>
> 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.
>
> 4. Concatenative languages can be considerably simpler than their
> typical applicative counterparts. Throw out all your binding forms,
> precedence rules, scoping rules, etc.
>
> Other people undoubtedly have other interests.
>
>> I recently investigated gforth
>
> Gforth probably isn't what you want to be looking at. Factor is a
> better bet, although it isn't currently capitalizing on the formal
> methods you're talking about.
>
>> [advantages of] knowing that language X can be viewed as a sequence
>> of [transformations] of stacks?
>
> It certainly makes it easy to move state through your program. This is
> what enables the linear implementation I mentioned previously.
> Similarly, it could make dealing with uniqueness types quite
> comfortable.
>
> 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 +
>
> 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)'.)
>
> - John
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>