Matchertext: Towards Verbatim Interlanguage Embedding
 
https://github.com/dedis/matchertext

This draft represents a “work-in-progress” snapshot of an experimental open research project. Anyone with adequate interest, skills, and motivation is welcome to contribute to this research project, and potentially become a co-author upon making a substantial contribution. (Smaller contributions will receive acknowledgments in the final paper.) To propose a contribution, please use Pull Requests (PRs) on the project’s GitHub repository. We do not have time and cannot promise to answer all E-mails, or provide detailed guidance, before an interested potential contributor has proactively created and submitted some significant and well-considered contribution.

Many special-purpose language syntaxes exist almost solely for embedded use in other syntactic contexts. A few particularly common examples of such “little languages” include regular expressions (REs), uniform resource identifiers (URIs), JavaScript Object Notation (JSON), and Structured Query Language (SQL).

Perhaps the most classic “little language” is regular expression (RE) syntax, commonly used for pattern-based searches and replacements in freeform text. RE syntax traditionally uses many punctuation characters for special purposes, but must also allow arbitrary embedded text to be matched literally. RE syntax therefore makes heavy use of “backslash-escaping” in literal text: e.g., the RE .* matches any number of arbitrary characters other than newlines, while one must write \.\* to match the literal string ‘.*’. Because REs themselves are often embedded in another language – frequently a C-inspired language that also uses backslash-escaping in string literals – we must further backslash-escape the backslashes in RE syntax. A C string literal containing the latter RE above is written "\\.\\*", for example. To match the double-backslash \\ that begins a UNC name (as in \\host\path\file), the backslashes must be doubled to become \\\\ as an RE, then doubled again to become "\\\\\\\\" as a C sring literal containing that RE. This confusing multi-level explosion of backslash escapes has been aptly dubbed leaning toothpick syndrome.

As fig. 2 illustrates, each additional level of embedding in traditional syntax adds a set of escaping requirements that the writer (or reader) of code must carefully consider and apply correctly – in the correct order – in order to “guide” the embedded text through the levels of host syntax that the text is embedded in. REs and C string literals each require a different set of punctuation characters to be backslash-escaped, further increasing the cognitive load when embedding. PCRE syntax helpfully promises that a backslash followed by any non-letter always “takes away any special meaning that character may have”, so one may fall back on just escaping all punctuation instead of remembering which characters must actually be escaped. But this practice feels like a band-aid at best, and yields even more “leaning toothpicks.”

The above examples also illustrate how each level of embedding can multiply the length of embedded strings by a factor of 2 or more, yielding in the worst case an exponential string-length explosion with the number of embedding levels. While more than two levels of embedding may not be that common, they do occur.

Escaping issues such as those above have in part led many languages to support multiple different types of quotes with different escaping rules. Many languages allow string literals to be either single-quoted or double-quoted, so that quote characters of one type can be used literally within string literals of the other, as in "’" or ’"’.

Some languages disable escape sequences in one form of string literal so that backslashes may appear literally without multiplying in number: e.g., single-quoted Bourne shell strings (’\’ is the same as "\\") or backtick-quoted raw string literals in Go (‘\‘ is like "\\"). But without escapes it becomes more difficult to include the forbidden terminating quote literally in the string: typically one must compose multiple strings, like "it’s "+’"quoted"’. Some languages such as Python allow triple-quoted multiline strings to make it less likely that the terminating sequence is needed in the literal: e.g., ’’’$\dots$’’’ or """$\dots$""". But such a sequence may still need to appear, of course – especially in written examples of exactly this syntax for example.

Some languages further mitigate this problem by offering an effectively-unlimited number of delimiter pairs. Extended string literals in Swift, for example, surround a quoted sequence with a balanced number of # signs: e.g., #"$\dots$"#, ##"$\dots$"##, etc. Lua similarly offers long bracket quotations like [=[$\dots$]=], [==[$\dots$]==], etc. This approach has the appeal that for any string to be delimited, there always exists some delimiter pair that can quote it unambiguously. But the delimiters must still be carefully matched to the quoted string, or vice versa. It is still not possible to embed any string of a broad class verbatim into any “hole” or template in a host language without thinking about, and potentially adapting, either the choice of delimiters or the embedded string. Further, the worst-case “cost” of embedding in terms of string expansion still increases with each level of nesting – in this case at least only linearly, rather than exponentially, in the number of levels. We would prefer, however, if embedding required no expansion with increased depth.

The syntactic complexity of correctly embedding strings into code has created several broad classes of security vulnerabilities, where untrusted (typically user-entered) strings intended to be embedded can maliciously “trick” an application into interpreting parts of the string in the host language context.

SQL injection attacks [6], for example, typically arise from the common practice of embedding user-entered strings into string literals within SQL query templates. If a server composes an SQL query with a clause like "WHERE name=’"+userName+"’", and the untrusted userName can be maliciously crafted to contain an unescaped single quote, then the attacker can prematurely terminate the SQL string literal and add other SQL clauses, like OR ’1’=’1’ to make the clause unconditionally true regardless of userName.

Cross-site scripting (XSS) attacks [11] similarly exploit errors in the ubiquitous practice of embedding content from an untrusted source – such as fields from an HTML form – into HTML or other markup without proper “sanitization” via escaping. Suppose, for example, that one user of a Web-based discussion forum can post a message containing an HTML <script> tag – which the discussion server then inserts into corresponding pages viewed by other users of the forum. The injected JavaScript code can then potentially steal authentication cookies or other private information from all users on the site who might unwittingly read the maliciously-crafted message.

These and other broad classes of syntactic confusion attacks have led to the security-critical practice of sanitizing all potentially-untrusted user input before embedding it into security-sensitive code of any kind – whether SQL queries, HTML markup, or other host languages. The forms of sanitization needed in a particular context unfortunately tend to be complex and intricately dependent on the syntax and semantics of the host language that the untrusted content is to be embedded in. Version updates in the host language or associated libraries, which the application might not always track immediately, can easily introduce new syntactic attack vectors that the application has not yet countered with appropriate sanitization logic.

We do not expect any syntactic discipline, including matchertext, to eliminate the need to sanitize untrusted inputs. If a future SQL query or Web form is designed to accept embedded matchertext from an untrusted source, for example, then it will likely still be security-critical to check that the untrusted content is indeed valid matchertext, and reject it if not. However, a passive verification like this can be much simpler, and hence less bug-prone, than a content-modifying transformation, to escape all characters or sequences that might be “sensitive” in the host language. Further, this security-critical check could also be more uniform across host languages – i.e., checking only that the three ASCII matcher pairs are matched corrrectly throughout the untrusted content, rather than deeply verifying and/or transforming based on the complex syntax of a particular host language. Thus, while matchertext will not eliminate the need for sanitization, it might tighten and simplify the function of the most security-critical “checkpoint” – namely checking that embedding content from an untrusted source preserves the structural integrity of the host language it is embedded in.

We first define abstract matchertext in order to ensure that the basic concept is clear and precise.

We assume at the outset we are given some arbitrary alphabet $\Sigma$, along with some finite set $\Pi$ of character pairs $\{(o_{1},c_{1}),\dots,(o_{k},c_{k})\}$, such that $\{o_{i},c_{i}\}\subseteq\Sigma$ for all $1\leq i\leq k$. We define the openers $O$ as the set of characters $o$ such that some pair $(o,c)\in\Pi$. Similarly, the closers $C$ are the characters $c$ such that some pair $(o,c)\in\Pi$. We assume and require that the sets of openers and closers do not overlap: i.e., $O\cap C=\emptyset$. We define the matchers $M$ as the set of all openers and closers (i.e., $M=O\cup C$). We define the nonmatchers $N$ as all characters that are not matchers (i.e., $N=\Sigma\setminus M$) A matchertext configuration is a pair $(\Sigma,\Pi)$ following the above rules.

We now define the language $L$ of matchertext strings inductively (i.e., generatively) as follows:

• •

  Any string $n$ consisting exclusively of nonmatcher characters in $N$, including the empty string, is a matchertext string in $L$.

• •

  For any matchertext strings $m_{1},m_{2},m_{3}$ in $L$, and for any pair $(o,c)\in\Pi$, the concatenation $m_{1}||o||m_{2}||c||m_{3}$ is also a matchertext string in $L$.

Intuitively, this definition captures the basic rule that matchers must match in matchertext. Openers can be introduced into valid matchertext only when paired with a matching closer, and vice versa, but nonmatchers may be interspersed throughout with no constraints.

We consider matchertext to constitute a purely syntactic rule with no associated semantic meaning. While we can formally define it as a syntactic language, in practice we will refer to it as a syntactic discipline rather than a language because it assigns no specific meaning or purpose to the strings in $L$, and no structure apart from the basic rule that matchers must match. The meanings and structural purposes of all characters – both matchers and nonmatchers – are deliberately left entirely open for any particular “matchertext-aware” language to define.

The abstract definition of matchertext above and its basic structural rule apply in principle to any matchertext configuration $(\Sigma,\Pi)$. In practice, however, we must standardize on particular choices of $\Sigma$ and $\Pi$ across a set of languages of interest in order to achieve escapeless embedding among them. We wish to identify a particular, concrete matchertext configuration that fits existing syntactic syntactic practices as well as possible, and facilitates escapeless embedding across minimally-adapted variants of today’s popular machine-readable languages.

We therefore propose a standard matchertext configuration whose alphabet $\Sigma$ is the Unicode/UCS character set [29], and whose matcher pairs $\Pi$ consist of the ASCII parentheses (), square brackets [], and curly braces {}.

The choice of UCS as the character set $\Sigma$ is justified by the fact that machine-readable languages have largely converged on this standard, so it is in effect already decided. In fact, the programming language community has also largely converged on UTF-8 as the standard way to encode UCS plain text into flat byte-stream source files – although encoding is not a primary concern for matchertext since it operates below the character set abstraction.

Even if adequately well-justified, we cannot expect the standard matchertext configuration as defined above to be a perfect or painless fit for all situations in which string embedding is useful. Including any matcher pair in $\Pi$ has the cost of requiring those matchers to be escaped in string literals and comments, for example, as we detail later in section 5. There may be legitimate or even unavoidable reasons to use other matchertext configurations in some cases, keeping in mind that doing so reduces interlanguage embedding compatibility.

In general, deviations from the standard matchertext configuration can be either tightening (more restrictive), loosening (less restrictive), or a combination.

Suppose a host language $L_{h}$ wishes to allow embedding a matchertext string $m$ from an arbitrary language $L_{e}$, whose syntax is likely unknown to the host language. In contexts where matchertext strings $m\in L_{e}$ are allowed, $L_{h}$ must impose no constraints on characters allowed in that context other than the matchertext discipline (matchers must match). Further, $L_{h}$ must not transform the embedded strings $m$ in any way while extracting it from the host-language text. Specifically, any escaping mechanisms or other transformations that might normally apply to text in $L_{h}$ must be disabled in the context of the embedded string. If any escaping mechanisms or other transformations are active within the embedded string, they must be those of $L_{e}$, not $L_{h}$. We will see examples of this principle applied in several specific contexts below.

Languages need not be matchertext-compliant in their own syntax, however, just in order to host embedded matchertext. Existing languages can preserve full compatibility with all their existing (non-embedded, non-matchertext) code – continuing to allow unmatched matchers in string literals for example – while incrementally adding extensions that make it easy to embed matchertext strings verbatim within the host language. This form of backward compatibility will likely be essential to the incremental adoption of matchertext.

We next examine languages with C-like string literal syntax in section 4.2, then address SGML-derived languages such as HTML and XML in section 4.3, and finally in section 4.4 we focus on uniform resource identifiers in their role as a meta-syntax frequently “hosting” embedded identifiers derived from other syntaxes.

Table 2 summarizes the syntax extensions for different language classes proposed in this section. We emphasize that these are merely proposals for discussion. Different language communities should and will make their own decisions, and need not agree across languages on specific extension syntax in order for matchertext to be useful.

An enormous variety of today’s popular programming languages are derived, either closely or loosely, from C [24]. Though differing widely in purpose, philosophy, and semantics, a vast number of these C-inspired languages share similar syntax for string literals. In particular, most C-derived languages use double and/or single quotes to delimit a string literal, and backslash escape codes to insert “special” characters within the literal: e.g., "hello!\n". Because quoted string literals are the primary existing syntactic mechanism for embedding (non-matchertext) strings traditionally, they represent a natural starting point for considering matchertext extensions.

Given the ubiquity of backslash-escaped string literals, we suggest that one reasonable extension for hosting matchertext in C-like languages is via a new escape sequence, such as \[$m$], where $m$ is arbitrary matchertext. The embedded matchertext $m$ is uninterpreted by the host language processor except to verify that ASCII matchers match and to find the terminating close bracket. Thus, quote characters, backslashes, whitespace, newlines, or other control codes cease being “special” within the matchertext $m$ – at least from the perspective of the host language. For example, the string literal "\["’\]" becomes equivalent to "\"\’\\". These and other characters might of course be “special” with respect to whatever embedded language $m$ might be written in.

While the venerable Standard General Markup Languages (SGML) [28, 15] itself has waned in popularity, its derivatives HTML [31] and XML [32] are now ubuiquitous in Web content and programming. Wherever the differences between these markup languages is not important, we will refer to them all as $\star$ML languages.

In their basic role as markup languages used to produce rich, structured documents, $\star$ML languages frequently play “host” to embedded strings in countless other languages: typically, in the language(s) of software or APIs that a marked-up document is written about. Embedding code in other languages as verbatim text is a basic and frequently-used purpose of HTML’s <code> and <pre> tags, for example. Beyond merely marking up verbatim text in other languages, however, HTML in particular has evolved to include special-purpose support for embedding several other languages within HTML: namely scripting languages such as JavaScript or Tcl, cascading style sheets (CSS) [35], MathML [33], and SVG [34].

The $\star$ML languages are surprisingly complex syntactically, especially given their simple-sounding purpose of “merely” describing structured markup of usually human-readable text. In particular, there are at least three different syntactic contexts in which strings in other languages are often embedded into $\star$ML languages – and in which three different sets of quoting and escaping rules apply. Embedded strings are often embedded (1) as the content of an element, (2) as an attribute within an element’s start tag, or (3) as verbatim text within a CDATA section. We address each of these syntactic contexts in turn, in each case suggesting potential matchertext extensions that could help mitigate the various forms of “escaping hell” that these embedding contexts can create.

Uniform resource identifier (URI) syntax [2] has become a ubiquitous notation for naming and locating not only web pages but innumerable other Internet resources. As a “small” special-purpose syntax, as opposed to a general-purpose programming language, it is arguably more often useful as an embedded rather than a host syntax, as we will focus on later in section 5.4. In practice, however, innumerable other identifier syntaxes get embedded into URIs regularly, either as scheme-specific text (e.g., file names, phone numbers, cryptographic hashes), or even as query parameter values. This common and intentional use of URI syntax as a uniform “wrapper” for other identifier syntaxes makes URIs worth careful consideration as a potential host syntax for matchertext embedding.

We suggest two syntactic extensions to host matchertext within URIs, which are potentially complementary and could be adopted either together or individually.

First, extending the existing “percent-encoding” scheme for escaping special characters (e.g., %20 to represent an ASCII space), we suggest matchertext escape sequences of the form %[$m$]. Like the backslash-escape form \[$m$] suggested in section 4.2 for C-like languages, the matchertext $m$ is uninterpreted by the URI processor other than to verify that matchers match and find the terminating close bracket. For example, file:///%[a<b>c‘d] becomes a valid URI usable to access a local file named a<b>c‘d, containing characters typically allowed in Unix-derived file systems but traditionally forbidden in URIs. Since percent-encoding by the host URI processor is disabled within the embedded matchertext $m$, %[100%] becomes valid and equivalent to 100%25. In effect, this matchertext escape syntax offers a more concise, less obfuscated way to express arbitrary portions of URIs in which several characters would otherwise have to be individually percent-encoded. Figure 4 shows a few examples of URIs using conventional and matchertext percent-escapes for comparison.

Another potential syntactic extension is to allow square-bracketed sequences [$m$] to appear verbatim within the URI body, where $m$ is otherwise-uninterpreted matchertext. This is not an escape sequence: the square brackets are not eliminated in URI processing, so [@] is equivalent to %5B%40%5D. This extension essentially serves as a matchertext-friendly quoting syntax that may be used in specific URI schemes, or within pathname components or query strings, to embed substrings in other identifier syntaxes (even other URIs) without obfuscation. We will explore the usefulness of this extension further when we consider matchertext resource identifier or MRI syntax later in section 5.4.3. This extension is backwards-compatible with existing (valid) URIs because current syntax permits brackets only in special-purpose IPv6 address syntax as part of the authority field.

Despite being a “small” synax for the special purpose of matching patterns in strings, regular expressions (REs) and their use are complex enough in practice that multiple entire books have been written about them [10, 14, 16]. Two regular expression syntaxes were standardized by POSIX [22], while the Perl language and the Perl Compatible Regular Expressions (PCRE) library it inspired define advanced syntax that has become popular in numerous other languages and applications.

In filling their basic role of matching patterns in text, REs must inherently must embedd strings comprising the patterns to be matched – and those embedded strings can be in any syntax. Thus, being able to host embedded strings of any language with minimal obfuscation in principle facilitates an RE’s basic pattern-matching role.

Since the most common RE syntax uses backslash escapes similar to those in C-like languages, the same matchertext escape extensions, such as \[$m$], could work for REs. Because of the large number of punctuation characters that are sensitive in REs, however, some popular RE syntaxes such as PCRE guarantee the rule that if a backslash “is followed by a character that is not a number or a letter, it takes away any special meaning that character may have.” This way, a user can just conservatively escape all literal punctuation appearing in an RE, instead of remembering which punctuation must be escaped. Preserving this rule may suggest a longer, letter-based matchertext escape sequence such as \m[$m$].

Another alternative would be to use some non-backslash-escape syntax, such as {{$m$}}. This alternative syntax uses the same curly braces that REs already commonly use for repetition quantifiers like $c${1,3}, but in a syntactically non-conflicting fashion since the inner braces cannot be mistaken for repetition quantifiers. With this alternative syntax, the pathological “leaning toothpick syndrome” example RE, matching the double-backslash \\ in a UNC name (see section 2), becomes the more readable RE {{\\}}. Embedding this RE in a C-like string literal with matchertext extensions in turn becomes "\[{{\\}}]", for a more manageable three leaning toothpicks total, in contrast with the traditionally-required eight ("\\\\\\\\").

Almost certainly the most common context in which unmatched matchers appear in most today’s existing source code is within string literals. This is especially true of code to print, or parse, machine-readable code in almost any syntax. Structured pretty-printing code frequently includes code sequences like this:

print("[")
output all elements of a list
print("]")

Similarly, parsing code often uses if, switch, or case conditionals to recognize and parse matcher-delimited syntactic structures, as in:

if peekNextChar() == ’[’:
scanChar(’[’)
scan all elements of a list
scanChar(’]’)

Printing and scanning code like this generally violates the matchertext rule, and adapting such code most likely represents the biggest “pain point” in any venture to write readily-embeddable matchertext.

Almost all programming languages already offer a workable if slightly cumbersome solution: simply replace unmatched matchers in string literals with suitable numeric character escapes. Instead of print("["), for example, write print("\x5B") (C, C++, JavaScript) or print("\u005B") (Java, JavaScript, Go). This always works; the main annoyance is that it requires the writer (and reader) of the code to remember or look up the codes for the matcher characters in an ASCII table.

The usual solution in C-like languages to handle “special” characters in string literals is simply to backslash-escape the special character, like \[. This traditional solution does not work for unmatched matchers in matchertext, however, because the matchertext rule is deliberately language-independent and oblivious to language-specific syntax such as that of string literals. So a backslash-escaped unmatched bracket \[ remains just as much a matchertext violation as the bracket alone.

There is a solution that avoids the need for ASCII tables, however. Because literal matchers are a problem in matchertext only when unmatched, we can simply introduce escape sequences that incorporate both matchers as a properly-matched pair, while “selecting” only the opener or closer of the pair. In C-like languages, for example, we suggest the sequence \o() to escape an open parenthesis, \c() to escape a close parenthesis. Similarly, \o[] and \c[] represent open/close square brackets, and \o{} and \c{} represent open/close curly braces.

The choice of the letters o and c to escape the matchers is consistent with their standardized character classes: “Open Puntuation (Ps)” and “Close Punctuation (Pe)”, respectively. We might consider l and r for “left” and “right”, escept \r is a near-universal escape for carriage return (CR). A few languages already use o or c in escape sequences: e.g., Raku uses \o[$n$] to denote the ASCII character with octal value $n$, and uses \c[$n$] to denote a Unicode character with name or decimal value $n$. Many of these existing uses are technically not in conflict syntactically, provided the existing use requires a non-empty string between the matchers – as Raku does in the above cases, for example. In any case, different languages need not agree on specific escapes sequences for unmatched matchers and are free to make their own stylistic choices.

Another context in which unmatched matchers may regularly appear in typical source code is within comments: e.g., as part of human-readable text describing how the associated code handles particular characters. Conventional language processors usually just ignore unmatched matchers (along with everything else) in a comment. But the matchertext discipline operates below and oblivious to the syntax of a particular language, and hence does not know what a “comment” is – so the matchertext discipline must disallow unmatched matchers even in comments.

Since comments are generally intended for humans reading the source code, it is usually possible simply to rephrase the comment to avoid a literal use of unmatched matcher characters: e.g., just name it (‘open parenthesis’) instead of writing it (‘(’). Another alternative, if a language adopts the above extensions for string literals, is simply to use these matchertext-friendly escapes in comments as well (e.g., \o()).

In some languages, comments often get used to produce API documentation, using tools like Javadoc or godoc. In such cases, it may be useful to interpret escape sequences such as those above while auto-generating documentation from source code, so that a documentation comment like ‘// Parse a \o()’ becomes ‘Parse a (’ in the formatted output generated from the code.

Considerations similar to those above for string literals apply when we wish to embed $\star$ML-language markup into other languages as matchertext. The most common reason unmatched matchers appear in markup is when needed in literal text being marked up: e.g., human-readable text about the matcher characters or syntactic constructs built from them, or code examples that contain unmatched matchers.

As with C-style string literals, $\star$ML languages already offer a workaround: simply use character references, either named (like () or numeric ((). For the same reasons as above, we may like to have extensions offering more visually-obvious alternatives for writing matchertext: e.g., &o(); and &c(); for open and close parentheses, respectively.

Since uniform resource identifier (URI) syntax represents a special-purpose “little language” just for expressing identifiers, URIs are predominately embedded in other contexts – software source code, documentation markup, configuration files, etc. Especially since URIs are intended to be human-readable, it would thus seems useful if URIs could be maximally “friendly” for embedding.

Typical regular expression (RE) syntax is C-like in terms of using backslashes to escape sensitive punctuation characters within text to be matched. Similar escape sequences like \o and c for unmatched matchers could therefore be introduced as discussed above in section 5.1.

One complication is that the popular PCRE syntax already uses \o{$n$} for character escapes with octal numeric value $n$. This octal-escape usage of \o technically does not conflict syntactically with \o{}, however, since the $n$ in an octal escape cannot be the empty string.

PCRE syntax also offers \c$x$ as a way to enter control characters, by flipping bit 6 of ASCII character $x$. This is a syntactic conflict with the proposed matchertext escapes, but perhaps a tolerable one. The sequence \c( would constitue a bizarre and unlikely way to express a simple literal letter ‘h’, and \c{ would be a strange synonym for a semicolon ‘;’ – neither of which need escaping at all. The sequence \c[ might be slightly more likely to see use to express the ASCII escape (ESC) control code (hex 1B) – but PCRE already provides the more-concise and obvious sequence \e to express this control code.

One early experiment in matchertext-friendly syntax design is MinML [13], an alternative syntax for SGML-derived markup languages like HTML and XML.

Beyond merely adding matchertext hosting and embedding extensions as discussed in the sections above, MinML more ambitiously reformulates the basic $\star$ML syntax to rely on matching brackets for basic structure rather than matching start/end tags as in SGML tradition. For example, emphasis is written like em[emphasis] rather than <em>emphasis</em>. Character references are written like [star] instead of ☆.

A “quotation” delimited by matching quote characters may be written like "[quotation] in MinML instead of “quotation”. A comment is -[comment] instead of <!--comment-->. A raw embedded text sequence is written +[verbatim] instead of <![CDATA[verbatim]]>. MinML’s embedded sequences leverage matchertext to support arbitrary nesting, so a verbatim example of a raw matchertext sequence is simply +[+[example]], rather than in XML:

<![CDATA[<![CDATA[example]]]]><![CDATA[>]]>

For escaping unmatched matchers, MinML supports both the traditional HTML named and numeric character references, and bracket-delimited versions of the “visual” matcher escapes suggested earlier in table 1 and section 5.5.1 discussing regular expressions:

An experimental library and command-line tool to parse MinML and convert it to HTML or XML, written in Go, is available at https://github.com/dedis/matchertext. An extention to the Hugo static website generator supports web authoring in MinML.

I wish to thank Terence Parr and Russ Cox for valuable feedback on earlier drafts of this paper.