Category talk:Programming paradigm/Concatenative: Difference between revisions

From Rosetta Code
Content added Content deleted
No edit summary
(L2R/R2L)
Line 9: Line 9:


:: So, for example.. J is "almost a concatenative language". It has two major departures from the [http://concatenative.org/wiki/view/Concatenative%20language fundamentals] currently described at concatenative.org: J is right to left, instead of left to right. And, composing J code requires something more than whitespace. You need <code>[: code1 code2</code> instead of just <code>code1 code2</code>. And, thus, you can get statements like <code>[: a [: b [: c [: d e</code>. (A related issue is that many of the operations which would be useful on a stack might be of the form <code>(, code)</code>. So... it's just over the edge of being a concatenative language... I think. --[[User:Rdm|Rdm]] 11:51, 8 April 2011 (UTC)
:: So, for example.. J is "almost a concatenative language". It has two major departures from the [http://concatenative.org/wiki/view/Concatenative%20language fundamentals] currently described at concatenative.org: J is right to left, instead of left to right. And, composing J code requires something more than whitespace. You need <code>[: code1 code2</code> instead of just <code>code1 code2</code>. And, thus, you can get statements like <code>[: a [: b [: c [: d e</code>. (A related issue is that many of the operations which would be useful on a stack might be of the form <code>(, code)</code>. So... it's just over the edge of being a concatenative language... I think. --[[User:Rdm|Rdm]] 11:51, 8 April 2011 (UTC)
:::I think you can overlook the direction of execution for this. You could probably easily translate J to left-to-right with a few simple compiler/interpreter changes. I think that property excludes things like lazy evaluation or that some parts of the code are evaluated out of reading order. E.g. in "(2 * 3) + (4 * 5)", "2*3" and "4*5" need to be evaluated first and then the "executor" needs to "go back" and evaluate the "+" but in something like Forth the code would look like "2 3 * 4 5 * +" where everything is evaluated as it is read. An example in C-style: "function1(3, function2(4, 5))", "function1" is read, 3 is read and evaluated, function2 is read, 4 is read and evaluated, 5 is read and evaluated, function2(4, 5) is evaluated, function1(3, function2(4, 5)) is evaluated. In a concatenative language, it would be 3 4 5 function2 function1, and all parts would be evaluated as they are read from left to right. In short: it means it uses [[wp:Reverse Polish notation|RPN]] or [[wp:Polish notation|PN]]. The other fundamental...I dunno :p. --[[User:Mwn3d|Mwn3d]] 20:43, 8 April 2011 (UTC)

Revision as of 20:43, 8 April 2011

What belongs in this category? For example: Should Forth be in this category? How about languages which can be used for Concatenative Programming but which allow (or even encourage) other styles of programming? --Rdm 14:24, 7 April 2011 (UTC)

Treat it like the other programming paradigm pages. I guess we could say "if you can use this paradigm in the language and it doesn't go against the idioms of the language, it can be part of this paradigm category"? That probably deserves a vote. I'm no expert on whatever concatenative programming is, but it seems like Forth should be here based on the text on the page. --Mwn3d 14:49, 7 April 2011 (UTC)

Do assembly languages qualify as concatenative? They tend to pass data on the stack, albeit taking multiple push and pop instructions. They also support pass by reference (do concatenative languages support this, or does this mean that the language is not concatenative?)

Markhobley 16:10, 7 April 2011 (UTC)

Might this help? --Paddy3118 16:25, 7 April 2011 (UTC)
So, for example.. J is "almost a concatenative language". It has two major departures from the fundamentals currently described at concatenative.org: J is right to left, instead of left to right. And, composing J code requires something more than whitespace. You need [: code1 code2 instead of just code1 code2. And, thus, you can get statements like [: a [: b [: c [: d e. (A related issue is that many of the operations which would be useful on a stack might be of the form (, code). So... it's just over the edge of being a concatenative language... I think. --Rdm 11:51, 8 April 2011 (UTC)
I think you can overlook the direction of execution for this. You could probably easily translate J to left-to-right with a few simple compiler/interpreter changes. I think that property excludes things like lazy evaluation or that some parts of the code are evaluated out of reading order. E.g. in "(2 * 3) + (4 * 5)", "2*3" and "4*5" need to be evaluated first and then the "executor" needs to "go back" and evaluate the "+" but in something like Forth the code would look like "2 3 * 4 5 * +" where everything is evaluated as it is read. An example in C-style: "function1(3, function2(4, 5))", "function1" is read, 3 is read and evaluated, function2 is read, 4 is read and evaluated, 5 is read and evaluated, function2(4, 5) is evaluated, function1(3, function2(4, 5)) is evaluated. In a concatenative language, it would be 3 4 5 function2 function1, and all parts would be evaluated as they are read from left to right. In short: it means it uses RPN or PN. The other fundamental...I dunno :p. --Mwn3d 20:43, 8 April 2011 (UTC)