Concatenative Languages

A concatenative programming language is a point-free language in which all expressions are functions, and the concatenation of two programs denotes the composition of the functions denoted by the two programs. -- paraphrasing https://en.wikipedia.org/wiki/Concatenative_programming_language and http://web.archive.org/web/20111007025556/http://www.latrobe.edu.au/phimvt/joy/j02maf.html

In this chapter, we may also include languages that are similar to concatenative languages but are not actually concatenative.

Forth

features

• "Forth builds on some fundamental properties that make it quite idiosyncratic and may appear quirky, due to its roots in simplicity and compactness, considering that it emerged in the microcomputer era, on machines that provided (for today's standards) severely limited capacity. Yet these attributes result in certain rather peculiar advantages. One such property is the use of reverse polish notation and the lack or eschewal of local variables. As argument-passing to subroutines and primitives takes place on the stack, factoring the code becomes nearly trivial - expressions can be taken out of context and moved into new definitions, just as in the "pointfree" style of functional programming. The emphasis on short definitions and (usually) a low subroutine call overhead additionally suggests isolating common code sequences. Local variables make this much more difficult which is why local variable facilities should be avoided." -- [1]
• "Another useful feature is the hyperstatic environment, where later redefinition of values does not change the meaning of previous uses. This greatly enhances the stability of already compiled code and reduces the pressure to find alternative names for existing definitions, if shadowing of already defined words does not present a problem for code defined later. Even though Forth provides a quite powerful namespacing system using vocabularies, it is not strictly necessary to isolate namespaces just to avoid polluting the environment, unless shadowing is an issue." -- [2]

local variables

Some Forth implementations have local variables.

" In some environments there may be more or fewer functions assigned to the call stack. In the Forth programming language, for example, ordinarily only the return address, counted loop parameters and indexes, and possibly local variables are stored on the call stack (which in that environment is named the return stack), although any data can be temporarily placed there using special return-stack handling code so long as the needs of calls and returns are respected; parameters are ordinarily stored on a separate data stack or parameter stack, typically called the stack in Forth terminology even though there is a call stack since it is usually accessed more explicitly. Some Forths also have a third stack for floating-point parameters. " -- [3]

"A Forth system is allowed to keep local variables on the return stack. This is reasonable, as local variables usually eliminate the need to use the return stack explicitly. So, if you want to produce a standard compliant program and you are using local variables in a word, forget about return stack manipulations in that word (refer to the standard document for the exact rules). " -- [4]

Adding a third stack to a Forth engine by VanNorman and Koopman says that the best use of a third stack in Forth would be for local variable (activation records, like C), but doesnt explain why this is better than just storing local variablens on the parameter stack or on the return stack

http://turboforth.net/resources/locals.html is an example of a third stack local variable implementation in Forth

https://forth-standard.org/standard/locals says "The storage resource ((for locals)) may be the return stack or may be implemented in other ways, such as in registers. The storage resource shall not be the data stack. Use of locals shall not restrict use of the data stack before or after the point of declaration. "

Stack Frames and Local Variables by George B Lyons (1985) or [5] is an example of a parameter stack implementation of local variables in Forth. I only skimmed it but it appears to be similar to (now)-standard activation records on a single stack.

Forth Dimension, volume XI, number 1 talks, amongst other thanks, about some techniques for adding local varibles to Forth. For example, on page 18, there is a description of an implementation that uses the return stack.

use of stacks

(I could be misunderstanding the following, but:) In Forth, there are typically two stacks, one called either just 'stack' or 'parameter stack', and the other called 'return stack'. The parameter stack tends to be much larger than the return stack. The return stack is the one organized with traditional 'stack frames', with return addresses, loop counters, and maybe local variables, so it looks the most like a C stack. Function calling parameters go on Forth's larger 'parameter stack'. The 'parameter stack' is manipulated much more frequently than the return stack.

retrospectives

opinions

• "per line, Forth is still a bit more error-prone than C, in my experience. In C you get enough static type checking to immediately detect something like 90% of your type errors; you get a warning if you forget to pass an argument to a function, or pass too many; the data flow of any subroutine is easily approximable without having to know the stack effect of every subroutine you call; and so on. " -- [6]
• "extensible assembly language" -- [7]
• "The good news is you can do anything with Forth, the bad news is you will probably have to do it yourself." -- David Sands
• [8]
  • response: "I think the heart of the problem is that the rudimentary ideas of forth- a stack, some stack-shuffling words, some arithmetic, control flow, and that's about it- are appealingly simple, but not enough of the language...Forth can be small, and simple, but the real gems of the language are a bit subtle. The many implications of CREATE>/DOES. Abuses of manipulating the rstack. Striking a balance between parsing words, named locals, global variables, vocabularies, and other tools to minimize twisty stack shuffling. Bending the rules at the right times. " [9]
• "The main characteristic of Forth programs that separates Forth from most other languages is the high frequency of subroutine calls." -- [10]
• "Given a data stack, subroutine calling sequences vanish...The cost of a subroutine is merely the call and return. This allows many small subroutines and more intense factoring of a problem." [11]