The stutter programming language

stutter is meant to be a stack frame-oriented language where basic operations are done as transformations across a stack, or stacks containing stacks (pointers to stacks, really).

It's designed for SIMD and parallel computing – it handles stack frames (and stacks containing stack frames) as data, and operations as transformations upon those stack frames.

The goal with stutter is to lay out the foundation for a language paradigm that is so necessarily structured to be parallel.

Transforms are dispatched in linear, batch, congruent or n-dimensional forms and are implemented from basic operations - things like “push”, “pop” and such can happen to every stack frame in a stack - in which case, a new stack is formed from the topmost elements of the contingent stacks.

It has several code representations, including lexrep, a lexical plaintext format inspired by M-expressions; symrep, a symbolic/formulaic TeX-alike format, and grafrep, a fully graphical representation much like an AST.

In stutter, you don't exactly have “basic blocks” or linear/synchronous code. you have stacks, and translations/transformations thereto. Such transformations can be parallelized, too. (Chances are, I'll work on making a compiler backend to emit stuttered code.)

Consider the scenario where you have a stack on one side of an operation. and it contains many stacks. You apply a transformation - this does two things:

• it advances the state, and transitions from one state to the next
• it applies the transformation, which occurs in a new, output stack or set of stacks.

(The language runtime keeps course of state for atomicity purposes, since it's a parallel and dispatching routine.) The state will advance, and all stack fragments will be collected with the state advance, so as to prevent races and mutex fault conditions Just as well - state is a dimension in the runtime, and can be rewound to an extent based on the extent of the log structure you provide for a given stack. So, you can set a stack to have an oplog (operation log) of any number of operations, and a datlog (data log) of any number of data elements, and it will simply advance pointers across memory rather than overwriting the data. This structure - in turn - is also a stack structure!

Programs in general, are just a linear flow graph to produce operations in a spatial domain (memory) - and stutter “knows” this.

stutter gets inspiration from lisp, naturally - homoiconicity included. A transformation is a set of operations to apply, and it is a stack structure itself.

stutter has “representations” - different visualizations or storage methods for the same program.

• lexrep is a lexical representation, and is formed as code, lines of code in an editor not unfamiliar to a programmer working in lisp or forth.
• symrep is symbolic representation, and conforms the stutter language to a body of symbols familiar to mathematics, to explain the set-logical relationship of operations and set members as stack frames. Best for print.
• grafrep is a graph-oriented representation, and shows stutter code as a series of nodes connected by flow or access relation to one another.
• anarep is an analytical representation best geared for understanding written or compiled stutter code. It is similar to grafrep, but with lexrep syntax embodied in nodes, and blocks of conditional jumps/loop structures being visualized.
• visrep is a purely visualization-oriented representation of a stutter program or system (the runtime state is a stutter program!) that is running.

there's also binrep, binary representation, which is compact, machine-friendly non-specific bytecode intended for use in a stutter runtime; and binarch, which is bytecode compiled from a stutter program, which is strictly intended for a given architecture or runtime environment.

in all of the above cases, rep has two meanings - “representation”, and the “REP” part of REPL. These can be used as “line”-editors and input stutter programs piece by piece.

Ideally, each of these representations will translate the same code, without any changes, losses or additions. This includes annotations, or spatial relations - those may be encoded in non-executable non-data code (“normative” languages call these “comments”.) And yes - in the stutter “bible”, comments are code - not only text! text by itself does not scale for carrying complicated concepts, as we've learned from the development of HTML and the WWW, from out of remote, text-only terminal and file services. stutter representations clearly distinguish between annotations (which would likely not execute without careful consideration, and are not part of the program code or runtime) and disabled code/data (which are executable, but not executed and do not become part of the program code or runtime). And annotations can overlap, and cover anything from a single character to an entire function domain, or beyond.

SIMD: Ideally to do SIMD work you'd want to have a stack transform run across the entire stack. This is a thing Forth can do, but it is iterative, in threaded code - rather than parallel. Factor, a successor to Forth, does a much better job with concurrency, but stack-to-register transformations for SIMD work are still a bottleneck. Lisp, in PL terms is particularly well-suited for this type of parallel processing work, but comes with its own headaches on the runtime side of things. In stutter, the transformation of data in the stack is a known, elementary quality of the language, and can be performed without any library helpers and with a streamlined and minimal amount of code.