Commits

catseye  committed a755dc2

Convert documentation to Markdown-formatted README.

  • Participants
  • Parent commits 42418ae
  • Tags rel_1_0_2012_0316

Comments (0)

Files changed (2)

File README.markdown

+The Unlikely Programming Language
+=================================
+
+Overview
+--------
+
+Unlikely is a programming language with the following traits:
+
+-   Unlikely conflates objects with continuations, and methods with
+    labels. All classes are subclasses of the root class `Continuation`.
+    Every object can be continued at any method. Every method, except
+    for the `continue` method on the built-in class `Stop`, must
+    continue some other method at the end of its definition.
+-   All Unlikely program structures are exposed as objects with
+    commensurate inheritance relationships. For example, every Unlikely
+    program is a subclass of `Program`, and the classes `If` and
+    `Switch` are both subclasses of the abstract base class `Branch`.
+-   Unlikely takes dependency injection to the logical extreme.
+    Dependency injection is an increasingly popular modern
+    object-oriented program construction technique which allows the
+    specific classes which will be used by some class ("dependencies")
+    to be specified ("injected") when that class is instantiated.
+    Unlikely goes one step further by *requiring* that all specific
+    classes used by some class are specified during instantiation.
+
+Semantics
+---------
+
+### Classes
+
+A class is a schema describing a set of objects. Instantiating a class
+produces a new object of that class. When a class is instantiated, all
+classes that are referenced by the class (dependant classes) must be
+named (injected) by the instantiating code (the instantiator). For each
+requested dependant class, any subclass of it may be supplied by the
+instantiator, further specifying and constraining behaviour (a technique
+called dependency injection). In this way, classes are inherently
+parameterized.
+
+When a class refers to itself, it is considered a dependant class of
+itself; it (or a subclass) must be injected by the instantiator.
+
+All specified dependant classes must be unique (no dependant class may
+be specified more than once.) Final classes need not and may not be
+specified as dependant classes because, being final, there is no
+subclass that the instantiator could possibly substitute for them.
+
+Each class may define zero or more properties and zero or more methods.
+
+#### Inheritance
+
+Whenever a class is defined in Unlikely source code, a superclass must
+be named; the class being defined is thus a subclass that inherits from
+that superclass. Its inheritance consists of the properties and methods
+defined by the superclass and all of its ancestors (i.e. including all
+properties and methods that the superclass inherited from its own
+superclasses) as well as the dependant classes of the superclass. The
+subclass may not inject dependencies when inheriting from a superclass.
+Only single inheritance is supported.
+
+A subclass may override methods that it inherits from its superclass. It
+may access the method definition of its direct superclass (or any
+indirect ancestor class) by naming that superclass explicitly in a
+continue.
+
+A class may be declared as final, in which case it may not be
+subclassed. In addition, final dependant classes may not be injected.
+
+A class may also be declared as saturated, in which case it can be
+subclassed, but subclasses of it must also be declared as saturated, and
+they cannot define any new methods. They can only override existing
+methods. In fact, the root class `Continuation` is declared saturated,
+so really, all objects have exactly one method, `continue`.
+
+If a class defines or inherits any abstract methods, that class must be
+declared as abstract. Abstract classes cannot be instantiated. Any
+subclass of an abstract class must define all inherited abstract methods
+in order to be considered concrete and thus instantiatable.
+
+### Properties
+
+Each property has a particular type, which is a class. The values it may
+take on are objects of that class, or of its subclasses.
+
+Each object has its own instances of the properties defined on the
+class, and each of these properties may take on different values.
+
+All state of an object is stored in its properties. Properties are
+effectively public; they can be modified by code in any method in any
+class.
+
+The root class `Continuation` defines one property, `accumulator`, of
+type `Passive`, which all classes inherit.
+
+Subclasses may not override inherited properties.
+
+### Methods
+
+A method is a label on a piece of code inside a class. The methods of a
+class are shared by all objects of that class.
+
+A method may be declared abstract instead of defining code for it.
+Classes which contain abstract methods must themselves be declared
+abstract.
+
+Only one thing may be done to a method in code, which is to continue it
+with respect to some object; this is described in the next section.
+
+A method may declare zero or more arguments. Each argument has a type,
+which is a class. When a method is continued, a value of the
+corresponding type (or some subclass of that type) must be given for
+each argument. In actuality, the arguments merely name properties of the
+object; they must already be declared in the class before they are
+listed in the declaration of the method. Passing values in arguments is
+just shorthand for assigning these properties before continuing the
+method.
+
+Methods do not have local variables, so for storage must use the
+properties of the object on which they were continued.
+
+The root class `Continuation` defines one abstract method which
+subclasses must implement, called `continue(Passive accumulator)`. By
+convention, this method is what other methods continue. The accumulator
+is passed from continuation to continuation, manipulated as execution
+proceeds.
+
+### Code
+
+The code inside a class labelled by a method consists of a series of
+assignments followed by a continue.
+
+Each assignment consists of an object property on the left-hand side,
+and an expression on the right-hand side. The the property so named will
+take on the value resulting from evalulating the given expression.
+Expressions consist of instantiations of new objects, and references to
+other object properties.
+
+The continue names a method on an object to which control flow will
+immediately pass. It may also pass values as arguments to that method;
+however, this is mere shorthand for assigning properties of the object
+on which the method being continued is defined. See above under
+"Methods" for more details.
+
+### Passive Data
+
+Passive data values, such as integers and strings, are modelled somewhat
+specially in Unlikely, in order to strike a balance in language design
+between "too straightforward" and "too convoluted".
+
+All passive data values are instances of some subclass of the abstract
+class `Passive`, which is itself a subclass of `Chain`. When a passive
+data value is continued, it passes its own value into the accumulator of
+the "next" continuation. (It is not necessary, however, to continue the
+passive data value to obtain its value in all cases.)
+
+Each immediate subclass of `Passive` gives a data type of values, such
+as `Integer` or `String`. Each of these type-classes has a countably
+infinite number of subclasses, one for each possible value of that type.
+It is these classes that are instantiated to acquire a passive value
+object. For example, `three = new 3()` instantiates the value 3. When
+the `continue` method on this object is continued, the value that it
+represents will be passed down the chain to the continuation assigned to
+its `next` property. For example, `three.next = new Print()` would cause
+3 to be printed when `three` was continued.
+
+None of the direct subclasses of `Passive` can be further subclassed. In
+effect, they are final (despite being abstract!) because all possible
+subclasses of them already exist.
+
+Syntax
+------
+
+### Overview
+
+The overall schema of a class definition is:
+
+    class ClassName(ClassName,ClassName) extends ClassName {
+      ClassName propname;
+      method methodname(ClassName propname, ClassName argname) {
+        propname = new ClassName(ClassName,ClassName);
+        propname.propertyname = argname;
+        goto expr.methodname(expr,expr);
+      }
+    }
+
+### Grammar
+
+A somewhat more formal definition of the syntactic structure of Unlikely
+code is given in the following EBNF-like grammar.
+
+    ClassBase   ::= {ClassDefn}.
+    ClassDefn   ::= "class" ClassName<NEW> "(" [ClassName {"," ClassName}] ")" "extends" ClassName
+                    ["{" {PropDefn} {MethodDefn} "}"] ["is" ClassMod {"and" ClassMod}].
+    ClassMod    ::= "final" | "saturated" | "abstract".
+    PropDefn    ::= ClassName PropName<NEW> ";".
+    MethodDefn  ::= "method" MethodName<NEW> "(" [ParamDecl {"," ParamDecl}] ")"
+                    ("{" {Assignment} Continue "}" | "is" "abstract").
+    ParamDecl   ::= ClassName PropName.
+    Assignment  ::= QualName "=" Expr ";".
+    Continue    ::= "goto" PropName "." MethodName "(" [Expr {"," Expr}] ")" ";".
+    Expr        ::= ConstrExpr | QualName.
+    ConstrExpr  ::= "new" (ClassName | Constant) "(" [ClassName {"," ClassName}] ")".
+    QualName    ::= PropName {"." PropName}.
+    ClassName   ::= <<sequence of alphabetic characters>> | Constant.
+    Constant    ::= <<sequence of decimal digits>> | <<sequence of arbitrary characters between double quotes>>.
+
+Note that multiple ClassDefns for a single class may appear; each may
+partially define the class. In this way a "forward declaration" of a
+class may occur. This may give its name, superclass, and dependant
+classes, so these can be consumed by some following class that requires
+them, before the methods of this class are defined. The dependant
+classes are cumulative over successive partial definitions; they need
+not be repeated. However the same superclass must be specified for all
+partial definitions of a class.
+
+Built-in Classes
+----------------
+
+-   `Continuation`
+
+    The abstract base class that is the superclass of all Unlikely
+    classes, and which can't be instantiated. Declares the property
+    `Passive accumulator`, and the abstract method
+    `continue(Passive accumulator)`, which all concrete subclasses must
+    implement. Is declared `saturated`, so no subclass may declare or
+    define any additional methods.
+
+    -   `Program`
+
+        An abstract continuation that provides the guarantee that it can
+        be started (that is, that its `continue` method can be initially
+        continued) from the operating system. It can be reasonably
+        expected that the `accumulator` will be assigned a value
+        provided by the user, perhaps via a command-line argument.
+
+        -   `Stop`
+
+            A concrete continuation which exits to the operating system
+            when continued. The accumulator is used as the exit code,
+            assuming the operating system supports this.
+
+        -   `Chain`
+
+            An abstract continuation which defines the property
+            `Continuation next`. When a subclass of `Chain` is
+            continued, it will generally continue the continuation
+            assigned to its `next` property after doing something.
+
+            -   `Passive`
+
+                The abstract final base class representing passive data
+                values. Discards whatever accumulator was passed to it,
+                and passes its own value into the accumulator when it
+                continues the continuation assigned to its `next`
+                property.
+
+                -   `Boolean`
+
+                    The abstract final base class representing boolean
+                    values.
+
+                    -   `True`, `False`
+
+                        Final classes representing particular boolean
+                        values.
+
+                -   `Integer`
+
+                    The abstract final base class representing integer
+                    values.
+
+                    -   `0`, `1`, `2`...
+
+                        Final classes representing particular integer
+                        values. Note that only positive constants are
+                        available; negative values must be computed by
+                        subtracting from 0.
+
+                -   `String`
+
+                    The abstract final class representing string values.
+
+                    -   `""`, `"a"`, `"b"`, `"aa"`...
+
+                        Final classes representing particular string
+                        values.
+
+            -   `BinaryOperation`
+
+                A continuation which posesses a property `value` and
+                which yields a value when continued by applying some
+                operation to `value` (treated as LHS) and the
+                accumulator (treated as RHS.)
+
+                -   `Add`
+
+                    A concrete binary operation which adds `value` to
+                    the accumulator and passes the result when
+                    continuing `next`.
+
+                -   `Subtract`
+
+                    A concrete binary operation which subtracts the
+                    accumulator from `value` and passes the result when
+                    continuing `next`.
+
+                -   `Multiply`
+
+                    A concrete binary operation which multiplies `value`
+                    by the accumulator and passes the result when
+                    continuing `next`.
+
+                -   `Divide`
+
+                    A concrete binary operation which divides `value` by
+                    the accumulator and passes the result when
+                    continuing `next`.
+
+                -   `Condition`
+
+                    A BinaryOperation which yields a boolean value.
+
+                    -   `Equal`
+
+                        A concrete binary operation which compares
+                        `value` to the accumulator and passes True when
+                        continuing `next` only if they are equal.
+
+                    -   `GreaterThan`
+
+                        A concrete binary operation which compares
+                        `value` to the accumulator and passes True when
+                        continuing `next` only if `value` is greater.
+
+            -   `Print`
+
+                A concrete continuation which displays the value of the
+                accumulator to the user before continuing its `next`
+                property.
+
+            -   `Input`
+
+                A concrete continuation which obtains a value from the
+                user, and passes this value in the accumulator when
+                continuing its `next` property.
+
+            -   `Branch`
+
+                An abstract continuation which continues one of the
+                continuations assigned to its properties, based on some
+                other information. Defines the `Chain` property `else`
+                which represents the basic alternate continuation that
+                can be continued instead of `next`.
+
+                -   `If`
+
+                    A continuation which continues one of two
+                    continuations assigned to its properties, `next` and
+                    `else`, based on whether the accumulator is an
+                    instance of `True` or `False`.
+
+                -   `Switch`
+
+                    An abstract continuation whose behaviour differs on
+                    subsequent times it is continued. This is
+                    implemented by means of a `state` property which
+                    changes values each time the switch is continued;
+                    depending on the value of `state`, different things
+                    happen.
+
+                    -   `Loop`
+
+                        An abstract continuation which is intended to
+                        implement a loop. However, this is not
+                        automatic; some continuation chain leading from
+                        this continuation *must* lead back to this
+                        continuation in order for actual repetition to
+                        take place.
+
+                        -   `WhileLoop`
+
+                            A concrete `Loop` which, on odd visits
+                            continues its `test` property. It is assumed
+                            that some continuation down that chain
+                            continues this `WhileLoop` object with a
+                            boolean value in the accumulator. On these
+                            even visits, it will behave like an `If`:
+                            when the boolean is a `True`, `next` is
+                            continued, otherwise `else`.
+
+                        -   `ForLoop`
+
+                            A concrete `Loop` which defines `value`,
+                            `delta`, and `finish` properties, all
+                            `Integer`s. On each visit, it checks if
+                            `value` equals `finish`; if not, it adds
+                            `delta` to `value` and continues `next`. But
+                            if so, it simply continues `else`.
+
+Implementations
+---------------
+
+There is not currently a reference implementation of Unlikely. Any
+contradictions and/or grey areas in this document will therefore have
+nowhere to turn to to be cleared up.
+
+There is, however, a partial and non-normative implementation of
+Unlikely, a static analyzer written in Python called Coldwater. It
+parses Unlikely programs and identifies many type errors and other
+statically-detectable invalid programs. It is meant to give some body to
+the ideas present in Unlikely, without actually going so far as
+implementing it in full.
+
+The construction of Coldwater helped clear up some of the fuzzier
+corners of the language. However, there are probably several areas that
+remain fuzzy and render the language unsuitable for anything but the
+most trivial programming. Extending Coldwater to be a full-fledged
+Unlikely interpreter will probably help define the language. However
+that project has been deferred as future work, and any clarifications
+that come from it will be incorporated only in a future language
+version.
+
+Discussion
+----------
+
+This section contains some random thoughts and reflections on the
+Unlikely programming language.
+
+There is a rough analogy between Unlikely's requisite dependency
+injection class parameters, and value parameters in languages without
+global variables. There is no implicit referent when you say `Foo`;
+`Foo` must name some parameter that has been passed into scope.
+
+Because all the parts of the language are modelled as objects, the
+language's execution model has some resemblance to an object-oriented
+AST interpreter for itself. Except, of course, these objects are
+continuations, so it is not like a recursive, depth-first walk of the
+AST; it is much closer to the technique of threading the AST and
+following that thread.
+
+At one point I included the constraint that the set of dependant classes
+specified by a class must be mutually disjoint; that is, no dependant
+class in the set could be a subclass of some other dependant class in
+the set. I am not entirely sure why I introduced that constraint, since
+it could well be valuable to refine two classes by injection even when
+one of those classes is a subclass of the other. I took it out.
+
+Because properties cannot be redefined in subclasses, and because
+parameters to methods are just syntactic sugar for properties, methods
+cannot be overloaded. In particular `continue` must always work on a
+`Passive` parameter, although of course it is mere convention that the
+method works on the `accumulator` property anyway.
+
+Unlikely is Turing-complete. (I will assert this because it seems
+reasonable to me, but I do not have a proof, so I may be wrong.) The
+Unlikely language is not minimal. In particular, the `Loop` class and
+its subclasses `WhileLoop` and `ForLoop` could be removed, and the
+resulting language would still be Turing-complete. In fact, `WhileLoop`
+and `ForLoop` could probably be implemented in Unlikely and provided in
+an extension class library.
+
+The idea to conflate contintuations and objects was inspired by the
+data-structure representation of continuations in Chapter 7 of
+[Essentials of Programming Languages, 2nd
+ed.](http://www.cs.indiana.edu/eopl/), which embodies a tiny measure of
+inheritance. The idea that language constructs have commensurate
+inheritance relationships (`WhileLoop` and `ForLoop` are subclasses of
+`Loop`, etc.) was borrowed from Steve Yegge's article [Scheming is
+Believing](http://steve.yegge.googlepages.com/scheming-is-believing).
+The idea that all programs are subclasses of `Program`, which dovetails
+so nicely with that, was borrowed from Brian Connors' "Sulawesi"
+language design. The idea that every concrete value has its own class,
+leading to abstract final classes with countably infinite subclasses,
+was pure desperation.
+
+For the purpose of defining computable functions, the Unlikely-Calculus
+could be considered as a variant of Unlikely without `Print` or `Input`
+classes. The `Stop` class would be there redefined to yield the value
+passed to the accumulator as the result of evaluation, rather than as an
+operating system exit code.
+
+It's a safe bet that there is at least one person out there who will be
+disappointed that this language is named Unlikely yet contains no
+probabilistic design features.
+
+Happy object-method-continuing!  
+Chris Pressey  
+March 15, 2009  
+Bellevue, WA

File doc/unlikely.html

-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml" lang="en">
-<head>
-<title>The Unlikely Programming Language</title>
-<meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
-  <!-- begin html doc dynamic markup -->
-  <script type="text/javascript" src="/contrib/jquery-1.6.4.min.js"></script>
-  <script type="text/javascript" src="/scripts/documentation.js"></script>
-  <!-- end html doc dynamic markup -->
-</head>
-<body>
-
-<h1>The Unlikely Programming Language</h1>
-
-<h2>Overview</h2>
-
-<p><dfn>Unlikely</dfn> is a programming language with the following traits:</p>
-
-<ul>
-<li>Unlikely conflates objects with continuations, and methods with
-labels.  All classes are subclasses of the root class <code>Continuation</code>.
-Every object can be continued at any method.  Every method,
-except for the <code>continue</code> method on the built-in class <code>Stop</code>, must
-continue some other method at the end of its definition.</li>
-<li>All Unlikely program structures are exposed as objects with commensurate
-inheritance relationships.  For example, every Unlikely program is a subclass of <code>Program</code>,
-and the classes <code>If</code> and <code>Switch</code>
-are both subclasses of the abstract base class <code>Branch</code>.</li>
-<li>Unlikely takes dependency injection to the logical extreme.
-<dfn>Dependency injection</dfn> is an increasingly popular modern
-object-oriented program construction technique which allows the specific
-classes which will be used by some class ("dependencies") to be
-specified ("injected") when that class is instantiated.  Unlikely goes
-one step further by <em>requiring</em> that all specific classes used by some
-class are specified during instantiation.</li>
-</ul>
-
-<h2>Semantics</h2>
-
-<h3>Classes</h3>
-
-<p>A class is a schema describing a set of objects.  <dfn>Instantiating</dfn> a class produces a new
-object of that class. When a class is instantiated, all classes that are referenced by the class (<dfn>dependant classes</dfn>)
-must be named (<dfn>injected</dfn>) by the instantiating code (the <dfn>instantiator</dfn>).  For each
-requested dependant class, any subclass of it may be supplied by the instantiator,
-further specifying and constraining behaviour (a technique called <dfn>dependency injection</dfn>).
-In this way, classes are inherently parameterized.</p>
-
-<p>When a class refers to itself, it is considered a dependant class of itself;
-it (or a subclass) must be injected by the instantiator.</p>
-
-<p>All specified dependant classes must be unique (no dependant class may be specified more than
-once.)  Final classes need not and may not be specified as dependant classes because, being final,
-there is no subclass that the instantiator could possibly substitute for them.</p>
-
-<p>Each class may define zero or more <dfn>properties</dfn> and zero or more <dfn>methods</dfn>.</p>
-
-<h4>Inheritance</h4>
-
-<p>Whenever a class is defined in Unlikely source code, a superclass must be named; the class being defined
-is thus a subclass that inherits from that superclass.  Its inheritance consists of the properties
-and methods defined by the superclass and all of its ancestors (i.e. including all properties and
-methods that the superclass inherited from its own superclasses) as well as the dependant
-classes of the superclass.  <!-- XXX is that implemented?? -->
-The subclass may not inject dependencies when inheriting
-from a superclass.  Only single inheritance is supported.</p>
-
-<p>A subclass may override methods that it inherits from its superclass.  It may access
-the method definition of its direct superclass (or any indirect ancestor class)
-by naming that superclass explicitly in a continue.</p>
-
-<p>A class may be declared as <dfn>final</dfn>, in which case it may not be subclassed.
-In addition, final dependant classes may not be injected.</p>
-
-<p>A class may also be declared as <dfn>saturated</dfn>, in which case it can be subclassed,
-but subclasses of it must also be declared as saturated, and they cannot define any new methods.
-They can only override existing methods.
-In fact, the root class <code>Continuation</code> is declared saturated, so really, all objects
-have exactly one method, <code>continue</code>.</p>
-
-<p>If a class defines or inherits any abstract methods, that class must be declared as <dfn>abstract</dfn>.
-Abstract classes cannot be instantiated.
-Any subclass of an abstract class must define all inherited abstract methods
-in order to be considered concrete and thus instantiatable.</p>
-
-<h3>Properties</h3>
-
-<p>Each property has a particular type, which is a class.  The values it may take on
-are objects of that class, or of its subclasses.</p>
-
-<p>Each object has its own instances of the properties defined on the class, and
-each of these properties may take on different values.</p>
-
-<p>All state of an object is stored in its properties.  Properties are effectively
-public; they can be modified by code in any method in any class.</p>
-
-<p>The root class <code>Continuation</code> defines one property, <code>accumulator</code>,
-of type <code>Passive</code>, which all classes inherit.</p>
-
-<p>Subclasses may not override inherited properties.</p>
-
-<h3>Methods</h3>
-
-<p>A method is a label on a piece of code inside a class.  The
-methods of a class are shared by all objects of that class.</p>
-
-<p>A method may be declared <dfn>abstract</dfn> instead of defining
-code for it.  Classes which contain abstract methods must themselves be declared
-abstract.</p>
-
-<p>Only one thing may be done to a method in code, which is to <dfn>continue</dfn> it
-with respect to some object; this is described in the next section.</p>
-
-<p>A method may declare zero or more arguments.  Each argument has a type,
-which is a class.  When a method is continued, a value of the corresponding
-type (or some subclass of that type) must be
-given for each argument.  In actuality, the arguments merely name properties of the
-object; they must already be declared in the class before they are listed
-in the declaration of the method.  Passing values in arguments is just
-shorthand for assigning these properties before continuing the method.</p>
-
-<p>Methods do not have local variables, so for storage must use the properties of 
-the object on which they were continued.</p>
-
-<p>The root class <code>Continuation</code> defines one abstract method which
-subclasses must implement, called <code>continue(Passive accumulator)</code>.  By convention,
-this method is what other methods continue.  The accumulator is passed from continuation
-to continuation, manipulated as execution proceeds.</p>
-
-<h3>Code</h3>
-
-<p>The code inside a class labelled by a method consists of a series of
-<dfn>assignments</dfn> followed by a <dfn>continue</dfn>.</p>
-
-<p>Each assignment consists
-of an object property on the left-hand side, and an expression on the right-hand
-side.  The the property so named will take on the value resulting from evalulating
-the given expression.  Expressions consist of instantiations of new objects, and
-references to other object properties.</p>
-
-<p>The continue names a method on an object to which control
-flow will immediately pass.  It may also pass values as arguments to
-that method; however, this is mere shorthand for assigning properties
-of the object on which the method being continued is defined.
-See above under "Methods" for more details.</p>
-
-<h3>Passive Data</h3>
-
-<p>Passive data values, such as integers and strings,
-are modelled somewhat specially in Unlikely, in order to strike a balance
-in language design between "too straightforward" and "too convoluted".</p>
-
-<p>All passive data values are instances of some subclass of the abstract
-class <code>Passive</code>, which is itself a subclass of <code>Chain</code>.
-When a passive data value is continued, it passes its own value into
-the accumulator of the "next" continuation.  (It is not necessary, however,
-to continue the passive data value to obtain its value in all cases.)</p>
-
-<p>Each immediate subclass of <code>Passive</code> gives a data type of
-values, such as <code>Integer</code> or <code>String</code>.
-Each of these type-classes has a countably infinite number of subclasses,
-one for each possible value of that type.  It is these classes that are instantiated
-to acquire a passive value object.  For example, <code>three = new 3()</code>
-instantiates the value 3.  When the <code>continue</code> method on
-this object is continued, the value that it represents will be passed down the chain to
-the continuation assigned to its <code>next</code> property.
-For example, <code>three.next = new Print()</code> would cause 3 to be
-printed when <code>three</code> was continued.</p>
-
-<p>None of the direct subclasses of <code>Passive</code> can be further
-subclassed.  In effect, they are final (despite being abstract!) because all possible
-subclasses of them already exist.</p>
-
-<h2>Syntax</h2>
-
-<h3>Overview</h3>
-
-<p>The overall schema of a class definition is:</p>
-
-<pre>
-class ClassName(ClassName,ClassName) extends ClassName {
-  ClassName propname;
-  method methodname(ClassName propname, ClassName argname) {
-    propname = new ClassName(ClassName,ClassName);
-    propname.propertyname = argname;
-    goto expr.methodname(expr,expr);
-  }
-}
-</pre>
-
-<h3>Grammar</h3>
-
-<p>A somewhat more formal definition of the syntactic structure of Unlikely code is given in the following EBNF-like grammar.</p>
-
-<pre>
-ClassBase   ::= {ClassDefn}.
-ClassDefn   ::= "class" ClassName&lt;NEW&gt; "(" [ClassName {"," ClassName}] ")" "extends" ClassName
-                ["{" {PropDefn} {MethodDefn} "}"] ["is" ClassMod {"and" ClassMod}].
-ClassMod    ::= "final" | "saturated" | "abstract".
-PropDefn    ::= ClassName PropName&lt;NEW&gt; ";".
-MethodDefn  ::= "method" MethodName&lt;NEW&gt; "(" [ParamDecl {"," ParamDecl}] ")"
-                ("{" {Assignment} Continue "}" | "is" "abstract").
-ParamDecl   ::= ClassName PropName.
-Assignment  ::= QualName "=" Expr ";".
-Continue    ::= "goto" PropName "." MethodName "(" [Expr {"," Expr}] ")" ";".
-Expr        ::= ConstrExpr | QualName.
-ConstrExpr  ::= "new" (ClassName | Constant) "(" [ClassName {"," ClassName}] ")".
-QualName    ::= PropName {"." PropName}.
-ClassName   ::= &lt;&lt;sequence of alphabetic characters&gt;&gt; | Constant.
-Constant    ::= &lt;&lt;sequence of decimal digits&gt;&gt; | &lt;&lt;sequence of arbitrary characters between double quotes&gt;&gt;.
-</pre>
-
-<p>Note that multiple ClassDefns for a single class may appear; each may partially define the class.  In this way
-a "forward declaration" of a class may occur.  This may give its name, superclass, and dependant classes, so these can be
-consumed by some following class that requires them, before the methods of this class are defined.
-The dependant classes are cumulative over successive partial definitions; they need not be repeated.
-However the same superclass must be specified for all partial definitions of a class.</p>
-
-<h2>Built-in Classes</h2>
-
-<ul>
-  <li>
-    <code>Continuation</code>
-    <p>The abstract base class that is the superclass of all Unlikely classes, and which can't be instantiated.
-    Declares the property <code>Passive accumulator</code>, and the
-    abstract method <code>continue(Passive accumulator)</code>, which all concrete subclasses
-    must implement.  Is declared <code>saturated</code>, so no subclass may declare or define any additional methods.</p>
-    <ul>
-      <li><code>Program</code>
-        <p>An abstract continuation that provides the guarantee that it can be started
-        (that is, that its <code>continue</code> method can be initially continued) from
-        the operating system.
-        It can be reasonably expected that the <code>accumulator</code> will be
-        assigned a value provided by the user, perhaps via a command-line argument.</p>
-        <ul>
-          <li><code>Stop</code>
-            <p>A concrete continuation which exits to the operating system when continued.
-            The accumulator is used as the exit code, assuming the operating system supports this.</p>
-          </li>
-          <li><code>Chain</code>
-            <p>An abstract continuation which defines the property <code>Continuation next</code>.
-            When a subclass of <code>Chain</code> is continued, it will generally continue
-            the continuation assigned to its <code>next</code> property after doing something.</p>
-            <ul>
-              <li><code>Passive</code>
-                <p>The abstract final base class representing passive data values.  Discards whatever accumulator was passed
-                to it, and passes its own value into the accumulator
-                when it continues the continuation assigned to its <code>next</code> property.</p>
-                <ul>
-                  <li><code>Boolean</code>
-                    <p>The abstract final base class representing boolean values.</p>
-                    <ul>
-                      <li>
-                        <code>True</code>,
-                        <code>False</code>
-                        <p>Final classes representing particular boolean values.</p>
-                      </li>
-                    </ul>
-                  </li>
-                  <li><code>Integer</code>
-                    <p>The abstract final base class representing integer values.</p>
-                    <ul>
-                      <li>
-                        <code>0</code>,
-                        <code>1</code>,
-                        <code>2</code>...
-                        <p>Final classes representing particular integer values.  Note that only positive constants
-                        are available; negative values must be computed by subtracting from 0.</p>
-                      </li>
-                    </ul>
-                  </li>
-                  <li><code>String</code>
-                    <p>The abstract final class representing string values.</p>
-                    <ul>
-                      <li>
-                        <code>""</code>,
-                        <code>"a"</code>,
-                        <code>"b"</code>,
-                        <code>"aa"</code>...
-                        <p>Final classes representing particular string values.</p>
-                      </li>
-                    </ul>
-                  </li>
-                </ul>
-              </li>
-              <li><code>BinaryOperation</code>
-                <p>A continuation which posesses a property <code>value</code>
-                and which yields a value when continued by applying
-                some operation to <code>value</code> (treated as LHS) and
-                the accumulator (treated as RHS.)</p>
-                <ul>
-                  <li>
-                    <code>Add</code>
-                    <p>A concrete binary operation which adds <code>value</code> to the
-                    accumulator and passes the result when continuing <code>next</code>.</p>
-                  </li>
-                  <li>
-                    <code>Subtract</code>
-                    <p>A concrete binary operation which subtracts the accumulator from <code>value</code>
-                    and passes the result when continuing <code>next</code>.</p>
-                  </li>
-                  <li>
-                    <code>Multiply</code>
-                    <p>A concrete binary operation which multiplies <code>value</code> by the
-                    accumulator and passes the result when continuing <code>next</code>.</p>
-                  </li>
-                  <li>
-                    <code>Divide</code>
-                    <p>A concrete binary operation which divides <code>value</code> by the accumulator
-                    and passes the result when continuing <code>next</code>.</p>
-                  </li>
-                  <li>
-                    <code>Condition</code>
-                    <p>A BinaryOperation which yields a boolean value.</p>
-                    <ul>
-                      <li>
-                        <code>Equal</code>
-                        <p>A concrete binary operation which compares <code>value</code> to the accumulator
-                        and passes True when continuing <code>next</code> only if they are equal.</p>
-                      </li>
-                      <li>
-                        <code>GreaterThan</code>
-                        <p>A concrete binary operation which compares <code>value</code> to the accumulator
-                        and passes True when continuing <code>next</code> only if <code>value</code> is greater.</p>
-                      </li>
-                    </ul>
-                  </li>
-                </ul>
-              </li>
-              <li><code>Print</code>
-                <p>A concrete continuation which displays the value of the accumulator to the user before continuing
-                its <code>next</code> property.</p>
-              </li>
-              <li><code>Input</code>
-                <p>A concrete continuation which obtains a value from the user, and passes this value in the accumulator when continuing
-                its <code>next</code> property.</p>
-              </li>
-              <li><code>Branch</code>
-                <p>An abstract continuation which continues one of the continuations assigned to its properties,
-                based on some other information.  Defines the <code>Chain</code> property <code>else</code>
-                which represents the basic alternate continuation that can be continued instead of <code>next</code>.</p>
-                <ul>
-                  <li><code>If</code>
-                    <p>A continuation which continues one of two continuations assigned to its properties,
-                    <code>next</code> and <code>else</code>, based on whether
-                    the accumulator is an instance of <code>True</code> or <code>False</code>.</p>
-                  </li>
-                  <li><code>Switch</code>
-                    <p>An abstract continuation whose behaviour differs on subsequent times it is continued.
-                    This is implemented by means of a <code>state</code> property which changes values each
-                    time the switch is continued; depending on the value of <code>state</code>, different
-                    things happen.</p>
-                    <ul>
-                      <li><code>Loop</code>
-                        <p>An abstract continuation which is intended to implement a loop.  However, this is not
-                        automatic; some continuation chain leading from this continuation <em>must</em> lead back
-                        to this continuation in order for actual repetition to take place.</p>
-                        <ul>
-                          <li><code>WhileLoop</code>
-                            <p>A concrete <code>Loop</code> which, on odd visits continues its <code>test</code> property.
-                            It is assumed that some continuation down that chain continues this <code>WhileLoop</code>
-                            object with a boolean value in the accumulator.  On these even visits, it will behave like
-                            an <code>If</code>: when the boolean is a <code>True</code>, <code>next</code>
-                            is continued, otherwise <code>else</code>.</p>
-                          </li>
-                          <li><code>ForLoop</code>
-                            <p>A concrete <code>Loop</code> which defines <code>value</code>, <code>delta</code>,
-                            and <code>finish</code> properties, all <code>Integer</code>s.  On each visit, it
-                            checks if <code>value</code> equals <code>finish</code>; if not, it adds <code>delta</code>
-                            to <code>value</code> and continues <code>next</code>.  But if so, it simply continues
-                            <code>else</code>.</p>
-                          </li>
-                        </ul>
-                      </li>
-                    </ul>
-                  </li>
-                </ul>
-              </li>
-            </ul>
-          </li>
-        </ul>
-      </li>
-    </ul>
-  </li>
-</ul>
-
-<h2>Implementations</h2>
-
-<p>There is not currently a reference implementation of Unlikely.  Any
-contradictions and/or grey areas in this document will therefore have
-nowhere to turn to to be cleared up.</p>
-
-<p>There is, however, a partial and non-normative implementation of Unlikely,
-a static analyzer written in Python called <dfn>Coldwater</dfn>.  It parses Unlikely
-programs and identifies many type errors and other statically-detectable invalid
-programs.  It is meant to give some body to the ideas present in Unlikely,
-without actually going so far as implementing it in full.</p>
-
-<p>The construction of Coldwater helped
-clear up some of the fuzzier corners of the language.  However, there are probably
-several areas that remain fuzzy and render the language unsuitable for anything but
-the most trivial programming.  Extending
-Coldwater to be a full-fledged Unlikely interpreter will probably help define
-the language.  However that project has been deferred as future work, and any
-clarifications that come from it will be incorporated only in a future language version.</p>
-
-<h2>Discussion</h2>
-
-<p>This section contains some random thoughts and reflections
-on the Unlikely programming language.</p>
-
-<p>There is a rough analogy between Unlikely's requisite dependency injection class
-parameters, and value parameters in languages without global variables.  There
-is no implicit referent when you say <code>Foo</code>; <code>Foo</code> must name some
-parameter that has been passed into scope.</p>
-
-<p>Because all the parts of the language are modelled as objects, the language's
-execution model has some resemblance to an object-oriented AST interpreter for itself.
-Except, of course, these objects are continuations, so it is not like a recursive,
-depth-first walk of the AST; it is much closer to the technique of threading the
-AST and following that thread.</p>
-
-<p>At one point I included the constraint that the set of dependant classes specified
-by a class must be mutually disjoint; that is, no dependant class in the set could be a
-subclass of some other dependant class in the set.  I am not entirely sure why I
-introduced that constraint, since it could well be valuable to refine two classes by
-injection even when one of those classes is a subclass of the other.  I took it out.</p>
-
-<p>Because properties cannot be redefined in subclasses, and because parameters
-to methods are just syntactic sugar for properties, methods cannot be overloaded.
-In particular <code>continue</code> must always work on a <code>Passive</code>
-parameter, although of course it is mere convention that the method works on the
-<code>accumulator</code> property anyway.</p>
-
-<p>Unlikely is Turing-complete.  (I will assert this because it seems reasonable
-to me, but I do not have a proof, so I may be wrong.)  The Unlikely language is not minimal.  In
-particular, the <code>Loop</code> class
-and its subclasses <code>WhileLoop</code> and <code>ForLoop</code> could be removed,
-and the resulting language would still be Turing-complete.  In fact, <code>WhileLoop</code>
-and <code>ForLoop</code> could probably be implemented in Unlikely and provided in an
-extension class library.</p>
-
-<p>The idea to conflate contintuations and objects was inspired by the data-structure representation of continuations
-in Chapter 7 of <a class="external" href="http://www.cs.indiana.edu/eopl/">Essentials of Programming Languages, 2nd ed.</a>,
-which embodies a tiny measure of inheritance.  The idea that language constructs have commensurate inheritance relationships (<code>WhileLoop</code>
-and <code>ForLoop</code> are subclasses of <code>Loop</code>, etc.) was borrowed from Steve Yegge's article
-<a class="external" href="http://steve.yegge.googlepages.com/scheming-is-believing">Scheming is Believing</a>.
-The idea that all programs are subclasses of <code>Program</code>, which dovetails so nicely with that,
-was borrowed from Brian Connors' "Sulawesi" language design.  The idea that every concrete value has its own class, leading to
-abstract final classes with countably infinite subclasses, was pure desperation.</p>
-
-<p>For the purpose of defining computable functions, the <dfn>Unlikely-Calculus</dfn>
-could be considered as a variant of Unlikely without <code>Print</code> or <code>Input</code>
-classes.  The <code>Stop</code> class would be there redefined to yield the value passed to
-the accumulator as the result of evaluation, rather than as an operating system exit code.</p>
-
-<p>It's a safe bet that there is at least one person out there who will be disappointed that
-this language is named Unlikely yet contains no probabilistic design features.</p>
-
-<p>Happy object-method-continuing!
-<br/>Chris Pressey
-<br/>March 15, 2009
-<br/>Bellevue, WA</p>
-
-</body>
-</html>