Re: [stack] the concatenative wikipedia article

John Nowak <[email protected]>
Newsgroups gmane.comp.lang.concatenative
Message-ID <[email protected]>
On Dec 31, 2008, at 10:48 PM, Christopher Diggins wrote:

> I just posted my newest definition of concatenative language at
> http://dobbscodetalk.com/index.php?option=com_myblog&show=What-is-a-Concatenative-Language.html&Itemid=29

Well lets see. Starting with your definition:

"A concatenative programming language is language in which terms  
correspond to functions and in which the juxtaposition of terms  
denotes the composition of functions."

The phrase "terms correspond to functions" is critical and I'm glad to  
see you're included it. What you don't mention is that the language is  
non-applicative. This is essentially a requirement of all terms being  
functions, but perhaps you could cram it in there.

Here it is again with a few small changes:

"A concatenative programming language is A NON-APPLICATIVE language in  
which ALL terms correspond to functions and in which the juxtaposition  
of terms denotes the composition of functions."

I'm fine with this. It doesn't admit some things I'm working on, but  
that's more than fine. The very term "concatenative" essentially  
requires that concatenation mean something, and function composition  
seems like the most likely choice. Yes, you could write a  
concatenative-like language where '.' denoted composition, but why  
would you? Narrowing the syntactic aspect of the definition without  
restricting things that are possibly useful makes it easier to give  
examples, state rules, etc. So yes, requiring juxtaposition mean  
composition is fine.

Your definition doesn't mention quotation. I think this is a good  
thing as Forth doesn't have it. It also leaves open the possibility  
for other forms like construction, conditional (as in Forth), etc.

In short, you seem to have captured the essentials. I like it,  
although I like it more with the non-applicative nature stressed.

I do have a question though. What about a language that allows  
definition of this form:

    dup drop => id

I think the answer is no because the terms denote *terms*, but I'd  
like your answer anyway.

As for the remainder of your article, I completely disagree with this:

"In practical terms a concatenative language is not really different  
from a functional language..."

If we consider Haskell a "functional language", then I think  
concatenative languages are very different both in practical and  
theoretical terms. Of course, it's not necessarily clear what you mean  
by "functional" (which is another horribly abused term).

- John
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.