Re: [stack] disallowing recursive definitions

zallambo <[email protected]> wrote:
>  If code isn't readable without stack diagrams, comments seem like a
>  poor fix.

Indeed. But this isn't relevant to the discussion. Code is unreadable
for many reasons. We were originally talking about a specific cause of
unreadability which appears to apply exclusively to applicative
languages -- now people have started complaining that concatenative
languages are universally unreadable, which is not backed up by the
arguments being presented.

> Rather, there should be a way to make the code itself more
>  transparent. I think lambda expressions are a good replacement for
>  stack diagrams. They make the stack explicit and are often easier to
>  read. Compare:

Lambda expressions are an excellent tool, but they do not replace or
augment stack diagrams; the purposes are simply different.

>  #x y u v -- (x*u - y*v) (x*v + y*u)
>  dup4 [swap] dip * bury * swap - bury * bury * +
>  [x y u v] [x u * y v * - x v * y u * +] lambda
>  A mistake would be much easier to notice in the latter than the
>  former.

A mistake in either one is a programming error, which can be
arbitrarily hard to find. In this particular case, lambda is
objectively better than raw stack notation, and a mathematical
domain-specific-language would be even better (one should use the
simplest thing that will work, of course); but in general, errors in
lambdas are as hard to find as errors in stack notation; they can be
worse in some situations because in a stack language, lambda
expressions mix up and permit confusion between the two ways of
getting parameters to the functions.

Again, lambdas are useful, but in my experience they're mainly used
where a math-like expression is desired -- in other words, it would be
even more useful for the language to provide a math DSL.

> Not being able to keep track of the stack in one's head can be
> a serious problem.

Indeed. Guess what my answer is to that problem?

1. Learn better to keep track of the stack in your head;
2. Write code that's easier to track.

Both will only come with practice.

>  -Justin

-Wm