Re: [stack] the concatenative wikipedia article
- John Nowak <john@...> wrote:
> The Wikipedia article on concatenative languages has a number ofI'd like to see that. For some reason I've never felt adequate to
> 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.
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 haveAgreed entirely.
> already shown that the counter-examples are beyond mere curiosities.
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 areThis is a very big point, and should be strongly emphasized.
> not applicative. The reduction of a concatenative expression is the
> 3. There is no reason concatenative languages must use a postfixTechnically it's not prefix or postfix; it's beginning-to-end or
> 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
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
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
> 4. Not all concatenative languages have parsing words or an equivalentGranted. I'd be okay with removing this... Although Forth (for
> to macros. Talking about them here makes as much sense as talking
> about macros on a page about applicative programming.
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-Okay, that's good. I'd worry a little about the expression "objects
> 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.
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 universallyI agree... I suspect this is one of Wikipedia's famous controversy
> accepted as a particularly useful term". It's an objectively useful
> term if some care is given to its definition;
edits. It doesn't fit well with the rest of the page, and it serves no
> So, should I make the changes or should I just define a new term so II'd like the changes made -- it would be nice to have an encyclopedic
> 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.
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
- On Jan 13, 2009, at 7:29 AM, pml060912 wrote:
> Well, where does Furphy fit in this breakdown?Interesting!
> Although it does have quotation, as I mentioned elsewhere that's just
> syntactic sugar. The fundamental constructs are Reverse Polish naming
> and concatenation, which can use the complementary keywords FREEZE and
> THAW to defer and invoke evaluation/execution - and those can be built
> from the return stack manipulation keywords R> and >R already found in
> Forth. That looks fairly associative/flat to me.
Here are the semantics I'd use (in a more Joy-like, single-stack
freeze F -> [F] F
F [G] thaw -> G
This is the first time I've had a rewrite rule with a "row" on the
*right* side of the function.
What 'freeze' would basically do is take the rest of the program and
return a new program that is prefixed with a quoted version of itself.
What 'thaw' would do is take a program 'F' with a quotation '[G]' on
top and return the new program 'G'. This seems like something that
could be added to a Joy-like language very simply (excepting that
pesky "implementation" part).
This sounds a lot like XY: