8 ms·

I'm a bit confused why "using postfix notation" is considered a programming paradigm - I'm semi-fond of post-fix notation (it is the second best notation after

by munk-a 7y ago

I'm a bit confused why "using postfix notation" is considered a programming paradigm - I'm semi-fond of post-fix notation (it is the second best notation after prefix after all) but[1] it's incredibly trivial to convert between prefix and postfix notation and most programming language expressions use prefix already - it's just the infix ones that are a bit weird... Allllso, expressing if statements without any infix notation is sort of terrible, I've never seen an option to do it that isn't incredibly misleading or confusable. A core question, though, is why? Is tab-oriented programming have a wikipedia page where programs are written predominantly using tab stops instead of spaces? It's honestly a very similar sort of distinction to make. 1. I'm trying not to stray too far into all turing complete languages are turing complete and thus difference is meaningless land.

triska 7y ago
As I see it, the key characteristic of stack-oriented programming is not that it "uses postfix notation". Rather, the key characteristic is that there is an important implicit feature available, namely the stack (or, as for example in the case of PostScript, several stacks), by which arguments can be passed along. As a consequence, you get a form of compositionality of language elements that is not available in languages that lack this feature: A language element may consume, change and create entities on the stack, and the next language element can pick them up implicitly. This often allows very concise and elegant code, and can also be interpreted very efficiently.
- jerf 7y ago
  Best advocacy I know of: http://evincarofautumn.blogspot.com/2012/02/why-concatenative-programming-matters.html http://evincarofautumn.blogspot.com/2012/02/why-concatenativ... Presented by way of being an interesting link, and the educational nature of reading the best arguments in favor of something. I haven't done anything in concatenative programming in about 20 years, since I left math class and didn't need my HP 48G anymore.
- munk-a 7y ago
  That's quite helpful, it may be a lack of in-depth reading of the page but the persistence and implicit passing of computation between operations is helpful to understand the differentiation. In more classic procedural languages you'll usually have a function stack that is being pushed and popped two but actual program values are handled using entirely arbitrarily loaded references that get juggled around as needed for computation - does stack programming often have a similar concept to frame popping when an issue with I/O or something similar is encountered or do we just get a panic that aborts computation?
  - triska 7y ago
    To get a glimpse of stack-oriented programming, I really like and recommend PostScript, because this also automatically introduces you to a widely used programming language with important practical applications, and it's also great fun to learn. So, for instance, let's elicit an error using Ghostscript, a freely available and efficient PostScript interpreter: $ gs GPL Ghostscript 9.27 (2019-04-04) ... At the "GS>" prompt, I now define "f" via: /f { /hello g } def Note that "f" refers to "g", which is not yet defined. Therefore, when I then invoke "f" via: GS>f I get an error: Error: /undefined in g And importantly, the stack is retained, so I can inspect it at this point, interactively, using for example "pstack": GS<1>pstack /hello This shows that /hello is still on the stack. From there, we can resume in various ways, for example by clearing the stack (with "clear"), by redefining and reinvoking "f" etc.
    - haolez 7y ago
      Is PostScript used beyond page description? I'm really curious :)
      - PeCaN 7y ago
        Sun made a windowing system based on (Display) PostScript way back https://en.wikipedia.org/wiki/NeWS https://en.wikipedia.org/wiki/NeWS
      - hnick 7y ago
- rixed 7y ago
  Sounds like automatic currying in FPLs is equivalent to some of that.
smabie 7y ago
Postfix notation isn't really related to stack programming, you could just as easily read the programs right-to-left and have prefix notation. Something like K/Q but with stacks. Anyways, stack based languages are a real distinct category, just like OO or FP or array-based languages or whatever. If you look at forth code for example, especially written by Moore, it's some... pretty crazy shit. I do agree that conditionals are pretty annoying to read using stack based languages, but they are used a lot less often due to the implicit "branching" a stack context provides.
olooney 7y ago
For a stack oriented language, postfix is execution order. Consider the program "2 3 +". This is really three instructions: 1. Push the literal 2 onto the stack 2. Push the literal 3 onto the stack 3. Execute the Plus Operation Therefore, there is no need to use a compiler, or even Dijkstra's shunting-yard algorithm[1], to reorder the statements for execution. This makes it extremely easy to write a compiler or interpreter for a stack-oriented language with postfix syntax: you never have to do any parsing at all, you just execute (or emit byte code) for each token as it comes, never needing to look forwards or backwards even a single token. [1]: https://en.wikipedia.org/wiki/Shunting-yard_algorithm https://en.wikipedia.org/wiki/Shunting-yard_algorithm
astrobe_ 7y ago
"Paradigm" is a conveniently abstract word. I would say that RPN is part of a paradigm - and if you pardon my bias I would say the Forth paradigm, really. The stack is part of a strategy of complexity reduction that start at the compiler/interpreter level.

by munk-a 7y ago

triska 7y ago

As I see it, the key characteristic of stack-oriented programming is not that it "uses postfix notation". Rather, the key characteristic is that there is an important implicit feature available, namely the stack (or, as for example in the case of PostScript, several stacks), by which arguments can be passed along. As a consequence, you get a form of compositionality of language elements that is not available in languages that lack this feature: A language element may consume, change and create entities on the stack, and the next language element can pick them up implicitly. This often allows very concise and elegant code, and can also be interpreted very efficiently.

jerf 7y ago
Best advocacy I know of: http://evincarofautumn.blogspot.com/2012/02/why-concatenative-programming-matters.html http://evincarofautumn.blogspot.com/2012/02/why-concatenativ... Presented by way of being an interesting link, and the educational nature of reading the best arguments in favor of something. I haven't done anything in concatenative programming in about 20 years, since I left math class and didn't need my HP 48G anymore.
munk-a 7y ago
That's quite helpful, it may be a lack of in-depth reading of the page but the persistence and implicit passing of computation between operations is helpful to understand the differentiation. In more classic procedural languages you'll usually have a function stack that is being pushed and popped two but actual program values are handled using entirely arbitrarily loaded references that get juggled around as needed for computation - does stack programming often have a similar concept to frame popping when an issue with I/O or something similar is encountered or do we just get a panic that aborts computation?
- triska 7y ago
  To get a glimpse of stack-oriented programming, I really like and recommend PostScript, because this also automatically introduces you to a widely used programming language with important practical applications, and it's also great fun to learn. So, for instance, let's elicit an error using Ghostscript, a freely available and efficient PostScript interpreter: $ gs GPL Ghostscript 9.27 (2019-04-04) ... At the "GS>" prompt, I now define "f" via: /f { /hello g } def Note that "f" refers to "g", which is not yet defined. Therefore, when I then invoke "f" via: GS>f I get an error: Error: /undefined in g And importantly, the stack is retained, so I can inspect it at this point, interactively, using for example "pstack": GS<1>pstack /hello This shows that /hello is still on the stack. From there, we can resume in various ways, for example by clearing the stack (with "clear"), by redefining and reinvoking "f" etc.
  - haolez 7y ago
    Is PostScript used beyond page description? I'm really curious :)
    - PeCaN 7y ago
      Sun made a windowing system based on (Display) PostScript way back https://en.wikipedia.org/wiki/NeWS https://en.wikipedia.org/wiki/NeWS
    - hnick 7y ago
rixed 7y ago
Sounds like automatic currying in FPLs is equivalent to some of that.

smabie 7y ago

Postfix notation isn't really related to stack programming, you could just as easily read the programs right-to-left and have prefix notation. Something like K/Q but with stacks. Anyways, stack based languages are a real distinct category, just like OO or FP or array-based languages or whatever. If you look at forth code for example, especially written by Moore, it's some... pretty crazy shit. I do agree that conditionals are pretty annoying to read using stack based languages, but they are used a lot less often due to the implicit "branching" a stack context provides.

olooney 7y ago

For a stack oriented language, postfix is execution order. Consider the program "2 3 +". This is really three instructions: 1. Push the literal 2 onto the stack 2. Push the literal 3 onto the stack 3. Execute the Plus Operation Therefore, there is no need to use a compiler, or even Dijkstra's shunting-yard algorithm[1], to reorder the statements for execution. This makes it extremely easy to write a compiler or interpreter for a stack-oriented language with postfix syntax: you never have to do any parsing at all, you just execute (or emit byte code) for each token as it comes, never needing to look forwards or backwards even a single token. [1]: https://en.wikipedia.org/wiki/Shunting-yard_algorithm https://en.wikipedia.org/wiki/Shunting-yard_algorithm

astrobe_ 7y ago

"Paradigm" is a conveniently abstract word. I would say that RPN is part of a paradigm - and if you pardon my bias I would say the Forth paradigm, really. The stack is part of a strategy of complexity reduction that start at the compiler/interpreter level.