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