Re: [stack] Comments on Trade-Offs in Systems of Notation/Programming Languages

I'm not going to get the time for a while to address this properly and
in full, but I think it provides (and the other documents posted
provide) really valuable instigations to discussion on this list.

Thank you.

cpcogan <[email protected]> wrote:
> It's the LAW:
> Whenever a programming language is developed that eliminates the need
> for some conventional programming construct, that programming language
> will have partially compensating complexity in some other aspect of
> its use, thus somewhat reducing the value of the new language.

That's quite pragmatic and reasonable.

> In the case of old-time Lisp, for example, we get a simplification of
> syntax at the cost of a proliferation of parenthetical expressions
> that can get pretty confusing (and further complexities from its
> applicative nature). In older Forths (if not newer ones), we get stack
> manipulation activities, two-step retrieval of variable values (where
> the address of a value is first pushed in one step and then used to
> retrieve the actual data in another step).

Careful. The two-step retrieval isn't an attribute of Forth's
notation; it's a result of the fact that the only provision for
variables was naming a chunk of memory inside the dictionary. It's
easy to code alternate implementations of global variables (a common
name is VALUE), and the ANSI standard makes it possible to code
locals.

But otherwise, great examples.

The Forth example hits this discussion group on the head. Pardon the
painfully mixed clich\'e.

The stack shuffling problem is a fundamental attribute of stack-based
concatenative languages; in a more general sense, the problem is that
dataflow languages must explicitly express their dataflow, while
lambda-based languages can keep dataflow hidden.

> The real trick is to find those systems of notation that, for their
> purposes, offer the best choices in what is given up and what is
> gained by each choice. This is made complicated by the fact that the
> different aspects of a system of notation have to fit together, with
> the result that a way of adding a feature to one system may not work
> in another.

I can't delete this... I have to add "<aol>Me too!</aol>".

It's made still more complex by the fact that in general you're not
usually "giving up" a pure quality that the other language possesses;
rather, you're reducing a quantity of one thing in return for a
quantity of a qualitatively different thing. And, of course, you're
almost never trading one for one; usually there are several things to
give up and/or gain.

> almost instantly). (Unfortunately, Spencer-Brown's book on his
> calculus is marred by bad philosophizing and by having most of the
> book written in a compact but cryptic style, so it takes a while to
> "get" what he's done and why it's of value, but there are
> more-accessible introductions now available online.)

Where would you recommend going for an intro? Stevan's page on the
subject was interesting (although "compact but cryptic"), but I want
more. The PDF you linked to seems like a decent conceptual start, but
lacks depth and application (as far as I could see).

> bracketed code in this way in the 1970's but almost COMPLETELY missed
> most of the importance of it, because I was still thinking of the
> language I was designing as a variant of Forth with a stricter
> adherence to an "RPN" style (no explicit loops, etc.).

I made a similar error in my understanding of Forth as well (although
mine wasn't as creative); it's easy to do when you think of Forth as
"postfix" rather than dataflow RPN.

>        http://www.boundarymath.org/papers/BLogic-intro.pdf

Noted, skimmed, and saved.

> (e.g., the set-inclusion paradoxes and the liar's paradox, etc.). My
> own more-philosophical way of dealing with the paradoxes (along with

We may have to take this particular part offline, unless you've got a
webpage... But I want to hear more. Imaginary truth values... Very
interesting.

-Billy