|Sources for development of this article may be located at|
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)
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 orianted 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 lenguages that do not have parameter. For example a language of functions that operate on a character stream (or string) and manipulates 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:
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:
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)
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,
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)
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. 22.214.171.124 (talk) 14:08, 8 June 2011 (UTC)
- 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)
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?
- 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)