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

Le Mon, 2 Mar 2009 16:23:15 -0500,
John Nowak <[email protected]> s'exprima ainsi:

> On Mar 2, 2009, at 3:19 PM, spir wrote:
> 
> > I intuitively understand "concatenative" as meaning "constructive"  
> > in the sense of "brick programming". This is what I have always  
> > looked for, probably. Still, I do not really get why some languages  
> > may be so qualified; why most languages do not have this property.
> 
> The Wikipedia article was completely changed a few days ago and now  
> gives a (mostly) good definition of what qualifies; I'd start there:
> http://en.wikipedia.org/wiki/Concatenative_programming_language

Thank you for your extensive reply.
I have read this page numerous times ;-)

> > In stack based langugages,
> > :W 1
> > actually means "push 1 (whatever it actually is) on top of the stack".
> > In a "real" OO language (based on messaged passing, such as usually  
> > done in prototypes languages like Io), a reference to a data slot  
> > actually calls a data accessor.
> > Is this analog to "pushing on the stack" ?
> 
> I'm not sure what you mean exactly, but I think the answer is probably  
> no.

What I mean is (letting aside the notion of object to which a message are sent -- say that there a unique global object or talk of plain functions).

:plus <whatever> ;
:plus1 1 plus ;

Can we say that the code above is equivalent to:

func plus(a,b)
	<whatever>
func plus1(n)
	plus(n, 1)

or more explicitely:


:plus <whatever> push;	# 'push' means push result on the stack
:plus1 1 push plus ;	# result already on the stack

func plus(a,b)
	<whatever>
	resturn result
func plus1(n)
	# equivalent to pushing 'data'?
	x := n
	y := 1
	# then only call other func
	plus(x, y)

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.

> > This leads me to wonder whether concatenation is related to  
> > referential transparency.
> 
> In Joy, most functions are referentially transparent. Depending on how  
> you look at it, you might even say that all functions are  
> referentially transparent because the compositional nature of the code  
> makes it possible to thread a single invisible state throughout the  
> entire program. Some degree of hand-waving is required however.
[...]
> > 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 depends on the language. For example, all data is persistent in  
> Joy; only IO will cause a visible side effect. In a language like  
> Factor, much data is not persistent.

> > Are purely functional languages necessarily, logically, concatenative?
> 
> Not at all. Haskell is purely functional (i.e. there are *no* side  
> effects), but not concatenative.

Still unclear for me. (good, I have unknown worlds to explore ;-)

> > 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.

> > Is there a way to accord concatenation and basic OO? Or are these  
> > approaches -- as I suspect -- definitely incompatible?
> 
> They're not incompatible. Many Forths have objects, Factor has  
> objects, and I believe there was talk of adding a prototype-based  
> object system to Cat at one point as well. If you want to reimplement  
> Io in Factor, you'd be more than able to. I'd encourage you to try the  
> existing system first though and see what you think.

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...

> - John

Thank you again,
Denis
------
la vita e estrany