Re: [stack] What does "concatenative" actually mean?

spir wrote:
> John Nowak <[email protected]> s'exprima ainsi:
> Can we say that the code above is equivalent to:
> I wonder if the functional way and the stack way are equivalent
> manners of defining code snippets -- that use variables in the math
> sense of "unpredictable values" (at design time) -- that are secure;
> meaning that they will perform a fully defined action and/or are
> concatenatable as code bricks.

The best way to say that kind of thing -- assuming that I understand
what you're asking for -- is to provide a constructive method to
transform one representation into another. Nowak pointed you at Kerby's
web page earlier; that includes an algorithm to convert lambda notation
into stack notation, thus proving that the two are equivalent (assuming
that you have a complete basis in both).

> > > This leads me to wonder whether concatenation is related to  
> > > referential transparency.
> > > What lets me uneasy with this point of view is that
> "concatenative"  
> > > is not supposed to be a synonym of "purely functional". Or what?

It's not. Joy attempts to be a partially pure functional language that's
purely concatenative; Cat and 5th try much harder to be functionally
pure. My little toy language achieves complete functional purity by the
expedient mechanism of being completely useless for any practical
purpose.

But Forth and Postscript are (reasonably) concatenative, and are not
functionally pure at all.

"Concatenative" and "functional" are two completely different adjectives
that can be applied completely independently. The only thing they share
in common is that both allow you to make mathematical statements about
your code -- and if your language is "pure" enough, those statements
help you reason about your code.

> > > I wonder about the practical usefulness of the concatenative  
> > > propertie(s).
> > They're useful. Tons of code is written in Forth. 
> I expressed myself unclearly.

To me, the most useful property is that concatenative code is fully
associative. This implies that you can group concatenative code in any
way that's convenient for you. If you're reading the code, you can "give
up" on a complex section of code and skip ahead to try to make sense of
a later section; what you discover will be correct no matter what the
earlier section actually meant. If you're writing or refactoring the
code, it means that you can "physically" group the code any way you
want: just cut any section out, replace it with a new function name, and
paste the old section into the definition of the new function.

One mathematical property, two uses.

> This is something I really do not understand. In many OO languages,
> especially prototype-based ones, objects are simple map/dict like
> variables. They can be refered to from inside any word/func/'action';
> so as I understand the point they act, at least can act, as global
> state, environment, variables that will necessarily break the
> (referential) "safety" of the function. Meaning that they have
> unpredictable effect/result. How can one then simply combine such
> functions as code bricks -- which is how I understand concatenativity?
> There must be something my brain is unable to catch...

The truly pure functional languages, like Haskell, have a mathematical
model for state-changing effects, like objects and I/O. The problem is
that purely functional languages don't express what order their
operations will occur in; they just tell the computer what operations to
do, and let the compiler figure out the best order. So Haskell provides
a mathematical construct called a "monad". Monads can mathematically
only be evaluated in order, so the compiler receives enough information
to know what order to execute your code in.

Concatenative languages use a stack (or something like that), and as a
result they already have a monad built into them. If you do something
that's functionally unsafe (stateful) you're still concatenatively safe,
so your associative property still applies.

(However, state-free concatenative languages DO have some nice
additional properties.)

> Denis

-Wm