# Misty: a dynamic distributed actor language from Douglas Crockford Source: https://mistysystem.com/doc/introduction.html ## Summary Douglas Crockford presents Misty, a dynamic, general-purpose, transitional, secure, distributed actor language with a gentle syntax intended to benefit students and advanced features such as capability security and lambdas with lexical scoping. The language supports the Actor model of distributed computation and also a more conventional functional-style model with mutation, similar in some ways to JavaScript, which the article says makes it easier for industry to accept than a pure actor language. Misty enforces strict whitespace rules, with indentation in increments of 4 spaces and only one allowed formatting convention. The article states that Misty only allows mutation through the assign statement and that the language strives for, but does not achieve, purity. ## Article Misty Programming Language:Introduction Public Domain 2026 Douglas Crockford The Misty Programming Language is a dynamic, general-purpose, transitional, secure, distributed actor language. It has a gentle syntax that is intended to benefit students, as well as advanced features such as capability security and lambdas with lexical scoping. The grammar of the language is expressed in McKeeman Form. Overview The Misty System supports the Actor model of distributed computation. It is a transitional language because it also supports a more conventional model with features of a functional language with mutation, similar in some ways to JavaScript. The intention is that a transitional language will be easier for industry to accept than a pure actor language, even if a pure actor language is more deserving of adoption. A misty application can be made up of many misty actors, possibly distributed over many machines. The misty actors communicate by sending messages. Misty uses a capability model to secure the application. In a capability system, programs and modules are only given authority on a need-to-do basis. Part of the responsibility of a program is to manage the capabilities of its modules. A misty actor runs a misty executable (mex). An executable is made from a misty program source text (mst) and some misty modules (msb) and some build specifications (msp). The role of a program is to manage the work of the modules. Some modules are built into the system and are freely available. Some modules are more restricted. modules can be provided by third parties. The capability model makes it possible to include third party modules securely. Sources and specifications are kept in the program shop. The build specifications determine build-time options such as conditional compilation and access to logs. Build specifications can also provide linkages to capabilities outside of the Misty System, such as access to file systems and display systems. Misty programs should be designed for a distributed environment in which failure is always an option. Actors are expected to fail early and often, informing concerned actors as they halt. Because they fail to a known state, recovery and resumption can be straightforward. Space The language is quite strict in its use of spaces and indentation. In most programming languages, code spacing and formatting are under specified, which leads to many incompatible conventions of style, some promoting bug formation, and all promoting time-wasting arguments, incompatibilities, and hurt feelings. Misty instead allows only one convention which is strictly enforced. This liberates programmers to focus their attention on more important matters. Indentation is in increments of 4 spaces. The McKeeman Form is extended by three special rules to make this possible: indentation The spaces required by the current nesting. increase_indentation Append four spaces to the indentation. decrease_indentation Remove four spaces from the indentation. The indentation is the number of spaces required at the beginning of a line as determined by its nesting level. indent increase_indentation linebreak outdent decrease_indentation linebreak The linebreak rule allows the insertion of a comment, ends the line, and checks the indentation of the next line. Multiple comments and blank lines may appear wherever a line can end. linebreak optional_comment linefeed more_linebreaks more_linebreaks linebreak indentation space ' ' linefeed '000A' There are many places where the language expects an end of line, such as at the end of a statement. Misty is strict about whitespace in order to eliminate the need for, debate over, and circumvention of coding standards. Misty starts with the pretty convention of JSON formatting. For example, JSON allows this compact JSON text {"one":1,"array":[1,2,3],"text":"hello"} to be presented more pleasingly as { "one": 1, "array": [ 1, 2, 3 ], "text": "hello" } Misty record literals take this further by eliminating the comma, and eliminating quotes on field names in most cases. {one: 1 array: [1 2 3] text: "hello"} { one: 1 array: [ 1 2 3 ] text: "hello" } Misty uses the same convention with (left paren and )right paren in argument lists and expressions. In an open argument list, each argument goes on its own line. my_button.on( "click" function (event) { call event.done() call take_action() } ) In complex expressions, parens can allow a line break. (See operators.) def atan(slope) ( math.sine( slope / (math.sqrt( slope * slope ) + 1) ) ) assign progress: ( result + (radicand / result) ) / 2 A comment begins with an #octothorpe and ends with the end of the line. Comments are used to provide context and motivation to help humans understand the programming. The Misty System strictly ignores all comments. optional_comment "" spaces '#' comment_characters spaces "" space spaces comment_characters "" comment_character comment_characters comment_character '0020' . '10FFFF' Names Names are used to identify functions, function inputs, fields, variables, modules, and programs. A name starts with a letter. A name may contain any number of letters and digits. A name may contain _underbar as a separator. Names may end with ?question mark which is used to indicate predicate functions and truth values. name letter subsequent subsequent "" '?' letter_or_digit subsequent '_' letter_or_digit subsequent letter 'A' . 'Z' 'a' . 'z' digit '0' . '9' letter_or_digit letter digit There are no reserved words. Purity The Misty language strives for, but does not achieve, purity. It is a transitional language, so mutation and side-effects are tolerated, but not encouraged. Mutation is only allowed by the assign statement. The word assign is required in the statement. This allows for using = equal sign correctly as the equality operator. When calling a function only for its side-effects, the call statement must be used. This is quite different than conventional languages whose syntax is optimized for mutation and side-effects. For example, JavaScript has 20 assignment operators if you count ++ and -- twice, which you should, and it allows them all to be used in expression position as well as statement position. ## Comments **timdaub.eth**: > The language is quite strict in its use of spaces and indentation. In most programming languages, code spacing and formatting are under specified, which leads to many incompatible conventions of style, some promoting bug formation, and all promoting time-wasting arguments, What do you mean? **rvolz.eth**: It's basically why many modern languages, like Go and Rust, provide a code formatter. The arguments are similar: >>> Rustfmt is a formatting tool that enforces the standard Rust community code style. It automatically reformats Rust code according to a consistent style, helping to maintain readability and prevent arguments about coding style in collaborative projects