Re: [stack] Re: the concatenative wikipedia article

On Dec 31, 2008, at 6:54 PM, Don Groves wrote:

> I was leaning toward defining a concatenative (if that's the right
> word) program as "a list of operators applied to a (possibly initially
> empty) list of operands."

I don't think this is a satisfactory definition for a few reason:

1. What exactly is a "list of operators"? Do you mean a sequence of  
functions reified as a list of objects? I don't think that's necessary.
2. For me, the main advantage of a concatenative language is that you  
get rid of application. Manfred von Thun pointed this out in his "Joy  
compared with other functional languages" paper and I think it is  
critical to the definition of concatenative languages.
3. There's no reason that the data structure the functions operate on  
be a list or a stack. I recently proposed a language using vectors in  
the style of More's array theory. Earlier today, Chris proposed a  
language based on a deque. I believe XY works on a stack/queue tuple.  
Other possibilities are easy to dream up.

> the order of application is not specified.

This would depend on the language in question. Various evaluation  
strategies can be employed. In a language with side effects, the order  
of reduction is going to be important. One could even imagine a  
language with a term rewriting semantics that allows definitions of  
the form 'dup drop  -> id'. If your rewrite rules aren't confluent,  
the way in which you reduce will matter.

- John