# the concatenative wikipedia article

## John Nowak — 2008-12-31 05:27:10

    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 realize many of these concerns are rather tired at this point. I

    apologize. However, that doesn't change the fact that they've gone

    unresolved. Indeed, there seems to be almost a resistance to resolving

    them. I personally think that the non-applicative style of programming

    has important properties and that it would be great to have a term for

    them so I could stop redefining "concatenative" every time I talk to

    someone (including those knowledgeable about concatenative languages).

    Here are my issues with the article:

    1. Concatenative should not be conflated with "stack-based". I have

    already shown that the counter-examples are beyond mere curiosities.

    2. It should be more clearly stressed that concatenative languages are

    not applicative. The reduction of a concatenative expression is the

    simplification of one function to another function (e.g. '1 2 + + ==>

    3 +'). Never is it necessary to deal with objects or application, and

    much is gained by not doing so (as is mentioned at http://www.latrobe.edu.au/philosophy/phimvt/joy/j08cnt.htm)

    .

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

    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.

    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.

    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; What's "universally

    accepted" is unimportant. Hell, even Slava (who says it's unimportant)

    has started concatenative.org (which lists C++ and Java as

    "interesting languages"... ugh).

    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.

    Sorry for bringing this up *again*, but I'm trying to write a paper

    and keep stumbling over how to describe what it is that I'm talking

    about.

    - John

## William Tanksley, Jr — 2008-12-31 17:07:49

    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

    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

## Christopher Diggins — 2008-12-31 19:34:16

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

     Allow me to present the deque language that I just made up.

    1! - Pushes a one to the right of the deque

    !1 - Pushes a one to the leftt of the deque

    ...

    add! - Adds the right two numbers of the deque

    !add - Adds the left two numbers of the deque

    ...

    3! !5 !2 sub! !add

    If applied to an empty deque this will leave the value 4 on the deque.

    So is this a concatenative language? It satisfies many of the

    criteria, but I am not sure. If we could agree that this is or is not

    concatenative, it may prove useful.

     >> 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?)

     Agreed, I think there is value in refining the term concatenative.

    However, I think it is more important to define it here than somewhere

    else like a wiki where people with no knowledge of the subject can

    make arbitrary uninformed edits. Besides whatever is agreed upon in

    the list can serve as a source of citation for the Wikipedia article.

    - Christopher

## William Tanksley, Jr — 2008-12-31 20:21:53

    Christopher Diggins <cdiggins@...> wrote:

     >>> 1. Concatenative should not be conflated with "stack-based". I have

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

    > Allow me to present the deque language that I just made up.

    > 1! - Pushes a one to the right of the deque

    > !1 - Pushes a one to the leftt of the deque

    > add! - Adds the right two numbers of the deque

    > !add - Adds the left two numbers of the deque

    > ...

    > 3! !5 !2 sub! !add

    > If applied to an empty deque this will leave the value 4 on the deque.

    > So is this a concatenative language? It satisfies many of the

    > criteria, but I am not sure. If we could agree that this is or is not

    > concatenative, it may prove useful.

     By all three of the definitions I posted, as well as the Wikipedia one

    (stripped of its parochial insistence on stacks), this qualifies. As a

    bonus, my gut feeling is that it's concatenative. It's definitely more

    complex than working with a stack, but there's nothing inherently

    wrong about that -- and perhaps there's a data structure that's

    inherently simpler than a stack.

    OTOH, can a concatenative language ever be infix? I'd find it odd... A

    fundamental property is syntactic associativity, and infix isn't

    associative... Or can it be made so by means of currying?

     > Agreed, I think there is value in refining the term concatenative.

    > However, I think it is more important to define it here than somewhere

    > else like a wiki where people with no knowledge of the subject can

    > make arbitrary uninformed edits. Besides whatever is agreed upon in

    > the list can serve as a source of citation for the Wikipedia article.

     Granted, but a mailing list is ephemeral.

     > - Christopher

     -Wm

## John Nowak — 2008-12-31 22:49:40

    On Dec 31, 2008, at 3:21 PM, William Tanksley, Jr wrote:

     > OTOH, can a concatenative language ever be infix? I'd find it odd...

     The general idea that I've had for a prefix/infix language is as

    follows:

    1. 'f g' denotes the composition of 'f' and 'g'

    2. 'f g h' denotes the composition of 'g' with the construction of 'f'

    and 'h' (construction is basically a cleave combinator)

    3. Grouping is to the right such that 'f g h i j k == f g (h i (j k))'

    4. Composition is associative such that '(f g) h == f (g h)'

    5. Literals (e.g. '42') are constant functions such that '42 f == 42'

    6. Multiple arguments are passed via lists

    7. 'a == head', 'b == head tail', 'c == head (head tail)', etc --

    these are essentially used to index into lists

    As such, you write functions like this:

        discriminant = (sq b) - 4 * a * c

    And here's the definition in use

        # composition of discriminant and the construction [1,3,-4]

        discriminant [1,3,-4]

        # expansion of discriminant

        ((sq b) - 4 * a * c) [1,3,-4]

        # fully parenthesized

        ((sq b) - (4 * (a * c))) [1,3,-4]

        # replacing infix with composition + construction

        (- [sq b, * [4, * [a, c]]) [1,3,-4]

        # law of associativity: (f g) h == f (g h)

        - ([sq b, * [4, * [a, c]]) [1,3,-4])

        # law of distributivity: [f0..fN] g == [f0 g..fN g]

        - [(sq b) [1,3,-4], * [4 [1,3,-4], (* [a, c]) [1,3,-4]]

        # simplification

        - [(sq b) [1,3,-4], * [4, (* [a, c]) [1,3,-4]]

        - [(sq b) [1,3,-4], * [4, * [1, -4]]

        - [sq (b [1,3,-4]), * [4, * [1, -4]]

        - [sq 3, * [4, * [1, -4]]

        - [sq 3, * [4, -4]]

        - [sq 3, -16]

        - [9, -16]

        25

    The infix syntax makes the manipulation a little awkward, but I've

    found it often makes the definitions shorter and more readable. The

    fact that any function can be used infix is a nice touch.

    So, is this concatenative? It's just composition and cleave combinators.

    - John

## Adam — 2008-12-31 23:01:37

    Slava recently created a nice description of Concatenative languages

    in the following four articles:

    http://www.concatenative.org/wiki/view/Concatenative%20language

    http://www.concatenative.org/wiki/view/Concatenative%20language/Name%20code%20not%20values

    http://www.concatenative.org/wiki/view/Concatenative%20language/Multiple%20return%20values

    http://www.concatenative.org/wiki/view/Concatenative%20language/Concatenation%20is%20composition

    -Adam

     --- In concatenative@yahoogroups.com, 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 realize many of these concerns are rather tired at this point. I

    > apologize. However, that doesn't change the fact that they've gone

    > unresolved. Indeed, there seems to be almost a resistance to resolving

    > them. I personally think that the non-applicative style of programming

    > has important properties and that it would be great to have a term for

    > them so I could stop redefining "concatenative" every time I talk to

    > someone (including those knowledgeable about concatenative languages).

    >

    > Here are my issues with the article:

    >

    > 1. Concatenative should not be conflated with "stack-based". I have

    > already shown that the counter-examples are beyond mere curiosities.

    >

    > 2. It should be more clearly stressed that concatenative languages are

    > not applicative. The reduction of a concatenative expression is the

    > simplification of one function to another function (e.g. '1 2 + + ==>

    > 3 +'). Never is it necessary to deal with objects or application, and

    > much is gained by not doing so (as is mentioned at http://www.latrobe.edu.au/philosophy/phimvt/joy/j08cnt.htm)

    > .

    >

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

    >

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

    >

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

    >

    > 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; What's "universally

    > accepted" is unimportant. Hell, even Slava (who says it's unimportant)

    > has started concatenative.org (which lists C++ and Java as

    > "interesting languages"... ugh).

    >

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

    >

    > Sorry for bringing this up *again*, but I'm trying to write a paper

    > and keep stumbling over how to describe what it is that I'm talking

    > about.

    >

    > - John

    >

## Adam — 2008-12-31 23:12:00

    Also, concatenative.org is editable by the public as well if you register.

     --- In concatenative@yahoogroups.com, Adam <hiatoms@...> wrote:

    >

    > Slava recently created a nice description of Concatenative languages

    > in the following four articles:

    >

    > http://www.concatenative.org/wiki/view/Concatenative%20language

    >

    >

    http://www.concatenative.org/wiki/view/Concatenative%20language/Name%20code%20not%20values

    >

    >

    http://www.concatenative.org/wiki/view/Concatenative%20language/Multiple%20return%20values

    >

    >

    http://www.concatenative.org/wiki/view/Concatenative%20language/Concatenation%20is%20composition

    >

    > -Adam

    >

    > --- In concatenative@yahoogroups.com, 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 realize many of these concerns are rather tired at this point. I

    > > apologize. However, that doesn't change the fact that they've gone

    > > unresolved. Indeed, there seems to be almost a resistance to resolving

    > > them. I personally think that the non-applicative style of programming

    > > has important properties and that it would be great to have a term for

    > > them so I could stop redefining "concatenative" every time I talk to

    > > someone (including those knowledgeable about concatenative languages).

    > >

    > > Here are my issues with the article:

    > >

    > > 1. Concatenative should not be conflated with "stack-based". I have

    > > already shown that the counter-examples are beyond mere curiosities.

    > >

    > > 2. It should be more clearly stressed that concatenative languages are

    > > not applicative. The reduction of a concatenative expression is the

    > > simplification of one function to another function (e.g. '1 2 + + ==>

    > > 3 +'). Never is it necessary to deal with objects or application, and

    > > much is gained by not doing so (as is mentioned at

    http://www.latrobe.edu.au/philosophy/phimvt/joy/j08cnt.htm)

    > > .

    > >

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

    > >

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

    > >

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

    > >

    > > 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; What's "universally

    > > accepted" is unimportant. Hell, even Slava (who says it's unimportant)

    > > has started concatenative.org (which lists C++ and Java as

    > > "interesting languages"... ugh).

    > >

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

    > >

    > > Sorry for bringing this up *again*, but I'm trying to write a paper

    > > and keep stumbling over how to describe what it is that I'm talking

    > > about.

    > >

    > > - John

    > >

    >

## John Nowak — 2008-12-31 23:25:51

    On Dec 31, 2008, at 6:01 PM, Adam wrote:

     > Slava recently created a nice description of Concatenative languages

    > in the following four articles

     Thanks, I had hadn't seen that before.

    Slava's description seems decent enough. It is, however, stack-

    focused. He says that concatenative languages and stack-based

    languages are similar, but then never clarifies the differences and

    goes on to conflate the two. I also have some minor niggles (in no

    particular order):

    1. There's no reason a concatenative language has to support

    recursion. My initial version of 5th did not.

    2. Not all concatenative languages have multiple programmer-accessible

    stacks. Forth and Factor do, Joy and Cat do not.

    3. It isn't mentioned that the reduction of a function the

    transformation of one function to another. This is the critical thing

    I find lacking in FP and FL.

    4. It says composition must be denoted by concatenation. I'd prefer to

    say that some sort of concatenation operator is the primary means of

    forming programs, be that operator whitespace, a dot, etc.

    5. Quotation works quite differently in Factor and Joy compared to

    Cat. In Cat, quotation is an abstraction mechanism (as Chris has

    pointed out to me). In Factor and Joy, it is not. It is therefore not

    accurate to say a quotation is a sequence of objects.

    6. There's no reason that only one stack be live at any given point.

    Joy's persistent stack semantics allow for parallel evaluation.

    Ignoring IO, you can reduce programs using rewrite rules applied in

    any order and/or simultaneously.

    7. It it said that "literals are pushed onto the stack when

    encountered by the evaluator". This implies that '5' is an object, not

    a function, which I think is a less useful (and likely inaccurate)

    characterization.

    - John

## John Nowak — 2008-12-31 23:49:17

    On Dec 31, 2008, at 6:12 PM, Adam wrote:

     > Also, concatenative.org is editable by the public as well if you

    > register.

     This is probably one of those "should wait 24 hours before sending

    emails", but oh well...

    Concatenative.org feels more like the future Factor wiki to me than a

    general repository for information about concatenative languages. I

    understand that Factor is a useful language (in contrast to Joy, Cat,

    etc). I also understand that it's Slava's site. That said, I'd much

    prefer it if the Factor-specifics were separated into their own wiki

    (subdirectories on a wiki are meaningless) so the content could focus

    exclusively on the theory of concatenative languages.

    The dead links everywhere to things like "C++" and "garbage

    collection" make it look like a bit of a wasteland and make the

    purpose of the site less clear. I've asked if I could remove them but

    was told not to. This is probably just be some overly territorial part

    of my primitive mammalian brain going off, but I'm not comfortable

    contributing to it in its current state.

    A clear statement of intent for the site (and adherence to it) would

    help me out. I'm not really interested in contributing to "The Factor

    + Some Concatenative Stuff Wiki". I'm sure such a thing is not Slava's

    explicit intent, but it seems to be drifting in that general direction.

    Then again, perhaps this is just my problem. It wouldn't be the first

    time!

    - John

## Don Groves — 2008-12-31 23:54:31

    On Dec 31, 2008, at 3:25 PM, John Nowak wrote:

     >

    > On Dec 31, 2008, at 6:01 PM, Adam wrote:

    >

    >> Slava recently created a nice description of Concatenative languages

    >> in the following four articles

    >

    > Thanks, I had hadn't seen that before.

    >

    > Slava's description seems decent enough. It is, however, stack-

    > focused. He says that concatenative languages and stack-based

    > languages are similar, but then never clarifies the differences and

    > goes on to conflate the two. I also have some minor niggles (in no

    > particular order):

     I haven't worked on this stuff for almost a year now, but when last

    involved, I was fiddling with the terminology to eliminate the word

    "stack," which is ingrained in the concatenative culture, but at times

    not as descriptive as I would like. As these languages mature, their

    operators become less and less stack-like.

    I was leaning toward defining a concatenative (if that's the right

    word) program as "a list of operators applied to a (possibly initially

    empty) list of operands."

    This definition seems to me to have two advantages: (1) it allows

    for non-FIFO shuffle operations like swap, rot, etc..., which are fine

    for a list but not so for a classically-defined stack; and (2) the order

    of application is not specified.

    Not being up on this topic at the moment, the order of application

    may need to be specified -- [operand] [operators] -- I'm not sure

    of this.

    I'd appreciate any comments, as they may save me wasted effort

    if/when I do return to this eternally intriguing subject (which is why

    I've returned to it so often already ;-)

    --

    don

     > 1. There's no reason a concatenative language has to support

    > recursion. My initial version of 5th did not.

    > 2. Not all concatenative languages have multiple programmer-accessible

    > stacks. Forth and Factor do, Joy and Cat do not.

    > 3. It isn't mentioned that the reduction of a function the

    > transformation of one function to another. This is the critical thing

    > I find lacking in FP and FL.

    > 4. It says composition must be denoted by concatenation. I'd prefer to

    > say that some sort of concatenation operator is the primary means of

    > forming programs, be that operator whitespace, a dot, etc.

    > 5. Quotation works quite differently in Factor and Joy compared to

    > Cat. In Cat, quotation is an abstraction mechanism (as Chris has

    > pointed out to me). In Factor and Joy, it is not. It is therefore not

    > accurate to say a quotation is a sequence of objects.

    > 6. There's no reason that only one stack be live at any given point.

    > Joy's persistent stack semantics allow for parallel evaluation.

    > Ignoring IO, you can reduce programs using rewrite rules applied in

    > any order and/or simultaneously.

    > 7. It it said that "literals are pushed onto the stack when

    > encountered by the evaluator". This implies that '5' is an object, not

    > a function, which I think is a less useful (and likely inaccurate)

    > characterization.

    >

    > - John

    >

    > ------------------------------------

    >

    > Yahoo! Groups Links

    >

    >

    >

## John Nowak — 2009-01-01 00:24:08

    On Dec 31, 2008, at 6:54 PM, Don Groves wrote:

     > I was leaning toward defining a concatenative (if that's the right

    > word) program as "a list of operators applied to a (possibly initially

    > empty) list of operands."

     I don't think this is a satisfactory definition for a few reason:

    1. What exactly is a "list of operators"? Do you mean a sequence of

    functions reified as a list of objects? I don't think that's necessary.

    2. For me, the main advantage of a concatenative language is that you

    get rid of application. Manfred von Thun pointed this out in his "Joy

    compared with other functional languages" paper and I think it is

    critical to the definition of concatenative languages.

    3. There's no reason that the data structure the functions operate on

    be a list or a stack. I recently proposed a language using vectors in

    the style of More's array theory. Earlier today, Chris proposed a

    language based on a deque. I believe XY works on a stack/queue tuple.

    Other possibilities are easy to dream up.

     > the order of application is not specified.

     This would depend on the language in question. Various evaluation

    strategies can be employed. In a language with side effects, the order

    of reduction is going to be important. One could even imagine a

    language with a term rewriting semantics that allows definitions of

    the form 'dup drop  -> id'. If your rewrite rules aren't confluent,

    the way in which you reduce will matter.

    - John

## John Nowak — 2009-01-01 00:36:34

    On Dec 31, 2008, at 2:34 PM, Christopher Diggins wrote:

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

    >

    > Allow me to present the deque language that I just made up.

    > ...

    > So is this a concatenative language?

     Looks like it to me.

    The question is, which criteria would it *not* satisfy? I can't think

    of any unless you restrict the forms of the language to composition

    and quotation. Such a restriction would admit all current

    "concatenative" languages but rule out things like language you

    proposed (due to the '!' form) and the recent things I've been

    proposing that use construction.

    If that were the case, we could refer to concatenative languages as

    the subset of compositional languages (i.e. languages that use

    composition instead of application) that have quotation and

    composition as their only program forming operations. I seem to recall

    proposing this definition awhile back.

    One issue with this definition is that Forth doesn't qualify as it

    doesn't offer quotation. My proposed second-order 5th wouldn't qualify

    either as it doesn't offer quotation and defines new combinators in

    terms of (statically reducible) substitution. As my gut tells me that

    both Forth and 5th should count, I think the composition+quotation

    restriction may be too severe. You can't argue with the gut after all.

    - John

## William Tanksley, Jr — 2009-01-01 01:56:43

    John Nowak <john@...> wrote:

     > The general idea that I've had for a prefix/infix language is as

    > follows:

    > 1. 'f g' denotes the composition of 'f' and 'g'

    > 2. 'f g h' denotes the composition of 'g' with the construction of 'f'

    > and 'h' (construction is basically a cleave combinator)

    > 3. Grouping is to the right such that 'f g h i j k == f g (h i (j k))'

    > 4. Composition is associative such that '(f g) h == f (g h)'

    > So, is this concatenative? It's just composition and cleave combinators.

     As I see it, no. The problem is that grouping is semantically

    significant (rule 3), but not syntactically significant (rules 1&2).

    It violates my rule that a concatenative language must have

    associative semantics and syntax -- that means no required implicit

    grouping.

     > - John

     -Wm

## Christopher Diggins — 2009-01-01 03:48:50

    Hi All,

    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

    with a deconstruction. I am happy to discuss it here (avoids the

    headache of having to register to leave comments).

    Cheers,

    Christopher

## Don Groves — 2009-01-01 04:07:57

    On Dec 31, 2008, at 4:24 PM, John Nowak wrote:

     > On Dec 31, 2008, at 6:54 PM, Don Groves wrote:

    >

    >> I was leaning toward defining a concatenative (if that's the right

    >> word) program as "a list of operators applied to a (possibly

    >> initially

    >> empty) list of operands."

    >

    > I don't think this is a satisfactory definition for a few reason:

    >

    > 1. What exactly is a "list of operators"? Do you mean a sequence of

    > functions reified as a list of objects? I don't think that's

    > necessary.

     As I now belatedly recall, no doubt prompted by your words, I was

    using "sequence of operators" and "sequence of operands" rather

    than lists.

     > 2. For me, the main advantage of a concatenative language is that you

    > get rid of application. Manfred von Thun pointed this out in his "Joy

    > compared with other functional languages" paper and I think it is

    > critical to the definition of concatenative languages.

     I'll review that paper. Perhaps my use of of the word "application" to

    indicate the catenation of two sequences, e.g., [a b] [+] is confusing.

     > 3. There's no reason that the data structure the functions operate on

    > be a list or a stack. I recently proposed a language using vectors in

    > the style of More's array theory. Earlier today, Chris proposed a

    > language based on a deque. I believe XY works on a stack/queue tuple.

    > Other possibilities are easy to dream up.

     The reason I picked "sequence" is that it seems to be the most basic

    ordered structure.

     >> the order of application is not specified.

    >

    > This would depend on the language in question. Various evaluation

    > strategies can be employed. In a language with side effects, the order

    > of reduction is going to be important. One could even imagine a

    > language with a term rewriting semantics that allows definitions of

    > the form 'dup drop  -> id'. If your rewrite rules aren't confluent,

    > the way in which you reduce will matter.

     Many thanks for taking the time to comment, John. I'll tuck this away

    with my notes for when the urge strikes again...

    --

    don

     > - John

## William Tanksley, Jr — 2009-01-01 06:37:35

    Christopher Diggins <cdiggins@...> 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

    > with a deconstruction. I am happy to discuss it here (avoids the

    > headache of having to register to leave comments).

     That's a good definition.

    I did like the one you posted in the last thread, though; the one I

    listed as #2 in my list above. I like the fact that it explicitly

    mentions concatenation (making the rationale for the name clear), and

    it also depends on the concept of associativity, which directly drives

    the ability to easily factor.

    I do suspect that the definition might be a little improved by

    hybridizing it with your newest one, perhaps something like this:

    "A concatenative programming language is language in which terms

    correspond to functions and in which the juxtaposition of terms

    denotes an associative operation on functions."

    Heh... That was simpler than I thought.

    Is it TOO general? It seems to me to cover all the cases, even the

    non-interesting ones (such as where the operation is multiplication).

     > Christopher

     -Wm

## John Nowak — 2009-01-01 10:03:37

    On Dec 31, 2008, at 8:56 PM, William Tanksley, Jr wrote:

     > John Nowak <john@...> wrote:

    >>

    >

    >> 1. 'f g' denotes the composition of 'f' and 'g'

    >> 2. 'f g h' denotes the composition of 'g' with the construction of

    >> 'f'

    >> and 'h' (construction is basically a cleave combinator)

    >> 3. Grouping is to the right such that 'f g h i j k == f g (h i (j

    >> k))'

    >> 4. Composition is associative such that '(f g) h == f (g h)'

    >>

    >> So, is this concatenative? It's just composition and cleave

    >> combinators.

    >

    > As I see it, no. The problem is that grouping is semantically

    > significant (rule 3), but not syntactically significant (rules 1&2).

    > It violates my rule that a concatenative language must have

    > associative semantics and syntax -- that means no required implicit

    > grouping.

     So if I got rid of rules 2 and 3, would it be concatenative? It would

    have the same underlying semantics except concatenation is would

    always mean composition.

    This:

        (sq b) - 4 * a * c

    Would be written like this instead:

        - [sq b, * [4, * [a, c]]]

    If your answer is yes, my problem with that is that we don't impose

    the same syntactic restrictions on the definition of an applicative

    language. Tons of syntaxes are employed (Lisp, Haskell, J, FP, etc),

    yet we still call them all applicative. Perhaps concatenative isn't

    the right term, but I'd very much like a term focused strictly on

    semantics like "applicative" is. Again, "compositional" or similar

    seems like the obvious choice with "concatenative" being a subset

    defined partially by its syntax.

    - John

## John Nowak — 2009-01-01 10:23:28

    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

## John Nowak — 2009-01-01 10:28:39

    On Dec 31, 2008, at 11:07 PM, Don Groves wrote:

     >> 3. There's no reason that the data structure the functions operate on

    >> be a list or a stack. I recently proposed a language using vectors in

    >> the style of More's array theory. Earlier today, Chris proposed a

    >> language based on a deque. I believe XY works on a stack/queue tuple.

    >> Other possibilities are easy to dream up.

    >

    > The reason I picked "sequence" is that it seems to be the most basic

    > ordered structure.

     They need not be ordered. Consider a language that passed around a

    dictionary. Primitive operations would assume their arguments were

    stored at particular names. Essentially, it would be something like a

    register machine (as opposed to a stack machine).

    No, it isn't *useful*, but I'm not sure if you'd want to exclude it.

    - John

## John Nowak — 2009-01-01 10:54:20

    On Jan 1, 2009, at 1:37 AM, William Tanksley, Jr wrote:

     > I do suspect that the definition might be a little improved by

    > hybridizing it with your newest one, perhaps something like this:

    >

    > "A concatenative programming language is language in which terms

    > correspond to functions and in which the juxtaposition of terms

    > denotes an associative operation on functions."

    >

    > Is it TOO general? It seems to me to cover all the cases, even the

    > non-interesting ones (such as where the operation is multiplication).

     I'd say yes. Ideally, we'd like to be both clear *and* precise. I

    think such a definition would satisfy the first requirement (it's

    clear) but not the latter (it's too broad to be useful). It might be

    worth considering if we had some other interesting associative

    operations to base a programming language on, but I (thankfully) can't

    think of any.

    - John

## John Cowan — 2009-01-01 10:59:53

    John Nowak scripsit:

     > I'd say yes. Ideally, we'd like to be both clear *and* precise. I

    > think such a definition would satisfy the first requirement (it's

    > clear) but not the latter (it's too broad to be useful). It might be

    > worth considering if we had some other interesting associative

    > operations to base a programming language on, but I (thankfully) can't

    > think of any.

     I agree.  It seems to me essential for a concatenative language that the

    associative operation in question be composition and not something else.

    --

    John Cowan    http://ccil.org/~cowan    cowan@...

    [T]here is a Darwinian explanation for the refusal to accept Darwin.

    Given the very pessimistic conclusions about moral purpose to which his

    theory drives us, and given the importance of a sense of moral purpose

    in helping us cope with life, a refusal to believe Darwin's theory may

    have important survival value. --Ian Johnston

## Christopher Diggins — 2009-01-01 15:57:34

    On Thu, Jan 1, 2009 at 1:37 AM, William Tanksley, Jr

    <wtanksleyjr@...> wrote:

     > Christopher Diggins <cdiggins@...> 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

    >> with a deconstruction. I am happy to discuss it here (avoids the

    >> headache of having to register to leave comments).

    >

    > That's a good definition.

     Thanks.

     > I did like the one you posted in the last thread, though; the one I

    > listed as #2 in my list above. I like the fact that it explicitly

    > mentions concatenation (making the rationale for the name clear),

     I think that "juxtaposition of terms" is almost synonymous with

    concatenation. For a computer scientist familiar with language theory

    the terminology juxtaposition is more immediately recognizable. This

    is the terminology used by more than one expert in the field.

     > and

    > it also depends on the concept of associativity, which directly drives

    > the ability to easily factor.

     I agree that the associative property of function composition drives

    some of the interesting characteristics of the class of languages, but

    I think this is not necessary in the formal definition, but is a

    statement about why we are interested.

     > I do suspect that the definition might be a little improved by

    > hybridizing it with your newest one, perhaps something like this:

    >

    > "A concatenative programming language is language in which terms

    > correspond to functions and in which the juxtaposition of terms

    > denotes an associative operation on functions."

    >

    > Heh... That was simpler than I thought.

    >

    > Is it TOO general? It seems to me to cover all the cases, even the

    > non-interesting ones (such as where the operation is multiplication).

     I think it is too general. There are no interesting languages that I

    know of that don't use composition as the fundamental operation. I

    think restricting the definition to composition helps keep the class

    of languages more useful, and makes the relation to traditional

    functional languages more obvious.

    My goal is to relate concatenative languages to functional languages,

    especially the lambda calculus. I think this will help spur serious

    study of the languages.

     >> Christopher

    >

    > -Wm

## Don Groves — 2009-01-01 21:01:08

    On Jan 1, 2009, at 2:28 AM, John Nowak wrote:

     >

    > On Dec 31, 2008, at 11:07 PM, Don Groves wrote:

    >

    >>> 3. There's no reason that the data structure the functions operate

    >>> on

    >>> be a list or a stack. I recently proposed a language using vectors

    >>> in

    >>> the style of More's array theory. Earlier today, Chris proposed a

    >>> language based on a deque. I believe XY works on a stack/queue

    >>> tuple.

    >>> Other possibilities are easy to dream up.

    >>

    >> The reason I picked "sequence" is that it seems to be the most basic

    >> ordered structure.

    >

    > They need not be ordered. Consider a language that passed around a

    > dictionary. Primitive operations would assume their arguments were

    > stored at particular names. Essentially, it would be something like a

    > register machine (as opposed to a stack machine).

    >

    > No, it isn't *useful*, but I'm not sure if you'd want to exclude it.

     Sure it's useful. We do that now only we call them "files."

    --

    don

     > - John

    >

    > ------------------------------------

    >

    > Yahoo! Groups Links

    >

    >

    >

## Robbert Dalen — 2009-01-01 23:09:17

    My (very broad) definition would be:

    'A concatenative language is a language wherein syntactically valid

    expressions can be concatenated to yield syntactically valid

    expressions.'

    For instance, this definition includes all of the following (postfix)

    expressions to be concatenative:

    1

    1 2

    1 2 +

    +

    3 +

    3 4 +

    (and with a postfix concatenation of +):

    1 2 + 3 4 + + == 10

    the latter are all valid syntactic expressions, but may be not

    *semantically* valid, depending on the specific concatenative language

    in question.

    Postfix, prefix or infix doesn't really matter for a language to be

    concatenative or not.

    For instance, it is perfectly ok for prefix expressions to be

    concatenative:

    1

    1 2

    + 1 2

    +

    + 3

    + 3 4

    (and with a prefix concatenation of +):

    + + 1 2 + 3 4 = 10

    infix expressions:

    1

    1 +

    1 + 2

    4

    + 4

    3 + 4

    (and with an infix concatenation of +):

    1 + 2 + 3 + 4 == 10

    Moreover, I think the 'concatenative languages are non-applicative'

    argument is mood:

    It is perfectly ok - and convenient  - to have (postfix,prefix,infix)

    lambdas. Here are three different expressions that swap 1 and 2:

    postfix: 1 2 {x y=y x} == 1 {x=2 x} == 2 1

    prefix: {x y=y x} 1 2 == {y=y 1} 2 == 2 1

    infix1: 1 {x y=y x} 2 == 1 {x=2 x} == 2 1

    infix2: 1 {x y=y x} 2 == {y=y 1} 2 == 2 1

    Here, {...} constructs are anonymous, (partially applied) functions

    which can be concatenated to other expressions, just as any other

    primitive function.

    However, only in the infix case the application order is needs to be

    defined - either left-to-right or right-to-left - but that's it.

    - robbert

    [Non-text portions of this message have been removed]

## William Tanksley, Jr — 2009-01-02 00:10:35

    Christopher Diggins <cdiggins@...> wrote:

     > William Tanksley, Jr <wtanksleyjr@...> wrote:

    >> I did like the one you posted in the last thread, though; the one I

    >> listed as #2 in my list above. I like the fact that it explicitly

    >> mentions concatenation (making the rationale for the name clear),

    > I think that "juxtaposition of terms" is almost synonymous with

    > concatenation. For a computer scientist familiar with language theory

    > the terminology juxtaposition is more immediately recognizable. This

    > is the terminology used by more than one expert in the field.

     Okay, I grant that there's value in the word "juxtaposition" (unlike

    "concatenate", it allows whitespace to be interposed). Accepted.

     >> and

    >> it also depends on the concept of associativity, which directly drives

    >> the ability to easily factor.

    > I agree that the associative property of function composition drives

    > some of the interesting characteristics of the class of languages, but

    > I think this is not necessary in the formal definition, but is a

    > statement about why we are interested.

     Logically speaking, it is necessary; you're implying below that it's

    not sufficient. It's kind of nice to have the definition touch on one

    of the main interesting properties of the language being defined,

    don't you think?

    It's worth mentioning that Nowak's original language wasn't

    concatenative because it isn't associative; it actually DOES use

    composition.

     >> "A concatenative programming language is language in which terms

    >> correspond to functions and in which the juxtaposition of terms

    >> denotes an associative operation on functions."

    >> Is it TOO general? It seems to me to cover all the cases, even the

    >> non-interesting ones (such as where the operation is multiplication).

    > I think it is too general. There are no interesting languages that I

    > know of that don't use composition as the fundamental operation. I

    > think restricting the definition to composition helps keep the class

    > of languages more useful, and makes the relation to traditional

    > functional languages more obvious.

     Well, I may have to accept that, since I like your definition. I'm

    just not sure about it -- we do know that other operators are

    possible, we just don't know of any interesting ones.

     > My goal is to relate concatenative languages to functional languages,

    > especially the lambda calculus. I think this will help spur serious

    > study of the languages.

     By all means.

    I like your definition well enough to support it as the official

    definition. I do think the Wikipedia page should discuss some ways of

    testing for concatenativity.

    -Wm

## John Nowak — 2009-01-02 00:23:44

    On Jan 1, 2009, at 7:10 PM, William Tanksley, Jr wrote:

     >> I agree that the associative property of function composition drives

    >> some of the interesting characteristics of the class of languages,

    >> but

    >> I think this is not necessary in the formal definition, but is a

    >> statement about why we are interested.

    >

    > Logically speaking, it is necessary; you're implying below that it's

    > not sufficient. It's kind of nice to have the definition touch on one

    > of the main interesting properties of the language being defined,

    > don't you think?

    >

    > It's worth mentioning that Nowak's original language wasn't

    > concatenative because it isn't associative; it actually DOES use

    > composition.

     I think the actual problem was that the juxtaposition of two functions

    denoted composition, but the juxtaposition of three functions denoted

    composition and construction.

    Did you have something in mind where concatenation solely means

    composition but somehow isn't associative? I'm not sure how this could

    be possible unless the operation wasn't actually function composition.

    Perhaps I'm not understanding you correctly.

    - John

## John Nowak — 2009-01-02 00:31:01

    On Jan 1, 2009, at 6:09 PM, Robbert Dalen wrote:

     > My (very broad) definition would be:

    >

    > 'A concatenative language is a language wherein syntactically valid

    > expressions can be concatenated to yield syntactically valid

    > expressions.'

     This definition seems so broad as to have no useful consequences. At

    least Tanksley's associative requirement would allow factoring and

    some other basic forms of manipulation.

    I think the thing to remember here is that we have things we want to

    describe and things we don't care to describe. Since the definition

    should be useful for our purposes, including a great number of things

    we don't care about as "concatenative" probably isn't the way to go.

    Getting away from having to say things like "a concatenative language

    where concatenation denotes function composition" is the point of this

    exercise in my opinion.

    - John

## Stevan Apter — 2009-01-02 13:12:19

    i've stayed out of this wrangle.  i've fallen into the habit of

    using/interpreting "concatenative" to mean nothing more than

    "joy-like."  if someone claims that L is concatenative, and L

    doesn't look like joy, then i look for an argument which connects

    L in some non-obvious way with joy.

    but now i think that robbert is correct.  "concatenative" is

    purely syntactic, and picks out just those languages where

    concatenation is used to make wfes from wfes.  at any rate,

    that seems to match my "pre-theoretical" use of the term.

    and that reminds me:  robbert, can we have a status update on

    enchilada?

     ----- Original Message -----

    From: "John Nowak" <john@...>

    To: <concatenative@yahoogroups.com>

    Sent: Thursday, January 01, 2009 7:31 PM

    Subject: Re: [stack] the concatenative wikipedia article

    >

    > On Jan 1, 2009, at 6:09 PM, Robbert Dalen wrote:

    >

    >> My (very broad) definition would be:

    >>

    >> 'A concatenative language is a language wherein syntactically valid

    >> expressions can be concatenated to yield syntactically valid

    >> expressions.'

    >

    > This definition seems so broad as to have no useful consequences. At

    > least Tanksley's associative requirement would allow factoring and

    > some other basic forms of manipulation.

    >

    > I think the thing to remember here is that we have things we want to

    > describe and things we don't care to describe. Since the definition

    > should be useful for our purposes, including a great number of things

    > we don't care about as "concatenative" probably isn't the way to go.

    > Getting away from having to say things like "a concatenative language

    > where concatenation denotes function composition" is the point of this

    > exercise in my opinion.

    >

    > - John

    >

## Robbert van Dalen — 2009-01-02 14:18:22

    i do agree with john (nowak) that - if concatenativity is defined to

    be purely syntactic - it would include too many (non-interesting)

    languages.

    however, the syntactic standpoint does *exclude* a whole bunch of

    useful languages such as c(++), java, haskell,etc, that are not

    concatenative.

    also, john's latest definition on wikipedia:

    'A concatenative language is a non-applicative programming language in

    which all terms denote functions and the juxtaposition of functions

    denotes function composition......

    .. would rule out enchilada (www.enchiladacode.nl) to be concatenative because:

    - not all terms in enchilada are functions

    - therefor, the juxtaposition of functions doesn't always denotes

    function composition

    and what about forth? surely, we don't want forth to be excluded!

    - robbert

     On 1/2/09, Stevan Apter <sa@...> wrote:

    > i've stayed out of this wrangle.  i've fallen into the habit of

    > using/interpreting "concatenative" to mean nothing more than

    > "joy-like."  if someone claims that L is concatenative, and L

    > doesn't look like joy, then i look for an argument which connects

    > L in some non-obvious way with joy.

    >

    > but now i think that robbert is correct.  "concatenative" is

    > purely syntactic, and picks out just those languages where

    > concatenation is used to make wfes from wfes.  at any rate,

    > that seems to match my "pre-theoretical" use of the term.

    >

    > and that reminds me:  robbert, can we have a status update on

    > enchilada?

## William Tanksley, Jr — 2009-01-02 14:20:41

    John Nowak <john@...> wrote:

     > William Tanksley, Jr wrote:

    >>> 1. 'f g' denotes the composition of 'f' and 'g'

    >>> 2. 'f g h' denotes the composition of 'g' with the construction of

    >>> 'f'

    >>> and 'h' (construction is basically a cleave combinator)

    >>> 3. Grouping is to the right such that 'f g h i j k == f g (h i (j

    >>> k))'

    >>> 4. Composition is associative such that '(f g) h == f (g h)'

    >>> So, is this concatenative? It's just composition and cleave

    >>> combinators.

    >> As I see it, no. The problem is that grouping is semantically

    >> significant (rule 3), but not syntactically significant (rules 1&2).

    >> It violates my rule that a concatenative language must have

    >> associative semantics and syntax -- that means no required implicit

    >> grouping.

    > So if I got rid of rules 2 and 3, would it be concatenative? It would

    > have the same underlying semantics except concatenation is would

    > always mean composition.

     Yes -- if you provide syntax for cleave, the rest of the language is

    clearly listlike and associative.

    Unfortunately, the example you give doesn't appear to conform to the

    rules I listed above; you seem to be using some alternative

    non-concatenative syntax.

     > This:

    >    (sq b) - 4 * a * c

    > Would be written like this instead:

    >    - [sq b, * [4, * [a, c]]]

     How is that concatenative? It appears totally applicative. I certainly

    don't see any opportunity for associativity in that example... If this

    is how things must be done, then I take it back: your language may

    possibly technically use composition, but if it's not associative in

    practice, it's not concatenative.

     > If your answer is yes, my problem with that is that we don't impose

    > the same syntactic restrictions on the definition of an applicative

    > language.

     We talk about applicative languages here, but the reality is that

    there are many different syntaxes for applicative languages, united in

    common by one syntactic feature: the need for a tree structure.

    Calling a language "applicative" doesn't tell you what its syntax is

    like (except that it must be tree-structured), while calling a

    language concatenative does tell you what its syntax is like.

    I think it's proper to define and classify languages in terms of their

    syntax, as long as one remembers that syntax and semantics are tied

    together by definition of "language". "Applicative" is not such a

    classification; "concatenative" was intended to be. Remember the

    now-obsolete term "flat", that was intended to be a subset of

    "concatenative"? I decided there was little need for flatness once we

    realized that associativity neatly explained concatenative ease of

    use; but flatness is syntactic too. Other syntactic classifications

    include tree-structured, LL, LALR, etc...

     > Tons of syntaxes are employed (Lisp, Haskell, J, FP, etc),

    > yet we still call them all applicative. Perhaps concatenative isn't

    > the right term, but I'd very much like a term focused strictly on

    > semantics like "applicative" is. Again, "compositional" or similar

    > seems like the obvious choice with "concatenative" being a subset

    > defined partially by its syntax.

     Composition is a possible term for semantics... I suppose you could

    use it. It doesn't seem very useful, since as Chris and I have been

    hammering out, it's neither a subset nor a superset, but rather just

    one feature a language can have. An applicative language can have

    compositional semantics in some part of its syntax (your language

    appears to be an example of that), and that part of its syntax will be

    concatenative... but it's kind of hard to say that it's a

    concatenative language, since actual use of associativity is very

    rare.

     > - John

     -Wm

## John Nowak — 2009-01-02 21:26:32

    On Jan 2, 2009, at 9:18 AM, Robbert van Dalen wrote:

     > i do agree with john (nowak) that - if concatenativity is defined to

    > be purely syntactic - it would include too many (non-interesting)

    > languages.

    >

    > however, the syntactic standpoint does *exclude* a whole bunch of

    > useful languages such as c(++), java, haskell,etc, that are not

    > concatenative.

     So would the category of all languages that use 'car' and 'cdr' to

    take the head and tail of a list. Such a category would basically mean

    Lisp and derivatives, but the definition of the category itself

    wouldn't let us say anything useful. I think that's the danger with

    your definition: It allows the things we want to allow, but doesn't

    let us say anything about them.

     > and what about forth? surely, we don't want forth to be excluded!

     I don't think the definition Chris proposed would necessarily exclude

    Forth. If you think there's an issue with parse words, perhaps there's

    some way to alter the definition?

     > - not all terms in enchilada are functions

    > - therefor, the juxtaposition of functions doesn't always denotes

    > function composition

     Enchilada is what I'd call a postfix term rewriting language. I don't

    think I'd consider it concatenative due to the presence of lambdas.

    Discussions in the past have indicated that lexical scope and

    substitution are not compatible with concatenativity. For example,

    given the expression '{a b=a b +}', I cannot define 'f' to be 'b +'

    and then say '{a b=a b +} == {a b=a f}'.

    - John

## John Nowak — 2009-01-02 21:41:03

    On Jan 2, 2009, at 9:20 AM, William Tanksley, Jr wrote:

     >> This:

    >>   (sq b) - 4 * a * c

    >> Would be written like this instead:

    >>   - [sq b, * [4, * [a, c]]]

    >

    > How is that concatenative? It appears totally applicative. I certainly

    > don't see any opportunity for associativity in that example

     You're right, there isn't any opportunity for it in that example

    because there's no contiguous composition of more than two functions.

    Perhaps this is a better example:

        a = hd

        b = hd tl

        c = hd tl tl

        hypot = sqrt + [sq a, sq b]

    Or, you could do something like this:

        sq-top = cons [sq a, tl]

        hypot = sqrt + sq swap sq

    I don't think it would be reasonable to say this isn't concatenative

    just because the average number of contiguous compositions is somewhat

    lower than in a stack-based language. They both share the all

    properties highlighted on the wikipedia entry-in-progress.

     >> If your answer is yes, my problem with that is that we don't impose

    >> the same syntactic restrictions on the definition of an applicative

    >> language.

    >

    > We talk about applicative languages here, but the reality is that

    > there are many different syntaxes for applicative languages, united in

    > common by one syntactic feature: the need for a tree structure.

     Applicative languages do not need a tree structure. The combinatory

    calculus is applicative and can even be written with a "concatenative"

    syntax. Look at Unlambda.

     > I think it's proper to define and classify languages in terms of their

    > syntax

     Agreed, ideally provided another term is available for languages with

    the same semantics but a different syntax. Lacking such a term, I

    think we lack the capability to talk about an interesting family of

    languages. In any case, I have no issue with making the term

    "concatenative" have syntactic implications as the Wikipedia entry-in-

    progress indicates.

    - John

## Robbert Dalen — 2009-01-02 22:15:36

    > So would the category of all languages that use 'car' and 'cdr' to

    >

    > take the head and tail of a list. Such a category would basically mean

    > Lisp and derivatives, but the definition of the category itself

    > wouldn't let us say anything useful. I think that's the danger with

    > your definition: It allows the things we want to allow, but doesn't

    > let us say anything about them.

    >

     bad example: car and cdr talk about semantics not syntax.

    but you are right: we want positive statements, not negative.

    in true leo brouwer style:

    'let's be constructive!'

     > Enchilada is what I'd call a postfix term rewriting language. I don't

    > think I'd consider it concatenative due to the presence of lambdas.

    > Discussions in the past have indicated that lexical scope and

    > substitution are not compatible with concatenativity. For example,

    > given the expression '{a b=a b +}', I cannot define 'f' to be 'b +'

    > and then say '{a b=a b +} == {a b=a f}'.

    >

     there is a catch:

    a lambda in enchilada is an unary (monadic) operator that is also a

    atomic term.

    as a consequence, you can't substitute expressions that are within the

    {scope} of a lambda.

    also, definitions shouldn't contain free variables (or symbols as they

    are called in enchilada)

     > - John

     - robbert.

## John Nowak — 2009-01-02 22:31:27

    On Jan 2, 2009, at 5:15 PM, Robbert Dalen wrote:

     >> Enchilada is what I'd call a postfix term rewriting language. I don't

    >> think I'd consider it concatenative due to the presence of lambdas.

    >> Discussions in the past have indicated that lexical scope and

    >> substitution are not compatible with concatenativity. For example,

    >> given the expression '{a b=a b +}', I cannot define 'f' to be 'b +'

    >> and then say '{a b=a b +} == {a b=a f}'.

    >

    > there is a catch:

    >

    > a lambda in enchilada is an unary (monadic) operator that is also a

    > atomic term. as a consequence, you can't substitute expressions that

    > are within the {scope} of a lambda.

     Quotations are atomic terms too (i.e. they are a single element), but

    you can still factor out subexpressions within them. Maybe what you're

    trying to say is at the entire lambda is an atom in the sense that you

    can't open it up any further. I would agree that this means you can't

    substitute expressions (by definition), but it would also mean that

    what you have inside isn't a concatenative expression because none of

    the normal rules apply.

     > also, definitions shouldn't contain free variables (or symbols as they

    > are called in enchilada)

     But variables can be free at points within a definition? That seems

    like further evidence that something isn't compositional.

    All that said, it's clear that Enchilada is "concatenativish". Perhaps

    this is just a case where we need a mostly-concatenative/purely-

    concatenative distinction.

    - John

## Joe Bowbeer — 2009-01-02 23:52:05

    Keep in mind that wikipedia is not where new definitions should be blazed.

    The articles should be written in layman's terms, from a neutral point of

    view, and supported by citations.

    See "No original research" and "Neutral point of view".  In particular:

    All Wikipedia articles and other encyclopedic content must be written from a

     > neutral point of view, representing fairly, and as far as possible without

    > bias, all significant views that have been published by reliable sources.

    >

     Can anyone find a reference for the statement that "concatenative" is not

    universally accepted as a useful term?

    Joe

     On Tue, Dec 30, 2008 at 9:27 PM, John Nowak 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 realize many of these concerns are rather tired at this point. I

    > apologize. However, that doesn't change the fact that they've gone

    > unresolved. Indeed, there seems to be almost a resistance to resolving

    > them. I personally think that the non-applicative style of programming

    > has important properties and that it would be great to have a term for

    > them so I could stop redefining "concatenative" every time I talk to

    > someone (including those knowledgeable about concatenative languages).

    >

    > Here are my issues with the article:

    >

    > 1. Concatenative should not be conflated with "stack-based". I have

    > already shown that the counter-examples are beyond mere curiosities.

    >

    > 2. It should be more clearly stressed that concatenative languages are

    > not applicative. The reduction of a concatenative expression is the

    > simplification of one function to another function (e.g. '1 2 + + ==>

    > 3 +'). Never is it necessary to deal with objects or application, and

    > much is gained by not doing so (as is mentioned at

    > http://www.latrobe.edu.au/philosophy/phimvt/joy/j08cnt.htm)

    > .

    >

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

    >

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

    >

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

    >

    > 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; What's "universally

    > accepted" is unimportant. Hell, even Slava (who says it's unimportant)

    > has started concatenative.org (which lists C++ and Java as

    > "interesting languages"... ugh).

    >

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

    >

    > Sorry for bringing this up *again*, but I'm trying to write a paper

    > and keep stumbling over how to describe what it is that I'm talking

    > about.

    >

    > - John

    >

    >

    [Non-text portions of this message have been removed]

## John Nowak — 2009-01-03 00:07:43

    On Jan 2, 2009, at 6:52 PM, Joe Bowbeer wrote:

     > Keep in mind that wikipedia is not where new definitions should be

    > blazed.

     Agreed, but I don't think that's what we're doing. We're trying to

    correct a definition that has obvious deficiencies. Given the nature

    of things, I think the discussion we're having now is about as good of

    a "source" as you're going to get.

     > The articles should be written in layman's terms, from a neutral

    > point of

    > view, and supported by citations.

     The "layman's terms" requirement is not so clear. Go look at the page

    on type theory and tell me that it's in layman's terms. Do you have

    any suggestions for how the article I've proposed might be simplified?

     > Can anyone find a reference for the statement that "concatenative"

    > is not

    > universally accepted as a useful term?

     I've not been able to find anything. The only thing I've seen along

    this lines has been casual comments in the #concatenative chat room on

    freenode. In either case, I don't think it really belongs in the

    article. I don't think "dynamically typed" is a good term either, but

    we're stuck with it. The same goes for "strong typing" which is used

    to mean almost anything.

    - John

## John Nowak — 2009-01-03 00:18:40

    On Jan 2, 2009, at 7:07 PM, John Nowak wrote:

     > 've not been able to find anything. The only thing I've seen along

    > this lines has been casual comments in the #concatenative chat room on

    > freenode. In either case, I don't think it really belongs in the

    > article. I don't think "dynamically typed" is a good term either, but

    > we're stuck with it. The same goes for "strong typing" which is used

    > to mean almost anything.

     In retrospect, this is a pretty flawed analogy.

    Perhaps it is worthwhile for the article to say that the term

    "concatenative" is relatively new and its meaning is not well-

    established. That's different than saying it isn't useful, which I

    think it clearly is (as we, you know, use it).

    - John

## Joe Bowbeer — 2009-01-03 02:16:57

    On Fri, Jan 2, 2009 at 4:18 PM, John Nowak wrote:

     >

    > On Jan 2, 2009, at 7:07 PM, John Nowak wrote:

    >

    > > 've not been able to find anything. The only thing I've seen along

    > > this lines has been casual comments in the #concatenative chat room on

    > > freenode. In either case, I don't think it really belongs in the

    > > article. I don't think "dynamically typed" is a good term either, but

    > > we're stuck with it. The same goes for "strong typing" which is used

    > > to mean almost anything.

    >

    > In retrospect, this is a pretty flawed analogy.

    >

    > Perhaps it is worthwhile for the article to say that the term

    > "concatenative" is relatively new and its meaning is not well-

    > established. That's different than saying it isn't useful, which I

    > think it clearly is (as we, you know, use it).

    >

    > - John

    >

     That sounds reasonable.

    FWIW, I think of Joy and Factor when I think of concatenative.  I would

    describe Forth as a precursor.

    Joe

    [Non-text portions of this message have been removed]

## William Tanksley, Jr — 2009-01-12 03:51:52

    John Nowak <john@...> wrote:

     > William Tanksley, Jr wrote:

    > Perhaps this is a better example:

     Thanks :-).

     >    a = hd

    >    b = hd tl

    >    c = hd tl tl

    >    hypot = sqrt + [sq a, sq b]

    > Or, you could do something like this:

    >    sq-top = cons [sq a, tl]

    >    hypot = sqrt + sq swap sq

    > I don't think it would be reasonable to say this isn't concatenative

    > just because the average number of contiguous compositions is somewhat

    > lower than in a stack-based language. They both share the all

    > properties highlighted on the wikipedia entry-in-progress.

     I'm having a hard time grasping the rules, so I'm limited to asking

    questions. But if a pair of definitions are valid, is their

    juxtaposition also always valid? I don't see why not, so on those

    grounds I think I'll say your language is concatenative. No, I don't

    care to measure the average number of compositions either :-).

    The interesting thing about a hybrid language like this is that we

    might get a chance to compare which part of the language most people

    wind up using. In this hybrid I'd say that concatenativity is favored,

    since it's the default operation; I could also imagine a language

    where composition is indicated by an explicit operator, and simple

    juxtaposition indicated curried application.

     >>> If your answer is yes, my problem with that is that we don't impose

    >>> the same syntactic restrictions on the definition of an applicative

    >>> language.

    >> We talk about applicative languages here, but the reality is that

    >> there are many different syntaxes for applicative languages, united in

    >> common by one syntactic feature: the need for a tree structure.

    > Applicative languages do not need a tree structure. The combinatory

    > calculus is applicative and can even be written with a "concatenative"

    > syntax. Look at Unlambda.

     Every applicative language has a tree structure; unlambda is no

    exception. The tree structure arises when a "parent" syntactic element

    (a function) takes more than one "child" syntactic elements (the

    parameters applied to the function). This is a hidden advantage that

    applicative combinator languages have over concatenative combinators.

    See the page that ieros/Kerby wrote on concatenative combinators. In

    order to make up for this advantage, concatenative combinators have to

    be more complex than applicative ones. In short, conc. combinators

    have to provide a "make siblings" operation, while applicative

    combinators don't need that because they have a sibling operation

    implicit in their syntax.

     >> I think it's proper to define and classify languages in terms of their

    >> syntax

    > Agreed, ideally provided another term is available for languages with

    > the same semantics but a different syntax. Lacking such a term, I

    > think we lack the capability to talk about an interesting family of

    > languages. In any case, I have no issue with making the term

    > "concatenative" have syntactic implications as the Wikipedia entry-in-

    > progress indicates.

     To me, the interesting thing about these languages is precisely that

    the mathematical properties of their syntax and semantics match so

    well.

    If we called them "associative" languages perhaps I'd be mollified...

    But it's already been used in computer language science.

     > - John

     -Wm

## John Nowak — 2009-01-12 06:53:16

    On Jan 11, 2009, at 10:51 PM, William Tanksley, Jr wrote:

     >> Perhaps this is a better example:

    >

    > I'm having a hard time grasping the rules, so I'm limited to asking

    > questions. But if a pair of definitions are valid, is their

    > juxtaposition also always valid?

     Yep. It's just composition in the opposite order.

     > I could also imagine a language where composition is indicated by

    > an explicit operator, and simple juxtaposition indicated curried

    > application.

     Sounds like Haskell to me! The reason Haskell sucks for pointfree

    programming though is that most of the functions are curried. As such,

    you need to modify the functions to get data into the correct places

    (e.g. 'flip f') rather than manipulating the data directly (e.g. 'f .

    swap').  All existing and proposed concatenative languages opt for

    handling multiple values via products (stacks, lists, etc) rather than

    using curried functions. All other pointfree language (FP, FL) or

    mostly pointfree languages (APL, J, etc) that I can think of do the

    same.

     >> Applicative languages do not need a tree structure. The combinatory

    >> calculus is applicative and can even be written with a

    >> "concatenative"

    >> syntax. Look at Unlambda.

    >

    > Every applicative language has a tree structure; unlambda is no

    > exception.

     I think I may've taken tree structure too literally. I see your point.

     > See the page that ieros/Kerby wrote on concatenative combinators. In

    > order to make up for this advantage, concatenative combinators have to

    > be more complex than applicative ones. In short, conc. combinators

    > have to provide a "make siblings" operation, while applicative

    > combinators don't need that because they have a sibling operation

    > implicit in their syntax.

     I'm not quite sure I understand. I'm going to guess (correct me if I'm

    wrong) that you mean concatenative functions need to preserve the

    values they don't act upon:

        Applicative:

        \x y -> x + y

        "Concatenative":

        \((s, x), y) -> (s, x + y)

    If that's what you mean, I don't think you're correct. I won't

    elaborate though as I probably misunderstood things. Please clarify if

    you can.

    - John

## William Tanksley, Jr — 2009-01-12 14:44:17

    John Nowak <john@...> wrote:

     > William Tanksley, Jr wrote:

    >> I could also imagine a language where composition is indicated by

    >> an explicit operator, and simple juxtaposition indicated curried

    >> application.

    > Sounds like Haskell to me! The reason Haskell sucks for pointfree

    > programming though is that most of the functions are curried. As such,

     Interesting point... I wouldn't have expected that currying would

    hurt. This just shows what little I know.

     >> See the page that ieros/Kerby wrote on concatenative combinators. In

    >> order to make up for this advantage, concatenative combinators have to

    >> be more complex than applicative ones. In short, conc. combinators

    >> have to provide a "make siblings" operation, while applicative

    >> combinators don't need that because they have a sibling operation

    >> implicit in their syntax.

    > I'm not quite sure I understand. I'm going to guess (correct me if I'm

    > wrong) that you mean concatenative functions need to preserve the

    > values they don't act upon:

     Sorry for the unclarity -- no. A 'sibling' operation refers to

    something like 'pair'; a way to encode two data items at the same

    level of nesting.

    The most glaring example of where this comes into play is when I tried

    to design a minimal-combinator basis for a concatenative languages.

    The minimal basis for applicative languages contains one combinator;

    the minimal basis for concatenative languages contains two

    (http://portal.acm.org/citation.cfm?id=967781.967785 has a proof). The

    reason is that applicative languages hide some program complexity in

    their syntax: a combinator that takes more than one parameter makes

    its parameters siblings in the parse tree.

     > - John

     -Wm

## John Nowak — 2009-01-12 17:33:33

    On Jan 12, 2009, at 9:44 AM, William Tanksley, Jr wrote:

     > Sorry for the unclarity -- no. A 'sibling' operation refers to

    > something like 'pair'; a way to encode two data items at the same

    > level of nesting.

     Ah. Thanks for clarifying.

     > The minimal basis for applicative languages contains one combinator;

    > the minimal basis for concatenative languages contains two

    > (http://portal.acm.org/citation.cfm?id=967781.967785 has a proof).

     This doesn't seem to be the case for a concatenative language with

    quotation (push). Okasaki is dealing with the additional limitation of

    "flatness". I suppose you could count quotation as a combinator of

    sorts, but in either case it's a very simple operation.

     > See the page that ieros/Kerby wrote on concatenative combinators. In

    > order to make up for this advantage, concatenative combinators have to

    > be more complex than applicative ones

     I'm not sure this is the case. Quotation, composition, and one

    combinator doesn't seem more complex than application and one

    combinator to me, just different. Here's Meertens on the subject (I

    believe from http://portal.acm.org/citation.cfm?id=746988):

    "The basic problem is that the basic operation of the classical

    combinator calculus (and also of the closely related lambda calculus)

    is application instead of composition. Application has not a single

    property. Function composition is associative and has an identity

    element (if one believes in the 'generic' identity function)."

    Perhaps I'm wrong, but I think you may be judging "complexity" simply

    by counting the number of primitive elements. I don't think this is a

    useful metric.

    - John

## William Tanksley, Jr — 2009-01-12 18:19:26

    John Nowak <john@...> wrote:

     > William Tanksley, Jr wrote:

    >> The minimal basis for applicative languages contains one combinator;

    >> the minimal basis for concatenative languages contains two

    >> (http://portal.acm.org/citation.cfm?id=967781.967785 has a proof).

    > This doesn't seem to be the case for a concatenative language with

    > quotation (push). Okasaki is dealing with the additional limitation of

    > "flatness". I suppose you could count quotation as a combinator of

    > sorts, but in either case it's a very simple operation.

     I have to blush -- I'd forgotten that part. Yes, you're right; I was

    thinking of a purely concatenative language, one with no

    non-associative syntax at all (AKA "flat"). Quotation is a strange

    thing to throw into an allegedly concatenative combinator base,

    though; unlike application, it's not an inherent part of the language

    paradigm; thus, I think my confusion is justified.

     >> See the page that ieros/Kerby wrote on concatenative combinators. In

    >> order to make up for this advantage, concatenative combinators have to

    >> be more complex than applicative ones

    > I'm not sure this is the case. Quotation, composition, and one

    > combinator doesn't seem more complex than application and one

    > combinator to me, just different. Here's Meertens on the subject (I

    > believe from http://portal.acm.org/citation.cfm?id=746988):

     I'm not saying that the entire language is more complex; I'm saying

    that the combinator basis is more complex, as measured by the fact

    that you must have two combinators rather than only one.

    Meertens is interesting; thank you for the reference. I've put it on

    my "read immediately" stack.

     > Perhaps I'm wrong, but I think you may be judging "complexity" simply

    > by counting the number of primitive elements. I don't think this is a

    > useful metric.

     http://barker.linguistics.fas.nyu.edu/Stuff/Iota/

    There are many ways to measure the "complexity" of a combinator. None

    of them are obviously correct.

     > - John

     -Wm

## pml060912 — 2009-01-13 12:29:13

    --- In concatenative@yahoogroups.com, "William Tanksley, Jr"

    <wtanksleyjr@...> wrote:

     >

    > John Nowak <john@...> wrote:

    > > William Tanksley, Jr wrote:

    > >> The minimal basis for applicative languages contains one combinator;

    > >> the minimal basis for concatenative languages contains two

    > >> (http://portal.acm.org/citation.cfm?id=967781.967785 has a proof).

    >

    > > This doesn't seem to be the case for a concatenative language with

    > > quotation (push). Okasaki is dealing with the additional limitation of

    > > "flatness". I suppose you could count quotation as a combinator of

    > > sorts, but in either case it's a very simple operation.

    >

    > I have to blush -- I'd forgotten that part. Yes, you're right; I was

    > thinking of a purely concatenative language, one with no

    > non-associative syntax at all (AKA "flat"). Quotation is a strange

    > thing to throw into an allegedly concatenative combinator base,

    > though; unlike application, it's not an inherent part of the language

    > paradigm; thus, I think my confusion is justified.

     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.

## William Tanksley, Jr — 2009-01-13 14:39:03

    pml060912 <pml540114@...> wrote:

     > "William Tanksley, Jr" <wtanksleyjr@...> wrote:

    >> non-associative syntax at all (AKA "flat"). Quotation is a strange

    >> thing to throw into an allegedly concatenative combinator base,

    >> though; unlike application, it's not an inherent part of the language

    >> paradigm; thus, I think my confusion is justified.

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

     Furphy is a fascinating language; I had no idea it had such an

    interesting loop system. I'd say that Furphy probably is

    flat/completely associative; but note that I'm not sure what to do

    with the "Reverse Polish naming" system.

    Furphy's loop system isn't strictly needed in order to be completely

    associative; a ColorForth-like scheme would also work, where a label

    (word name) is identified by a special character, tail recursion is

    automatic, and the compiler recognizes the return operator.

    For those who don't know ColorForth: Colorforth uses "labels" instead

    of having distinct words; unlike Forth, where a word name begins a new

    definition (which implies that the old definition is finished), a

    ColorForth definition merely implies a new entry point.

    Correspondingly, the ";" word in ColorForth compiles a return (which

    will normally be optimized to a tail call) rather than strictly ending

    the current definition.

    ColorForth itself is not flat, because it keeps the concept of

    immediate words; however, it would be easy to do the same thing a

    Furphy and remove the need for all the immediates.

    Unfortunately, Furphy is a foreign language to me, so I can't

    understand the discussion of FREEZE and THAW. I think the use of

    "Reverse Polish Naming" is blocking my understanding -- I can't tell

    when a word I don't recognize is intended to be a definition versus

    when it's simply unfamiliar to me. With all due respect, I'm pretty

    sure that Reverse Polish Naming isn't a good idea; it's way too easy

    to mess a file's semantics up by pre-defining one of the words it

    intends to define. I'd far rather make definitions explicit.

    -Wm

## pml060912 — 2009-01-14 12:58:16

    --- In concatenative@yahoogroups.com, "William Tanksley, Jr"

    <wtanksleyjr@...> wrote:

     >

    > pml060912 <pml540114@...> 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.

    >

    > Furphy is a fascinating language; I had no idea it had such an

    > interesting loop system. I'd say that Furphy probably is

    > flat/completely associative; but note that I'm not sure what to do

    > with the "Reverse Polish naming" system.

     .

    .

    .

     > Unfortunately, Furphy is a foreign language to me, so I can't

    > understand the discussion of FREEZE and THAW.

     The discussion is mainly aimed at describing what is going on behind

    the scenes and how to use the constructs in coding. Your comments

    imply that I need to work on that part of the page. You might find it

    easier to think of them in terms of continuations - FREEZE sets one up

    and THAW uses it.

     I think the use of

     > "Reverse Polish Naming" is blocking my understanding -- I can't tell

    > when a word I don't recognize is intended to be a definition versus

    > when it's simply unfamiliar to me.

     I can see how that would matter for following someone else's code, not

    so much for the coding process itself. I was thinking of addressing it

    with compiler warning messages and a prettyprinting standard for

    coding (it would be easy for the compiler to generate that as part of

    a log).

    In my examples I've tried to separate code that way, so each

    "paragraph" (maybe only one line) either ends with a definition or is

    the last one (which will be run). Maybe I need to be clearer and

    double check that there is always an "and run" paragraph for each

    example or a clear indication that I'm not providing one (technically,

    I am - a null one).

     With all due respect, I'm pretty

     > sure that Reverse Polish Naming isn't a good idea; it's way too easy

    > to mess a file's semantics up by pre-defining one of the words it

    > intends to define. I'd far rather make definitions explicit.

     This comes as part of the larger problem of making typos - the low to

    zero amount of syntax means that the compiler doesn't enforce/catch

    things as much as many languages would. But I want to stay with the

    Forth spirit of trusting and enabling the programmer, so I think

    warnings for each new word are enough. Also, I don't want to introduce

    "special" handling that would bring back modes or the equivalent,

    except as syntactic sugar like the quotation system, to keep the

    fundamentals simple and consistent. So I'll give some thought to

    syntactic sugar for naming, i.e. something that could be handled by a

    preprocessor even though actual implementation would use immediate

    keywords to integrate it with the compiler - suggestions welcome.

## William Tanksley, Jr — 2009-01-15 12:39:28

    pml060912 <pml540114@...> wrote:

     > "William Tanksley, Jr" <wtanksleyjr@...> wrote:

    >> I think the use of

    >> "Reverse Polish Naming" is blocking my understanding -- I can't tell

    >> when a word I don't recognize is intended to be a definition versus

    >> when it's simply unfamiliar to me.

    > I can see how that would matter for following someone else's code, not

    > so much for the coding process itself.

     If I come back to the same code tomorrow, it might as well be somebody

    else's code :-).

     > I was thinking of addressing it

    > with compiler warning messages and a prettyprinting standard for

    > coding (it would be easy for the compiler to generate that as part of

    > a log).

    > In my examples I've tried to separate code that way, so each

    > "paragraph" (maybe only one line) either ends with a definition or is

    > the last one (which will be run). Maybe I need to be clearer and

    > double check that there is always an "and run" paragraph for each

    > example or a clear indication that I'm not providing one (technically,

    > I am - a null one).

     I'm really not understanding 90% of what you're saying, so the

    following is just a guess. I *think* you're proposing that Furphy be

    made whitespace-sensitive, so that definitions have to/are recommended

    to fall within certain formats. This reminds me of ColorForth, and I'm

    in favor of it.

    On the other hand, I'm not in favor of warning messages for syntax. If

    you're going to make the compiler take cues from whitespace, make them

    the ONLY cues it takes. For example, suppose that you wanted to make a

    definition (by convention) be the last word in a paragraph; in that

    case, set up the compiler so that if a word's terminated by a newline

    it's automatically treated as a definition, and if the word's already

    defined it's an error. I don't like that convention, but it'd work.

    I'd prefer a visible convention, for example creating a label every

    time a word begins on column zero (so definition names would be

    against the left margin, and everything else would be indented). An

    even more graceful requirement would be to use a visible character

    tacked onto the desired definition, like a colon or equals sign.

     > This comes as part of the larger problem of making typos - the low to

    > zero amount of syntax means that the compiler doesn't enforce/catch

    > things as much as many languages would. But I want to stay with the

    > Forth spirit of trusting and enabling the programmer, so I think

    > warnings for each new word are enough.

     A compiler that trusts the programmer doesn't feel the need to emit

    warning messages.

    You definitely have gotten rid of an annoyance in Forth by inventing

    this modeless compiler; but I think your first solution isn't as

    modeless as you think. Instead of having one state variable, its state

    is the entire dictionary.

     > Also, I don't want to introduce

    > "special" handling that would bring back modes or the equivalent,

    > except as syntactic sugar like the quotation system, to keep the

    > fundamentals simple and consistent. So I'll give some thought to

    > syntactic sugar for naming, i.e. something that could be handled by a

    > preprocessor even though actual implementation would use immediate

    > keywords to integrate it with the compiler - suggestions welcome.

     Some examples are above :-). My preference is the visible character

    attached to the definition -- perhaps an equals sign at the beginning

    of the word, since your words appear after the thing they define.

    And by the way, your solution is extremely modal, according to

    Raskin's definition: "An human-machine interface is modal with respect

    to a given gesture when (1) the current state of the interface is not

    the user's locus of attention and (2) the interface will execute one

    among several different responses to the gesture, depending on the

    system's current state." (Raskin, "The Humane Interface", Page 42,

    cited on Wikipedia). The "gesture" is typing a word, and the system's

    current state is what words are currently defined. Because of the size

    of the state, it's impossible to have the state ever be the locus of

    the user's attention; thus, there will be a lot of modal errors.

    -Wm

## John Nowak — 2009-01-15 17:17:48

    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.

     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 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:

    http://www.nsl.com/k/xy/xy.htm

    - John