In Haskell a data type is a set of values. A data type can be defined as an instance of one or more classes; a class declares polymorphic operators and methods which a type instance must implement. Monad is a class with operations which control sequential execution; the do notation is a very convenient way to express computations in a seemingly imperative style as long as they involve values from types which are instances of Monad. Implementing the Monad operations makes it possible to abandon sequential execution, e.g., there can be a reaction to failure, and state can be maintained separately from sequential execution, e.g., to trace operations, support a form of assignment, or perform input and output. Specifically, Haskell uses the IO monad to separate stateful input/output from stateless, "pure" functional programming.

Many imperative languages such as C# , Groovy , Java , JavaScript , Python , Ruby , and of course all variants of Lisp , support functions as first-order values. Some of these languages, e.g., JavaScript and Lisp, are dynamically typed, others, like Haskell or C#, support some form of type inference; either variant of typing greatly simplifies the use of functions. However, but for Haskell, most languages do not integrate monadic types with special language constructs.

If a programming language supports assignment, input/output, and some kind of global storage, there is no pressing need for monads because state can be maintained rather explicitly. However, this web page shows that monads can be created given only functions as first-order values. The web page illustrates that -- at least in the area of parsing -- monads are a very useful way of structuring computation. Specifically, this web page shows how to program recursive descent parsers directly from LL(n) grammars based on an infrastructure which requires only regular expressions and functions as first-order values. It also extends JavaScript with a notation similar to Haskell's do notation which can be viewed as the input language for a parser generator, but which can be used for other monadic computations as well. There is a short discussion how the notation is used to convert itself into JavaScript, i.e., how the parser generator is implemented. Finally, there is an implementation of an interpreter for a very small, conventional programming language which serves as an example for other monadic computations.

The web page provides tools and examples for those who need to implement small languages using JavaScript, and it suggests by example how the tools can be quickly implemented in other languages which support regular expressions and functions as first-order values.

This section describes Monad, a base class for monadic classes in JavaScript. For the system described here a monadic value is an object which contains a state function:

Given a monadic value, its state function can be applied to a state value:

Unlike Haskell, JavaScript is a dynamically typed language, i.e., neither the type of state nor the return type of the state function have to be specified; therefore, Monad can provide the functionality of all state-function-based monadic classes. By convention in this system, on success a state function will return a collection with two properties, the new state and the value encapsulated by the monadic value which contains the state function; on failure a state function will return a collection with a fail property, e.g., with an error message. With this convention Monad combines the capabilities of Haskell's Either and state-function-based monads.

Given two monadic values, orElse creates a new monadic value in the same class as the receiver. The new value contains a state function which will apply the receiver's state function or -- only in case of failure -- the state function contained in the argument value for orElse:

Loosely speaking, monadic values "are" state functions and orElse combines them for alternative execution. It should be noted that either state function is applied to the same incoming state. In the terminology of Haskell, orElse is the mplus operation of the MonadPlus class.

Intuitively, the bind operation, denoted as >>= in Haskell's Monad class, combines two monadic values, i.e., state functions, for sequential execution (and creates a scope for a result value). However, sequential execution has to be controllable: it must be guaranteed that the first state function is executed first, and it should be possible to suppress executing the second state function if the first one fails. Additionally, and unlike orElse, if both state functions succeed the final state and value should depend on both functions.

Therefore, the method andThen does not combine two monadic values directly. Instead, it accepts as an argument a function which is expected to accept a value property produced by the receiver's state function and return the monadic value which andThen is to combine with the receiver:

The method andThen returns a monadic value in the same class as the receiver containing a state function which first applies the receiver's state function. If successful, the result.value is used to produce the second monadic value and its state function is applied to the result.state. Loosely speaking the final value results from composing both state functions, the incoming state is sent only to the first state function, and its result state is sent to the second state function.

Monad.subclass is a convenience function to create constructors for new monadic classes which inherit the methods described thus far. (Strictly speaking, there is no inheritance among classes in JavaScript; however, this web page uses the terminology of Java. In this parlance Monad.subclass is a class method -- which is not inherited by the new monadic classes.)

Monad is the superclass of all monadic classes. Therefore, the new constructor result is chained to the Monad constructor and a Monad object is set up as the prototype of the new class. The purpose of the prototype is to inherit andThen, apply and orElse; therefore, the stateFunction is deleted from the prototype. Finally result is added as constructor to the prototype and returned.

A monadic class should contain some monadic values. Therefore, subclass creates a few class methods for the new class which create monadic values. succeed creates an instance of the new class for its argument value, i.e., it returns a monadic value containing a state function which will return a collection with the argument value of succeed and the incoming state:

dump serializes a collection and is connected as toString method for the result of the state function defined for succeed, but it can also be used as a class method to display its argument:

The class method fail creates a monadic value with a state function which will return a collection with the argument of fail:

succeed and fail are the return and fail operations required by Haskell's Monad class. fail is also the operation mzero of MonadPlus.

Finally, two more kinds of monadic values will turn out to be useful and are defined as value of a class variable and results of a class method, respectively. get is a monadic value containing a state function which returns the incoming state as both, value and state; it is used to expose the current state within a monadic computation:

put returns a monadic value containing a state function which ignores the incoming state and returns the arguments of put as the new value and state; it is used to set the current state from within a monadic computation:

To simplify debugging, all result values are connected to dump.

Operations of Monad and MonadPlus should satisfy certain axioms which can now be tested using Monad. The tests are cumulative and can be edited and executed below. With a stand-alone implementation of JavaScript such as Rhino or SpiderMonkey the examples can be executed interactively once the Monad definition from the previous section is loaded.

Axioms is a monadic class and m is a monadic value for which the axioms will be tested; Axioms is also used as a namespace to avoid global clutter:

Used as a class method above, dump shows that m contains a state function which will return the argument 'hello' used to create m and the incoming state. JavaScript cannot show that the free variable value of the state function has in fact closed over the argument given to succeed when m was created.

Implicitly used to convert to a string below, dump shows that the result of applying the state function contained in m combines 'hello' and the incoming state 's'.

Loosely speaking, if one considers monadic values as a set with an operation andThen the function succeed has to act as a right unit:

This shows that the two monadic values m and m.andThen(succeed) exhibit the same behavior. However, they contain very different state functions:

Similarly, a monadic value constructed with succeed acts as a left unit. Given some function f which returns a monadic value and some argument 'hello':

The monadic value f('hello') exhibits the same behavior above as the monadic value resulting from combining succeed('hello').andThen(f) below:

The third axiom requires andThen to be an associative operation. Continuing the example here is an illustration which involves a monadic value constructed with succeed:

The original definition of f uses get which copies the incoming state 'hello' as value and g uses succeed to append ' world!' to it. The chain above is executed from left to right, but the functions can be combined to change this:

The example shows that (at least for these specific monadic values and functions) the behavior does not depend on whether m is first combined with g and the result is combined with f (association from the left), or m is combined with the result of combining g with f (association from the right).

MonadPlus operations are also expected to satisfy certain axioms: mzero should act as a right and left zero in combinations with >>= and mplus, i.e., fail, andThen and orElse should act just like false combined with preemptive and and or operations in a programming language.

x and false is false:

x or false is x:

false and x is false:

false or x is x:

It should be stressed that the examples do not prove that the methods and values inherited from Monad satisfy the axioms. The examples just illustrate that the axioms are observed for a specific monadic value and for the function g defined earlier; many values and functions can be inserted to check again.

Ideally, a parser examines an input string and produces a value, e.g., the input string might contain an arithmetic expression and the value is a tree representing the expression, or even the value of the expression. A parser is often unable to complete the task -- it might understand just an initial part of the input or even fail completely. Therefore, it makes sense to require that a parser function accept input and return a value and the remaining input if successful, and a string with an error message if not. In other words a parser function is a state function and the state is the input to be examined.

This section describes a class Parser with monadic values containing parser functions:

This section owes much to Hutton's excellent book . He starts with parsers which accept a single character or even nothing at all and builds up to parsers which accept numbers or identifiers optionally surrounded by white space. However, JavaScript supports regular expressions which simplify the description of low-level building blocks for complex parsers. For example, the following collection suffices to describe the pieces which can be combined to form arithmetic expressions:

A collection with a few more properties can already describe a small programming language:

The property skip has special significance as discussed below; all other property names can be chosen at will. Every property has a regular expression as a value and all but skip can themselves have a property reserved with a list of exceptions to indicate matches with a special meaning. A parser always examines the initial part of the input; therefore, the regular expressions are more efficient if they are anchored with ^.

reserved allows to create parsers for specific symbols and for all other symbols matching a pattern. For example, many programming languages use the same conventions for user-defined identifiers and language-specific reserved words. Therefore, the regular expression specified for a property like word is assumed to match both kinds of input. If a match of word is contained in word.reserved it is accepted only by a parser generated for a reserved word, not by the parser which accepts anything else matched by the regular expression specified for word.

Parser.Factory is a class of objects which can produce monadic Parser values. A factory object is constructed with a collection of properties as described above. Optionally, a trace flag can be specified:

The actual analysis of input, i.e., the body of the parser function, can be delegated to a common method scan which accepts input and a regular expression and returns a collection with the matched text as value and the remaining input as state:

The original input can be a string, but the remaining input will be a collection with the remaining string as text and the line number where this string begins as lno. If there is no match, or if the match is not at the beginning of the input, the result is an error message which includes the current line number in the input:

Either result is connected to dump to simplify debugging, for example:

The factory instance variable skip references a parser. For every other property in the collection a method is added to the factory which will create a parser. If there is a skip property, these parsers will discard a match before they consider the rest of their input:

For example, the parser factory created from the arithmetic collection is sufficient to deal with arithmetic expressions:

If the scan method finds a match the result value can be filtered with an argument specified to the generator method.

If there is a reserved list for a property the corresponding method creates a parser only if the argument, if any, is in the list. The language collection includes reserved words:

Parsers are objects which can be applied to accept input. Parsers can be created by generator methods of a parser factory. The example shows that frequently used parsers can be saved, e.g., as instance variables of the parser factory; the instance variable can even replace the generator method.

If there is no reserved list for a property, a parser can be generated without an argument to accept any input matching the corresponding regular expression, or it can be generated with an argument to accept only input which must match the regular expression and must equal the argument. If there is a reserved list, a parser can be generated with an argument from the list to accept input equal to the argument; if it is generated without an argument it accepts any match of the regular expression which is not in the reserved list. In any case, if there is a skip expression, input matching skip is first discarded.

In summary, regular expressions are used to partition input, skip indicates input to be discarded, generator arguments restrict what partitioned input is acceptable, and each reserved list describes special cases to be considered once input has been partitioned.

This section discusses how simple parsers can be combined to create parsers which accept input with a more complicated structure. Consider a grammar for arithmetic expressions:

      term:    number | '(' sum ')';
      product: term '*' product | term '/' product | term;
      sum:     product '+' sum | product '-' sum | product;
    

A Parser.Factory based on the arithmetic collection introduced in the preceding section produces parsers for number and the literal operator symbols used in this grammar. Parsers are monadic values and can be combined with andThen for sequential execution and orElse for alternatives, i.e., those two operations are sufficient to construct parsers for the nonterminals term, product, and sum in this grammar, simply by translating the grammar:

Each terminal symbol of the grammar such as number or '(' is translated into a parser generated from a pattern collection by Parser.Factory.

Each nonterminal symbol such as term is translated into a parser combined from other parsers: a sequence of items in the grammar is combined using andThen, alternatives are combined using orElse. The example above shows that the parsers can often be applied before all other parsers have been defined.

With a preprocessor-supported notation as described below it will be much easier to specify this nest of function calls. Nevertheless, the result is a functioning parser for arithmetic expressions -- it produces a value and the remaining input for a correct phrase as shown above, and an error message in case of failure:

expr expects that the input string contains only numbers, operators, and parentheses in the proper order, and optionally white space, nothing else. In the example above the expression is followed by a semicolon on a second line to demonstrate that an error message contains the current line number.

It should be noted that the order of the alternatives is important. orElse does not implement backtracking, it only activates the second parser if the first one fails. For example, the alternatives of sum could be reordered:

      sum:     product | product '+' sum | product '-' sum; 
    

which translates into

The error method is (temporarily) overridden above so that it produces output as soon as there is any failure. Execution with the original input shows that only the operators of product are searched. The two failures happen when product tries to find a multiplication operator before it settles for a simple term. While badSum succeeds, it does not accept the entire expression because the first alternative succeeds with a simple product. Therefore, when a grammar is translated into parsers, the longer alternatives have to be specified first.

The example suggests that it is inefficient when a failure happens in the middle of an alternative: orElse starts over with the original input, i.e., in this case 1 is parsed by number and term a total of three times before product finally succeeds. The grammar can be changed to avoid this:

      betterProduct: term mulDivs;
      mulDivs:       '*' betterProduct | '/' betterProduct | /* empty */; 
    

An empty alternative succeeds without accepting input, i.e., without changing state:

with (Parser) is needed in this code because Parser provides the method succeed.

Extended BNF, pioneered by Nicklaus Wirth for Pascal , introduces constructs to describe a grammar and avoid recursion. A popular style for the constructs is usually used in Internet RFCs : items can be grouped with parentheses, optional items are marked with a suffix ?, and the suffixes * and + indicate that an item can be repeated zero and one or more times, respectively. The grammar for arithmetic expressions and the translation to parsers could be changed as follows:

      betterSum: product summands?;
      summands:  ('+' product | '-' product)+;
    

This translates into:

Often, the parentheses need not be translated explicitly; here they are implied by the fact that method application is left-associative. The implementation uses two of the Parser methods optional, some, and many corresponding to the suffixes ?, +, and *, respectively, which can be applied to any Parser value:

Given a parser, optional creates a new parser with a parser function which will execute the receiver's parser function and return the result if successful; otherwise it will return the argument value (or an empty string) and the original input as state.

Given a parser, some creates a new parser with a parser function which will execute the receiver's parser function one or more times and return a list with the results as value and the remaining input as state; the parser function fails if the receiver function does not succeed at least once.

Given a parser, many creates a new parser with a parser function which tries to execute the receiver's parser function one or more times and return a list with the results as value and the remaining input as state; the parser function will always succeed but the resulting value list is empty and the input state is unchanged if the receiver's parser function does not succeed at least once.

The implementation of some uses the fact that andThen combines a parser and a function and passes the value resulting from successful execution of the receiver's parser function as argument to the function. In the chain of andThen above the function definitions are nested so that all parameter scopes extend to the end of the innermost function, i.e., any parameter can be used from the point where it is introduced and in all the nested functions.

The implementations of the methods above suggest that a parser function need not always return a string as value. In fact, some and many arrange to return lists and optional can arrange to return an arbitrary value. This can be exploited, e.g., to interpret an arithmetic expression as it is parsed. Here is a grammar expressed with extended BNF:

      term:    number | '(' sum ')';
      product: term ('*' term | '/' term)*;
      sum:     product ('+' product | '-' product)*;
      expr:    sum eof;
    

This translates into the following interpreter:

Where appropriate, functions passed to andThen have been given a parameter to bind the value produced by the preceding parser and another andThen has been added to each sequence (except to the first alternative of term) with a function which uses succeed to return a value for the recognized expression phrase.

The parsers created using many above return lists of curried functions, e.g., the phrase - 10 will return

      function (x) { return Number(x) - 10; }
    

and many creates a list of such functions. foldl is a generally useful class method of Parser which takes a value and a (possibly empty) list of curried functions and applies them left to right to accumulate the result value, i.e., foldl interprets left associative operation sequences:

The interpreter for arithmetic expressions shown in the preceding section works, but the implementation is rather error-prone due to the excessive use of nested functions as required by andThen. Haskell's do notation hugely simplifies specifying computations with monadic values and this section discusses something similar which is needed to make monadic values palatable in JavaScript. The grammar for arithmetic expressions

      term:    number | '(' sum ')';
      product: term ('*' term | '/' term)*;
      sum:     product ('+' product | '-' product)*;
      expr:    sum eof;
    

can be translated into an interpreter much more literally using a notation for monadic values:

{{{ and }}} enclose a computation which will return a monadic value. The computation consists of one or more alternatives, separated by |||. An alternative consists of one or more pieces of JavaScript code. Each piece must deliver a monadic value and must be terminated with a semicolon. (Depending on context JavaScript allows a newline to act as a statement terminator but this is not supported here.)

Each piece of JavaScript code may be preceded by an identifier and <-. In this case the value wrapped by the monadic value produced by the JavaScript code is bound to the identifier, e.g.,

      x <- succeed(y);
    

will bind the value y to the identifier x. The scope of the identifier extends from the next monadic value to the end of the alternative (i.e., x above cannot be used in place of y but it can be used beyond succeed); the identifier may be shadowed within its scope.

The notation can be nested and suffixes such as optional, many, and some can be applied. This helps to translate the rest of the grammar into monadic notation:

The preprocessor described in a subsequent section converts this notation into the code developed in the previous section.

Some browsers (most notably Apple's Safari) and the JavaScript interpreter SpiderMonkey seem to restrict the JavaScript call stack depth and cannot preprocess much larger examples. Fortunately, Firefox and the JavaScript interpreter Rhino do not appear to be restricted.

It is often convenient to represent input as a tree for further processing. For example, the code from the preceding section can be changed slightly to produce a tree for an arithmetic expression:

term remains almost unchanged: a number is represented as a Leaf node and whatever sum computes is the result of term.

The functions created in product and sum are changed to create tree nodes and connect their descendants rather than immediately evaluate the various operations. (The preprocessing area shows the entire tree builder, not just the translation of expr, sum, and product.)

Tree nodes are so simple that a static factory method Parser.makeTreeClasses can arrange for each property of a collection such as Tree above to be a JavaScript object constructor; by convention only those properties are modified to be tree classes where the name starts with an upper-case letter:

makeTreeClasses installs a constructor which simply saves its arguments as content. If makeTreeClasses is called with a second argument which evaluates to true, the constructor will immediately display the new object; this is quite helpful to debug a tree builder.

makeTreeClasses stores the className as a shared instance variable. This makes it possible to implement a static dumpTree function which is connected as toString for each of the generated classes:

dumpTree returns the class name followed by an indented list of the values in content, if any. The list accounts for nested arrays and nested objects, but nested objects are expected to implement toString in a compatible fashion.

The monadic notation is embedded in JavaScript and a JavaScript interpreter could be extended to deal with the notation directly. However, especially for prototyping purposes, it is much simpler to convert the notation into JavaScript prior to interpretation. This section discusses the significant parts of a preprocessor implementation; the complete code of the preprocessor is available for editing (and self-preprocessing) on a separate edit page.

The monadic notation can be described by a grammar which concentrates on the monadic computations and obscures most of JavaScript:

      jsm:      term+ eof;
      term:     monad | blanks | word | quoted
          |     '(' term* ')' | '[' term* ']' | '{' term* '}' | symbol;
      monad:    '{{{' mvalues ('|||' mvalues)* '}}}';
      mvalues:  mvalue+;
      mvalue:   blanks? (word blanks? '<-')? term+ ';' blanks?;
    

The grammar shows which parsers (such as blanks) have to be created with Parser.Factory and which literal symbols have to be accepted by one or more of these parsers. Describing the parser factory is the first step to implementing the preprocessor.

jsm is JavaScript code and can specify monadic values using monad phrases. The preprocessor normalizes white space, i.e., it replaces comments and multiple blanks by single blanks and it preserves all newline characters for the benefit of JavaScript so that there is a trivial correspondence between input and output lines. Therefore the parser factory description does not contain a skip property:

blanks describes the white space and comments which have to be normalized for output. word describes identifiers to which the monadic notation can bind wrapped values. quoted describes strings and regular expressions so that their content cannot be mistaken for symbols. Finally, symbol describes the significant multi-character symbols and all single characters which cannot start an identifier -- this does include single digits which make up numbers.

A reserved list is specified to distinguish symbols which are significant for the grammar from the other symbols which the pattern matches:

Unfortunately, just like strings, regular expressions may contain other characters which then loose their syntactic meaning, but regular expressions are harder to detect than strings because the leading slash may also appear alone as a division operator. To simplify the problem, the preprocessor requires that a regular expression must be enclosed in parentheses without intervening blanks.

The grammar can now be translated into the notation which it describes using methods such as many, etc., for the suffixes. For example:

Once a preprocessor is available, this code can be converted to JavaScript and executed to check if input conforms to the grammar. Unfortunately, for the initial version of the preprocessor this code had to be hand-translated using andThen, etc., in the style shown before.

The code fragment hints at a complication: term is used three times in the grammar: at the level of JavaScript code in jsm, at the level of monadic code in mvalue as shown above, and recursively, enclosed by various parentheses in term itself:

      term: monad | blanks | word | quoted
          | '(' term* ')' | '[' term* ']' | '{' term* '}' | symbol;
    

In mvalue a semicolon is significant but elsewhere it is not, i.e., the wildcard symbol cannot always match a semicolon. Fortunately, term is encoded as a monadic value, i.e., as a data item which can be created by a function with a parameter which controls whether or not a semicolon should be recognized when the data item is applied:

JavaScript's handling of newlines can result in ambiguities -- this is why blanks are explicit in this grammar so that newlines can be passed from monadic notation to preprocessed JavaScript. Specifically, if return and an argument are separated by a newline, JavaScript will treat return alone as a statement! As the code above shows this is easily circumvented by enclosing a return argument in parentheses and inserting a newline, if any, only after the leading parenthesis.

Once a grammar has been translated into monadic notation -- and executed to recognize some input if at all possible -- it needs to be extended with code which will represent or interpret the input. The preprocessor uses the factory method makeTreeClasses discussed in the previous section; the problem of translating the input is thus delegated to adding appropriate methods to these classes later. The necessary classes can be discovered top-down, simply by adding identifiers to bind interesting values returned by parsers and adding constructor calls in succeed calls to represent the interesting values. The monadic notation is ideally suited to this approach:

Paren and Text can be implemented using makeTreeClasses but Blank is best coded manually because white space is normalized before it is passed through:

The grammar and the monadic notation can be changed to perform some input rewriting or validation which cannot be conveniently expressed in the grammar itself. For example, the original rule

      mvalue:  blanks? (word blanks? '<-')? term+ ';' blanks?;
    

can be rewritten as

      mvalue:  ( blanks word blanks? '<-'
               |        word blanks? '<-'
               | blanks?                 )  term+ ';' blanks?;
    

because this makes it simple to combine the first two optional pieces of white space before handing them to the constructor. Moreover, term can be blanks and this is reasonable wherever term is used in this grammar -- empty parentheses or braces, no JavaScript code at all, etc. -- except in the situation shown above: a monadic value cannot be empty. This needs to be checked before mvalue is accepted:

bw is bound to a list containing null or Blank for the first two pieces of white space and null or a string for the identifier; ts is bound to a list of terms which will not include semicolons; finally, b3 is bound to null or a string with the last piece of white space, if any. All that is left is a loop over the term list to see if it contains a non-Blank and if so, the mvalue parser succeeds and the Mvalue constructor can be called with a canonical representation of the possible descendants.

Programming languages often make a difference between statements and expressions. The monadic notation requires that each computation produce a monadic value so that it can be unwrapped and bound to an identifier if one is specified. This means that a computation has to be a JavaScript expression, i.e., it can use conditional evaluation with ? : but it cannot use a loop. However, the code above shows that one can always insert a parameterless, anonymous function containing statements and call the function immediately following the definition. Among the statements must be at least one return to create the required value.

Finally, given a tree representing a JavaScript program with embedded monad phrases, code generation is implemented as a method gen in each of the classes from which the tree is built:

Text and Blank simply emit text or normalized white space, respectively. Paren emits the delimiters and uses a loop to generate code for the content between the delimiters. The hard part of the conversion is accomplished by Monad, Mvalues, and Mvalue. A Monad tree node contains a non-empty list of Mvalues and uses a loop to connect their code with orElse if needed:

      // Monad: Mvalues+
      //   Mvalues .orElse( Mvalues ) ...
      JSM.Monad.prototype.gen = function () {
        var content = this.content[0], 
          result = content[0].gen();
        for (var n = 1; n < content.length; ++ n)
          result += '.orElse(' + content[n].gen() + ')';
        return result;
      };
    

Mvalues contains a non-empty list of Mvalue objects and starts a loop implemented by recursion so that they can implement the appropriate function parameter name and connect their code with andThen if needed:

      // Mvalues: Mvalue+
      JSM.Mvalues.prototype.gen = function () {
        var content = this.content[0];
        return content[0].gen('', content, 1);
      };

      // Mvalue: Blank? word? (Blank|Monad|Paren|Text)+ Blank?
      //   Blank? term+ Blank? .andThen(function (word?) { return ... })?
      Mvalue.prototype.gen = function (head, content, next) {
        if (this.content[0]) head += this.content[0].gen();
        for (var n = 0; n < this.content[2].length; ++ n)
          head += this.content[2][n].gen();
        if (this.content[3]) head += this.content[3].gen();
        if (next < content.length) {
          head += '.andThen(function (';
          if (this.content[1]) head += this.content[1];
          head += ') { return (';
          head = content[next].gen(head, content, next+1);
          head += '); })'
        }
        return head;
      };
    

Normally the constructor calls are issued by the succeed clauses in the monadic notation; however, for testing purposes a tree can be built, displayed, and converted interactively:

But for white space, this example generates the same code as the monadic notation:

The tree display is always very useful to design code generation methods. It is instructive to take the tree output above and walk through the gen methods for the various preprocessor tree classes.

This section discusses the implementation of a little imperative programming language. The implementation uses monadic classes and consists of a parser to build a tree to represent the target program and of an interpreter which evaluates the tree. The complete code of the system is available for editing and preprocessing on a separate edit page.

The following program implements Euclid's algorithm to compute the greatest common divisor of two natural numbers. It uses typical features of such a little imperative programming language:

The following function controls the processing of a source string written in the little language:

The parser and tree builder for the little language is implemented just like the preprocessor discussed in the previous section. The grammar is an extension of the grammar for arithmetic expressions presented earlier:

      term:        number | word | '(' sum ')';
      product:     term ('*' term | '/' term)*;
      sum:         product ('+' product | '-' product)*;
      comparison:  sum ('<' sum | '<=' sum
                |  '>' sum | '>=' sum | '<>' sum | '=' sum);
      stmt:        sum | word '=' sum | 'print' sum
          |        'if' comparison 'then' stmt ('else' stmt)?
          |        'while' comparison 'do' stmt
          |        '{' stmt* '}'
          |        'try' stmt 'catch' (word ':')? stmt
          |        'raise' quoted;
      prog:        stmt eof;
    

The grammar can be translated into monadic notation as soon as the collection of regular expressions for the Parser.Factory has been defined:

=|<>|.)/,
        eof:     /^$/
      };
      Mini.scanner.word.reserved = [
        'catch', 'do', 'else', 'if', 'print', 'raise', 'then', 'try', 'while'
      ];
    ]]>

Once the grammar is translated, it is easy to see which classes are needed to represent a program. They can all be generated using makeTreeClasses:

The interpreter for the little language can be implemented with the visitor design pattern or by adding eval methods to the tree classes. An interpreter maps the features of the target language to the host language and it has to simulate missing features; e.g., Haskell does not support assignment and exception handling, i.e., if an interpreter is written in Haskell those features have to be simulated using monadic values.

JavaScript supports both, global assignment and exception handling, and there is no obvious need for simulation. However, monadic values make it possible to separate host and target behavior. The interpreter discussed here uses a monadic class Memory which holds an environment of current variable names and values accessible through fetch and store methods as the evaluation proceeds. The environment can be implemented as a collection:

All evaluation methods must return monadic values, for example:

Evaluation methods for binary operators can be implemented with a factory function bin which receives the actual operation as a parameter and creates the evaluation method with monadic notation, for example:

Memory maintains an environment with fetch and store operations as state. Access to the state is combined with these operations to implement variable reference and assignment:

Once monadic values are employed, andThen must be used to sequence execution at the statement level. if can be mapped to conditional evaluation; a missing else part has to be fudged:

A sequence of statements requires a loop which in turn requires a recursive implementation:

= content.length)
            return succeed(undefined);  // completed block has no value
          else
            return (
              {{{
                  content[n].eval();    // sequencing must be by andThen
                  self.eval(n+1);
              }}});
        };
    ]]>

Similarly, while must also be based on recursion:

For a host language like JavaScript, which has all the features of the target language, this approach looks too complicated. However, a monadic class can be used to implement exception handling very elegantly and with a choice of semantics:

Exception handling is based on fail and orElse, i.e., an operation such as division can use fail and cause an exception which a little language program can catch:

A failure can be caught with orElse, i.e., with ||| in monadic notation:

The try body a is evaluated. If there is a failure, the catch body b is evaluated. Both use the same initial state (environment).

It is even possible to make the error message from fail available as a variable value in the catch body. This is accomplished by re-implementing with a function argument in the style of andThen:

The alternative b must be wrapped as a function in order to provide the parameter scope for whatever value should be passed into the alternative. With onError, exception handling can be implemented so that the exception handler has access to the failure message:

The try body a is evaluated unconditionally. If it fails, the failure message is bound to the parameter value and from there to the variable name n in the environment before the catch body b is evaluated, i.e., b has access to the failure message with the variable name n.

Perhaps the most interesting aspect of this implementation of exception handling is that the interaction between assignment and exception handling can be influenced by the implementation of the environment.

This example produces a final environment which contains values for foo, bar, and foobar, i.e., catch seems to have operated on the state at the point of raise and not -- as should be the case for a monad-based implementation -- on the state at try. This behavior is caused by Hash, the implementation of the environment: As shown above, catch is implemented using orElse, i.e., try and catch do start out with the same environment. However, Hash is a simple JavaScript collection, i.e., all changes are persistent. The persistence can be removed, e.g., by cloning the environment whenever it is changed (there are less expensive ways):

If the environment is not persistent, the assignments in the try block are undone if there is an exception. While the implementation is expensive, the fact that this happens invisibly might make this variant of a try statement quite attractive, e.g., in a backtracking context.

This web page discusses a functional programming style suggested by the Monad and MonadPlus classes of Haskell and introduced a notation to facilitate coding in JavaScript. The significant problem domain is parsing: support for monadic parsers exists for Haskell , Python , and other languages .

This web page describes monadic LL(n) parsing with JavaScript. It contains the implementation of Monad, a base class for monadic JavaScript classes which wrap state functions. Subclasses can be created with the class method . A subclass has the shared monadic value to fetch the current state; the class methods to create a monadic value to store a new value and state, and to create monadic values reporting success and failure, and to serialize collections; and the methods to apply a monadic value, and and to create monadic values which apply monadic values sequentially or as alternatives.

This web page contains the implementation of Parser, a Monad subclass of monadic parsers which can be combined to represent LL(n) grammars. Parser provides the additional combinators , , and to support representing EBNF grammars. Parser has a number of class methods. supports left-associative assembly of a list of functions and converts certain property names in a collection into classes to represent trees which are connected to for serialization. is a class which is constructed with a collection of regular expressions and has methods to construct parsers which accept input matching the regular expressions.

This web page contains a preprocessor which extends JavaScript with a which simplifies specifying computations which involve monadic values. In particular, the notation facilitates translating LL(n) grammars into combinations of Parser values. From this perspective, JSM is a parser generator for JavaScript and the monadic notation extends JavaScript as input language for the parser generator. The web page contains three larger examples which use the preprocessor: a tree builder for a small programming language, an interpreter for the trees which implements error recovery and a functional approach to assignment, and finally the preprocessor itself.

Monad only requires functions as first-order values, Parser additionally benefits from regular expressions. Dynamic typing is convenient but not essential. Therefore, this web page can serve as a blueprint for quickly implementing parser generators in other programming languages where these features are available or can be simulated.

Finally, all code in this web page can be edited and used interactively. Therefore, the support files of this web page can be used as a framework for interactive, literate programming in JavaScript.