Loading ...
Sorry, an error occurred while loading the content.

Re: [stack] the concatenative wikipedia article

Expand Messages
  • William Tanksley, Jr
    ... I d like to see that. For some reason I ve never felt adequate to munge the page... ... The number one problem is the motivation for the definition. As
    Message 1 of 48 , Dec 31, 2008
    • 0 Attachment
      John Nowak <john@...> 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

      > 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

      > 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

    • John Nowak
      ... Interesting! Here are the semantics I d use (in a more Joy-like, single-stack context): freeze F - [F] F F [G] thaw - G This is the first time I ve had a
      Message 48 of 48 , Jan 15, 2009
      • 0 Attachment
        On Jan 13, 2009, at 7:29 AM, pml060912 wrote:

        > Well, where does Furphy fit in this breakdown?
        > (http://users.beagle.com.au/peterl/furphy.html)
        > 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:

        - John
      Your message has been successfully submitted and would be delivered to recipients shortly.