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