Re: [stack] the concatenative wikipedia article

"William Tanksley, Jr" <[email protected]>
Newsgroups gmane.comp.lang.concatenative
Message-ID <[email protected]>
John Nowak <[email protected]> wrote:
> The Wikipedia article on concatenative languages has a number of
> issues that I think should be addressed. I'm willing to make the
> changes, but I'd like to make sure I'm not off-base first.

I'd like to see that. For some reason I've never felt adequate to
munge the page...

> Here are my issues with the article:

The number one problem is the motivation for the definition. As given,
it sounds like a mathematical or historical curiosity.

> 1. Concatenative should not be conflated with "stack-based". I have
> already shown that the counter-examples are beyond mere curiosities.

Agreed entirely.

I'd like to see your examples, specifically emphasizing how you know
it's concatenative. I didn't notice them.

> 2. It should be more clearly stressed that concatenative languages are
> not applicative. The reduction of a concatenative expression is the

This is a very big point, and should be strongly emphasized.

> 3. There is no reason concatenative languages must use a postfix
> syntax. A prefix syntax is also a valid approach. Other syntaxes are
> useful (as I've shown recently with my infix construction syntax
> similar to that of in FL and J) but ruled out by the need for
> concatenation to always denote composition (which I think is probably
> unfortunate).

Technically it's not prefix or postfix; it's beginning-to-end or
end-to-beginning. I really don't see any utility in the latter.

It can also be ruled out by the use of other definitions for
concatenativity -- I really like the one we arrived at a year ago.
Here are a couple of (hopefully) alternative phrasings (that is,
they're intended to imply the same things):

1. For the mathematically oriented: "A concatenative language consists
of a mapping from a syntactic monoid over program concatenation to a
semantic monoid over an associative operation on functions." This
language is motivated by von Thun's "Mathematical Foundations of Joy",
http://www.latrobe.edu.au/philosophy/phimvt/joy/j02maf.html (but I'm
to blame for applying it here, so don't shoot at Manfred if I've got
it wrong).
2. A simple definition: "A concatenative language is a programming
language where the syntactic concatenation of terms expresses an
associative operation on the functions that the terms represent." This
was built by Christopher Diggins.
3. Purely language-theoretical: "A language's syntax is concatenative
if it is its own Kleene closure."

My favorite is #2. I'd really want to call out the advantages granted
by associativity; I think that's the single biggest thing experienced
concatenative programmers enjoy, even if they never know to name it.
It's the property that allows one to refactor merely using cut and
paste.

> 4. Not all concatenative languages have parsing words or an equivalent
> to macros. Talking about them here makes as much sense as talking
> about macros on a page about applicative programming.

Granted. I'd be okay with removing this... Although Forth (for
example) has a very simple and powerful macro system, it's interesting
that its creator recommends that it be entirely avoided. The theory of
macros on top of a concatenative language is simple and clear, but is
really a different issue.

> 5. It should be stressed that concatenative languages are function-
> level and pointfree. They also go beyond languages like Backus's FP in
> that objects are entirely removed from the language; The expression
> '3' represents a *function*, not an object.

Okay, that's good. I'd worry a little about the expression "objects
are entirely removed"... There's an obvious way to entirely
misunderstand that. The terminology in the Wikipedia definition of
"function-level" suggests that perhaps you should say something along
the lines of "the distinction between data and functions is entirely
removed from the language, and all functions are built up from other
functions, with constant functions standing in for data."

> 6. I dislike the sentence "The term 'concatenative' is not universally
> accepted as a particularly useful term". It's an objectively useful
> term if some care is given to its definition;

I agree... I suspect this is one of Wikipedia's famous controversy
edits. It doesn't fit well with the rest of the page, and it serves no
purpose.

> So, should I make the changes or should I just define a new term so I
> that can communicate with people without boring myself? I did like
> Diggins's "compositional" suggestion which is more to the point; The
> fact that it is already used in various vague ways doesn't disturb me
> too much.

I'd like the changes made -- it would be nice to have an encyclopedic
reference for this list's discussions. I'd rather not branch to
another term; I think "concatenative" is well-established and
fruitful, even if it is a bit vague. (But what isn't vague?)

> - John

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