Re: [stack] Jon Purdy: Why Concatenative Programming Matters

John Nowak <[email protected]> wrote:
> I think the second most interesting thing is that all functions
> operate on possibly empty sequences containing arbitrary amounts
> of program state. It's this "all the state" element that gives
> concatenative languages their character.

Indeed. And you're right when you elsewhere say that this gives
concatenative languages an imperative character.

You're right that any arbitrary function must be able to access all of
the state; but it need not be true that any specific function must be
able to access all the state. Modern concatenative languages use
typechecking to make sure that no function attempts to consume stack
state that doesn't match the function's declaration; but other types
of checking don't have such an obvious typechecking solution. (Were
you the one who designed a concatenative language with side-effect
checking?)

It seems obvious to me that in order to add effect checking, you have
to formally define the effect. Forth's dictionary could be formally
defined and checking there from implemented.

Of course, this is easier to say than to do, and I haven't even said it.

I also admit that by saying this, I have conceded your point. This has
the result of making reordering hard.

> This is very different from concatenative languages where
> combinators like 'bi@' allow the functions provided to step on
> each other as the second function runs on top of the stack
> returned from the first. This is the reason I gave up on
> concatenative languages; the equational reasoning possible when
> all functions operate on "the stack" just isn't great. I think

That specific example need not retain all of its problems, obviously
-- you can define similar combinators to require the forks to have
identical static types, and then effectively isolate the forks from
each other. Factor chooses not to do that, and thereby adds semantics
which are useful for its purposes.

> (as with Joy's 'infra'), is *really important*. While this fact
> is arguably implicit in the definition on Wikipedia, it's not
> spelled out at all. Maybe I can add some insight to it in the
> next few days.

Fair point. We await your input. Fthagn.

> - jn

-Wm