git » jacl.git » commit cc36875

diff --git a/README.md b/README.md
index 4c9fb63..43edbd9 100644
--- a/README.md
+++ b/README.md
@@ -7,25 +7,39 @@ Specifically, the project goals are to:
 3. Host as much development tooling as possible in the browser so that tools may organically evolve with the applications they’re used to build
 4. Support the delivery of applications competitive in size and speed with respect to those produced by JavaScript tools
 
-Why not JavaScript?
-
-The JavaScript language is Lisp-like in that it is garbage-collected, dynamically typed, and multi-paradigm. However, developing applications incrementally in a REPL in the traditional Lisp way is not well supported because JavaScript does not have a system of first-class global names.
-
-JavaScript modules are files that represent a closure, and the entire file must be reloaded in order for the names exported by the closure to be re-instantiated. Dependent files must also be reloaded. The necessity of reloading whole programs after making small changes orients JavaScript toward batch development workflows traditionally associated with statically-typed languages (and away from the incremental workflows traditionally associated with Lisp).
-
-A testament to this trend is the growing popularity of JavaScript with type inference extensions. Despite JavaScript being manifestly typed, the JavaScript REPL experience is so impoverished that developers find more value in writing type descriptions than in running program fragments interactively.
-
-OK, so why not add first-class global namespaces/packages to JavaScript?
-
-A good namespace system could be built as a library, but because programs are filled with references to library functions — and because each reference would necessarily look like a field access or function call — the code would be quite noisy.
-
-Thus, a namespace system requires syntax support in order to be practical. The best syntax support possible, for anything, is Lisp syntax.
-
-OK, but why Common Lisp (CL)?
-
-In short: because it’s good enough. Despite its warts, CL is a well-specified and multi-paradigm language. Most importantly, it is a proven substrate for performing incremental development and prototyping new ideas.
-
-
-Special Variables
-
-Unwinding must happen in a finally block
+## Why not JavaScript?
+
+The JavaScript language is Lisp-like in that it is garbage-collected,
+dynamically typed, and multi-paradigm. However, developing applications
+incrementally in a REPL in the traditional Lisp way is not well supported
+because JavaScript does not have a system of first-class global names.
+
+JavaScript modules are files that represent a closure, and the entire file must
+be reloaded in order for the names exported by the closure to be
+re-instantiated. Dependent files must then also be reloaded. The necessity of
+reloading whole programs after making small changes orients JavaScript toward
+batch development workflows traditionally associated with statically-typed
+languages (and away from the incremental workflows traditionally associated with
+Lisp).
+
+A testament to this trend is the growing popularity of JavaScript with type
+inference extensions. Despite JavaScript being manifestly typed, the JavaScript
+REPL experience is so impoverished that developers find more value in running
+their type checker than in running their program interactively.
+
+## OK, so why not add first-class global namespaces/packages to JavaScript?
+
+A good namespace system could be built as a library, but because programs are
+filled with references to library functions — and because each reference would
+necessarily look like a field access or function call — the code would be quite
+noisy. Global names would also need to be installed using something like a
+function call.
+
+Thus, a namespace system requires syntax support in order to be practical. The
+best syntax support possible, for anything, is Lisp syntax.
+
+## OK, but why Common Lisp (CL)?
+
+In short: because it’s good enough. Despite its warts, CL is a well-specified
+and multi-paradigm language. Most importantly, it is a proven substrate for
+performing incremental development and prototyping new ideas.