Talk:Stack-oriented programming

This is the talk page for discussing improvements to the Stack-oriented programming article.
This is not a forum for general discussion of the article's subject.

Put new text under old text. Click here to start a new topic.
New to Wikipedia? Welcome! Learn to edit; get help.

Article policies

Find sources: Google (books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL

Confusion in "Operations of the stack" section

I've added a disputed-section tag to the Operations of the stack section. I think it confuses the input and the stack. The input is a stream which can only be popped from. If you pop an operand from the input, you push it on to the stack. If you pop an operator from the input, you pop operands from the stack (however many the operator takes), perform the operation, then push the result on to the stack. I'll take a crack at rewriting the section. Klparrot 16:43, 3 May 2007 (UTC)[reply]

Excellent!

A very well written article, kudos! —Preceding unsigned comment added by 86.8.124.145 (talk) 12:50, 21 June 2009 (UTC)[reply]

Wrong Wrong Wrong

"A stack-oriented programming language is one that relies on a stack machine model for passing parameters"

That implies all nested block structure languages are stack oriented languages and doesn't distinguish the ones that actually have stack operators in the language. Stack orianted languages are analogous to stack based languaged. Passing parameters on the call stack is not required.

It also excludes languages that do not have parameters, for example a language of functions that operate on a character stream (or string) and manipulate stacks directly.

TREE-META is one example. CWIC another. They are metacompilers. The syntax language is syntax equations, boolean functions. Each euation expresses a goal, recognizing some language structure. They are boolean equations that analyze an input character stream and return success(true) or failure(false). Using operates like :<node> that creates a node and pushes it onto the node stack and !<number> that creates a tree, taking the top node stack entry and the top <number> of parse stack entries putting them to gather to form a tree that is pushed on that parse stack. The +[ ... ]+ make a list of parse stack entries pushed between them.

A set of syntax functions that parse an arithmetic expression building a abstract syntax tree on the parse atack:

expr = term (('+':ADD|'-':SUB) term!2)*;
term = factor (('*':MPY|'/':DIV) factor)*;
factor = id|num|'('expr')'
id .. let alphanum*;
num .. dgt dgt* MAKENUM();

expr is a function who's goal is to first recognize a term. Then some number of term may be added to or subtracted from the first expresed by:

(('+':ADD|'-':SUB) term!2)*

The Kleene star is used to express that zero or more ('+' or '-' term) may follow. If the character + is matched :ADD creates an ADD node and pushes it on the node stack. Likewise a SUB node may be created and pushed on the node atack. If nether '+' or '-' is recognized in the input stream the sequence terminates, returning success. On each iteration of the loop, after recognizing a term the !2 pops the top node off the node stack combining it with the top two objects poped off the parse stack making a tree or branch that is pushed on the parse stack. The term equation function parses products transforming them into trees or a single factor. The MPY and DIV nodes are combined with factors in the same manner as terms were in expr. The factor equation defines factor as a number, identifier or a parenthesized expr. Syntax equations consume input character stream characters recognized. Given the expression:

(5*x-3)/(y+1)

The syntax functions would create a tree on the parse stack:

          DIV
         /   \
      SUB     ADD
     /   \   /   \
  MPY     3 y     1
 /   \
5     x

The syntax equations described are from the CWIC syntax language only using the Kleenex star * instead of the CWIC zero or more $ operator. expr using $ operatot:

expr = term $(('+':ADD|'-':SUB) term!2);

The id and num .. equation are token making euations. id catalogs the parsed characters in the dictionary creating a symbol object that is pushed in the parse stack. The num equation recognizes sequence of one or more dgt. MAKENUM() is a function call that intercepts the dictionary processing. It creates a numeric object from the dgt sequence and pushes it or the parse stack.

The SYNTAX language is a goal orianted, stack oriented, string processing language. There are no parameters on the call stack or any returned. Success ot failure is commonly a processor status state that can be tested using hardware branch on condition instructions. The parse and node stacks liken to global variables. Steamerandy (talk) 22:42, 29 January 2016 (UTC)[reply]

A more fitting description

Can we change to to use stack instead:

stack-oriented programming language is one that relies on a stack (or stacks) for manipulating data and/or passing parameters. Several programming languages fit this description, notably Forth, RPL, PostScript,

Steamerandy (talk) 18:04, 21 February 2016 (UTC)[reply]

Program refinement

Are there techniques on how to refine abstract mathematical descriptions to stack-oriented programming languages? E.g. how did someone come up with the Fibonacci number example provided in this article? Reading the provided source code it is not trivial to see that it implements the Fibonacci number series. --Abdull (talk) 19:12, 9 October 2010 (UTC)[reply]

Split up article

This article should be split up in 2 articles. It confuses 2 meanings of stack-based languages: 1. Languages that define all operations as stack based (this article). 2. Languages that need stack-based processors, hence are inherently stack-based languages.

Indeed a lot of languages are stack-based: C, C++, Pascal, Modula, Smalltalk, Visual Basic. In fact all /most(?) function-based languages need a stack-based processor.

BASIC (the version with line number) is a language that doesn't necessarily need a stack-based processor (that is, when no subcalling is implemented (GOSUB)).

The above ("doesn't necessarily need a stack-based processor") is true for most languages, since stacks can easily be implemented in low level software. Non-recursive sub routines can effectively be called without a stack at all, too, through self modifying code (this is how it's done on Propeller processors, AFAIK). For conveniently parsing mathematical expressions in language such as BASIC, i think that you are stuck using an expression stack, though. 88.131.41.70 (talk) 14:08, 8 June 2011 (UTC)[reply]

True. It needs definition of stack-oriented. I mean, every function call is realized trought stack; if it is not, then either stack is "obfuscated" (trough array, special function ...) or stack is not needed (function call is optimized / inlined). Daemonicky (talk) 13:23, 23 August 2011 (UTC)[reply]

Why is Assembly language stack-oriented?

I am thinking about x86 assembly (acumulator and registry based machine language). I heard that there exists some other machine lanugages, some of them are list oriented (or perhaps there are even stack oriented?).

I know it (x86) can operate with stack (there is "stack pointer"). There are only operations of add (push) and remove (pop). And something like reset stack (pop-all ?). TMK there is no compute operation on top elements of stack and return result to stack ...

I am not sure if that counts as stack-oriented since every programming language with stack data structure would apply too; I believe I missunderstand the reason. Could somebody explain to me why is Assembly stack-oriented?

Thanks :) — Preceding unsigned comment added by Daemonicky (talk • contribs) 13:18, 23 August 2011 (UTC)[reply]

I do not see how assembly can in any general sense be stack anything. There are computers with no hardware stack of any kind. Though most today have at least a call stack. Though that does not exclude stack orianted assembly languages for specific stack machines.Steamerandy (talk) 05:09, 7 September 2018 (UTC)[reply]

Requested move 21 May 2018

The following is a closed discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review. No further edits should be made to this section.

The result of the move request was: moved as requested per the discussion below. Dekimasuよ! 07:09, 29 May 2018 (UTC)[reply]

Stack-oriented programming language → Stack-oriented programming – like the other programming paradigms Horcrux92 (talk) 23:47, 21 May 2018 (UTC)[reply]

Support per WP:CONSISTENCY and WP:CONCISE, and even WP:PRECISE in that the current name is over-precise for no reason. It doesn't really seem to match the scope, anyway. This isn't an article about a programming langauge named "stack-oriented programming", but a type of programming language (i.e., a paradigm, as the nom said). — SMcCandlish ☏ ¢ 😼 02:25, 23 May 2018 (UTC)[reply]
Support for consistency. -- Beland (talk) 18:31, 23 May 2018 (UTC)[reply]

The above discussion is preserved as an archive of a requested move. Please do not modify it. Subsequent comments should be made in a new section on this talk page or in a move review. No further edits should be made to this section.