diff --git a/documentation/website/.gitignore b/documentation/website/.gitignore
new file mode 100644
index 0000000000..3b3d49146a
--- /dev/null
+++ b/documentation/website/.gitignore
@@ -0,0 +1,3 @@
+build
+\#*
+*~
\ No newline at end of file
diff --git a/documentation/website/.gitmodules b/documentation/website/.gitmodules
new file mode 100644
index 0000000000..e69de29bb2
diff --git a/documentation/website/Makefile b/documentation/website/Makefile
new file mode 100644
index 0000000000..0526e8eeb8
--- /dev/null
+++ b/documentation/website/Makefile
@@ -0,0 +1,48 @@
+# Makefile for Sphinx documentation
+#
+
+# You can set these variables from the command line.
+SPHINXOPTS    =
+SPHINXBUILD   = sphinx-build
+BUILDDIR      = build
+
+# Internal variables.
+ALLSPHINXOPTS   = -d $(BUILDDIR)/doctrees $(SPHINXOPTS) source
+# the i18n builder cannot share the environment and doctrees with the others
+I18NSPHINXOPTS  = $(SPHINXOPTS) source
+
+.PHONY: help clean html gettext changes linkcheck
+
+all: html
+
+help:
+	@echo "Please use \`make <target>' where <target> is one of"
+	@echo "  html       to make standalone HTML files"
+	@echo "  gettext    to make PO message catalogs"
+	@echo "  changes    to make an overview of all changed/added/deprecated items"
+	@echo "  linkcheck  to check all external links for integrity"
+
+clean:
+	-rm -rf $(BUILDDIR)/*
+
+html:
+	$(SPHINXBUILD) -b html $(ALLSPHINXOPTS) $(BUILDDIR)/html
+	@echo
+	@echo "Build finished. The HTML pages are in $(BUILDDIR)/html."
+
+gettext:
+	$(SPHINXBUILD) -b gettext $(I18NSPHINXOPTS) $(BUILDDIR)/locale
+	@echo
+	@echo "Build finished. The message catalogs are in $(BUILDDIR)/locale."
+
+changes:
+	$(SPHINXBUILD) -b changes $(ALLSPHINXOPTS) $(BUILDDIR)/changes
+	@echo
+	@echo "The overview file is in $(BUILDDIR)/changes."
+
+linkcheck:
+	$(SPHINXBUILD) -b linkcheck $(ALLSPHINXOPTS) $(BUILDDIR)/linkcheck
+	@echo
+	@echo "Link check complete; look for any errors in the above output " \
+	      "or in $(BUILDDIR)/linkcheck/output.txt."
+
diff --git a/documentation/website/README.rst b/documentation/website/README.rst
new file mode 100644
index 0000000000..f46e388de4
--- /dev/null
+++ b/documentation/website/README.rst
@@ -0,0 +1,82 @@
+This is the Open Dylan website.
+
+It is built using `Sphinx <https://www.sphinx-doc.org/>`_.  All content is
+written using ReStructured Text with Sphinx extensions.
+
+Installation
+============
+
+Some system dependencies need to be satisfied first.  On a Debian-derivative
+this should work::
+
+    sudo apt install git graphviz make python3
+
+Install a Python3 virtual environment and use ``pip`` rather than the ``apt``
+Python packages, which are sometimes very out-of-date. ::
+
+    python3 -m venv /opt/python3-venv
+    export PATH=/opt/python3-venv/bin:${PATH}
+    pip install Sphinx furo
+
+The next step is fetching the repository and its dependencies::
+
+    git clone https://github.com/dylan-lang/website.git
+    cd website
+    deft update    # Install Dylan package dependencies
+
+Building the site
+=================
+
+Simply run the :file:`update.sh` script, specifying where you want the HTML
+files to be generated::
+
+    update.sh /tmp/opendylan.org
+
+The first time you run :file:`update.sh`, it will build the `gendoc
+<https://github.com/dylan-lang/gendoc>`_ executable, which takes a bit longer.
+
+.. note:: Currently the downloads directory is still maintained by hand. When
+          building the live site the first time, copy the files from the old
+          location.
+
+Testing
+=======
+
+The generated site will be in the output directory you specified. Run a local
+server using that directory as a static site. For example::
+
+    python3 -m http.server --directory /tmp/opendylan.org
+
+For bonus points, you can eat our own dogfood and run the Dylan HTTP server
+instead::
+
+    git clone --recursive https://github.com/dylan-lang/http
+    cd http
+    make install
+    http-server --directory /tmp/opendylan.org
+
+Link Validation
+---------------
+
+Sphinx also makes it easy to check that all of the links to external sites
+are valid.  You can run the link checker by::
+
+    make linkcheck
+
+Site Maintenance
+================
+
+New Binary Release of Open Dylan
+--------------------------------
+
+#. Update the appropriate info on the download page.
+
+
+Updating Documentation
+----------------------
+
+The `update-opendylan.org.sh` script is run by cron to update the
+documentation in various repositories by essentially doing a git pull
+and make html.
+
+*TODO:* more info here.
diff --git a/documentation/website/dylan-package.json b/documentation/website/dylan-package.json
new file mode 100644
index 0000000000..138d984ec3
--- /dev/null
+++ b/documentation/website/dylan-package.json
@@ -0,0 +1,16 @@
+{
+    "name": "website",
+    "version": "0.1.0",
+    "description": "The opendylan.org website and tools to build it.",
+    "contact": "dylan-lang@googlegroups.com",
+    "keywords": ["documentation"],
+    "dependencies": [],
+    "dev-dependencies": [
+        "dylan-reference-manual",
+        "dylan-programming-book",
+        "gendoc",
+        "opendylan",
+        "sphinx-extensions"
+    ],
+    "url": "https://github.com/dylan-lang/website"
+}
diff --git a/documentation/website/make.bat b/documentation/website/make.bat
new file mode 100644
index 0000000000..ceaa3be2d5
--- /dev/null
+++ b/documentation/website/make.bat
@@ -0,0 +1,63 @@
+@ECHO OFF
+
+REM Command file for Sphinx documentation
+
+if "%SPHINXBUILD%" == "" (
+	set SPHINXBUILD=sphinx-build
+)
+set BUILDDIR=build
+set ALLSPHINXOPTS=-d %BUILDDIR%/doctrees %SPHINXOPTS% source
+set I18NSPHINXOPTS=%SPHINXOPTS% source
+
+if "%1" == "" goto help
+
+if "%1" == "help" (
+	:help
+	echo.Please use `make ^<target^>` where ^<target^> is one of
+	echo.  html       to make standalone HTML files
+	echo.  gettext    to make PO message catalogs
+	echo.  changes    to make an overview over all changed/added/deprecated items
+	echo.  linkcheck  to check all external links for integrity
+	goto end
+)
+
+if "%1" == "clean" (
+	for /d %%i in (%BUILDDIR%\*) do rmdir /q /s %%i
+	del /q /s %BUILDDIR%\*
+	goto end
+)
+
+if "%1" == "html" (
+	%SPHINXBUILD% -b html %ALLSPHINXOPTS% %BUILDDIR%/html
+	if errorlevel 1 exit /b 1
+	echo.
+	echo.Build finished. The HTML pages are in %BUILDDIR%/html.
+	goto end
+)
+
+if "%1" == "gettext" (
+	%SPHINXBUILD% -b gettext %I18NSPHINXOPTS% %BUILDDIR%/locale
+	if errorlevel 1 exit /b 1
+	echo.
+	echo.Build finished. The message catalogs are in %BUILDDIR%/locale.
+	goto end
+)
+
+if "%1" == "changes" (
+	%SPHINXBUILD% -b changes %ALLSPHINXOPTS% %BUILDDIR%/changes
+	if errorlevel 1 exit /b 1
+	echo.
+	echo.The overview file is in %BUILDDIR%/changes.
+	goto end
+)
+
+if "%1" == "linkcheck" (
+	%SPHINXBUILD% -b linkcheck %ALLSPHINXOPTS% %BUILDDIR%/linkcheck
+	if errorlevel 1 exit /b 1
+	echo.
+	echo.Link check complete; look for any errors in the above output ^
+or in %BUILDDIR%/linkcheck/output.txt.
+	goto end
+)
+
+:end
diff --git a/documentation/website/source/_static/c3-linearization.pdf b/documentation/website/source/_static/c3-linearization.pdf
new file mode 100644
index 0000000000..bddc90cf8a
Binary files /dev/null and b/documentation/website/source/_static/c3-linearization.pdf differ
diff --git a/documentation/website/source/_static/dep-0001-states.png b/documentation/website/source/_static/dep-0001-states.png
new file mode 100644
index 0000000000..51eb2b2582
Binary files /dev/null and b/documentation/website/source/_static/dep-0001-states.png differ
diff --git a/documentation/website/source/_static/documentation/bachrach1999.bib b/documentation/website/source/_static/documentation/bachrach1999.bib
new file mode 100644
index 0000000000..0ec4868343
--- /dev/null
+++ b/documentation/website/source/_static/documentation/bachrach1999.bib
@@ -0,0 +1,6 @@
+@techreport{Bachrach:1999,
+ author = {Bachrach, Jonathan and Playford, Keith},
+ title = {D-Expressions: Lisp Power, Dylan Style},
+ year = {1999},
+ source = {http://people.csail.mit.edu/jrb/Projects/dexprs.pdf},
+}
diff --git a/documentation/website/source/_static/documentation/bachrach2000.bib b/documentation/website/source/_static/documentation/bachrach2000.bib
new file mode 100644
index 0000000000..086a49f66c
--- /dev/null
+++ b/documentation/website/source/_static/documentation/bachrach2000.bib
@@ -0,0 +1,6 @@
+@techreport{Bachrach:2000,
+ author = {Bachrach, Jonathan and Burke, Glemm},
+ title = {Partial Dispatch: Optimizing Dynamically-Dispatched Multimethod Calls with Compile-Time Types and Runtime Feedback},
+ year = {2000},
+ source = {http://people.csail.mit.edu/jrb/Projects/pd.pdf},
+}
diff --git a/documentation/website/source/_static/documentation/barrett1996.bib b/documentation/website/source/_static/documentation/barrett1996.bib
new file mode 100644
index 0000000000..298be12c99
--- /dev/null
+++ b/documentation/website/source/_static/documentation/barrett1996.bib
@@ -0,0 +1,34 @@
+@article{Barrett:1996:MSL:236338.236343,
+ author = {Barrett, Kim and Cassels, Bob and Haahr, Paul and Moon, David A. and Playford, Keith and Withington, P. Tucker},
+ title = {A monotonic superclass linearization for Dylan},
+ journal = {SIGPLAN Not.},
+ volume = {31},
+ issue = {10},
+ month = {October},
+ year = {1996},
+ issn = {0362-1340},
+ pages = {69--82},
+ numpages = {14},
+ url = {http://doi.acm.org/10.1145/236338.236343},
+ doi = {http://doi.acm.org/10.1145/236338.236343},
+ acmid = {236343},
+ publisher = {ACM},
+ address = {New York, NY, USA},
+}
+
+@inproceedings{Barrett:1996:MSL:236337.236343,
+ author = {Barrett, Kim and Cassels, Bob and Haahr, Paul and Moon, David A. and Playford, Keith and Withington, P. Tucker},
+ title = {A monotonic superclass linearization for Dylan},
+ booktitle = {Proceedings of the 11th ACM SIGPLAN conference on Object-oriented programming, systems, languages, and applications},
+ series = {OOPSLA '96},
+ year = {1996},
+ isbn = {0-89791-788-X},
+ location = {San Jose, California, United States},
+ pages = {69--82},
+ numpages = {14},
+ url = {http://doi.acm.org/10.1145/236337.236343},
+ doi = {http://doi.acm.org/10.1145/236337.236343},
+ acmid = {236343},
+ publisher = {ACM},
+ address = {New York, NY, USA},
+}
diff --git a/documentation/website/source/_static/documentation/dumas1995.bib b/documentation/website/source/_static/documentation/dumas1995.bib
new file mode 100644
index 0000000000..302117c967
--- /dev/null
+++ b/documentation/website/source/_static/documentation/dumas1995.bib
@@ -0,0 +1,17 @@
+@article{Dumas:1995:DWP:203241.203253,
+ author = {Dumas, Joseph and Parsons, Paige},
+ title = {Discovering the way programmers think about new programming environments},
+ journal = {Commun. ACM},
+ volume = {38},
+ issue = {6},
+ month = {June},
+ year = {1995},
+ issn = {0001-0782},
+ pages = {45--56},
+ numpages = {12},
+ url = {http://doi.acm.org/10.1145/203241.203253},
+ doi = {http://doi.acm.org/10.1145/203241.203253},
+ acmid = {203253},
+ publisher = {ACM},
+ address = {New York, NY, USA},
+}
\ No newline at end of file
diff --git a/documentation/website/source/_static/documentation/gray1998.bib b/documentation/website/source/_static/documentation/gray1998.bib
new file mode 100644
index 0000000000..86669f43cc
--- /dev/null
+++ b/documentation/website/source/_static/documentation/gray1998.bib
@@ -0,0 +1,17 @@
+@article{Gray:1998:MLM:274946.274957,
+ author = {Gray, David N. and Hotchkiss, John and LaForge, Seth and Shalit, Andrew and Weinberg, Toby},
+ title = {Modern languages and Microsoft's component object model},
+ journal = {Commun. ACM},
+ volume = {41},
+ issue = {5},
+ month = {May},
+ year = {1998},
+ issn = {0001-0782},
+ pages = {55--65},
+ numpages = {11},
+ url = {http://doi.acm.org/10.1145/274946.274957},
+ doi = {http://doi.acm.org/10.1145/274946.274957},
+ acmid = {274957},
+ publisher = {ACM},
+ address = {New York, NY, USA},
+}
diff --git a/documentation/website/source/_static/documentation/housel_peter_s_2020_3742567.bib b/documentation/website/source/_static/documentation/housel_peter_s_2020_3742567.bib
new file mode 100644
index 0000000000..861f3c0c10
--- /dev/null
+++ b/documentation/website/source/_static/documentation/housel_peter_s_2020_3742567.bib
@@ -0,0 +1,9 @@
+@misc{housel_peter_s_2020_3742567,
+  author       = {Housel, Peter S.},
+  title        = {LLVM Code Generation for Open Dylan},
+  month        = apr,
+  year         = 2020,
+  publisher    = {Zenodo},
+  doi          = {10.5281/zenodo.3742567},
+  url          = {https://doi.org/10.5281/zenodo.3742567}
+}
\ No newline at end of file
diff --git a/documentation/website/source/_static/documentation/kidd2001.bib b/documentation/website/source/_static/documentation/kidd2001.bib
new file mode 100644
index 0000000000..71297ed4ee
--- /dev/null
+++ b/documentation/website/source/_static/documentation/kidd2001.bib
@@ -0,0 +1,8 @@
+@techreport{Kidd:2001:ECG:867862,
+ author = {Kidd, Eric},
+ title = {Efficient Compression of Generic Function Dispatch Tables},
+ year = {2001},
+ source = {http://www.ncstrl.org:8900/ncstrl/servlet/search?formname=detail\&id=oai%3Ancstrlh%3Adartmouthcs%3Ancstrl.dartmouthcs%2F%2FTR2001-404},
+ publisher = {Dartmouth College},
+ address = {Hanover, NH, USA},
+}
diff --git a/documentation/website/source/_static/documentation/mehnert2007.bib b/documentation/website/source/_static/documentation/mehnert2007.bib
new file mode 100644
index 0000000000..b8cfbf739f
--- /dev/null
+++ b/documentation/website/source/_static/documentation/mehnert2007.bib
@@ -0,0 +1,17 @@
+@inproceedings{Mehnert:2007:DLM:1622123.1622148,
+ author = {Mehnert, Hannes and Bogk, Andreas},
+ title = {A domain-specific language for manipulation of binary data in Dylan},
+ booktitle = {Proceedings of the 2007 International Lisp Conference},
+ series = {ILC '07},
+ year = {2009},
+ isbn = {978-1-59593-618-9},
+ location = {Cambridge, United Kingdom},
+ pages = {22:1--22:8},
+ articleno = {22},
+ numpages = {8},
+ url = {http://doi.acm.org/10.1145/1622123.1622148},
+ doi = {http://doi.acm.org/10.1145/1622123.1622148},
+ acmid = {1622148},
+ publisher = {ACM},
+ address = {New York, NY, USA},
+}
diff --git a/documentation/website/source/_static/documentation/mehnert2009.bib b/documentation/website/source/_static/documentation/mehnert2009.bib
new file mode 100644
index 0000000000..9cca0cd829
--- /dev/null
+++ b/documentation/website/source/_static/documentation/mehnert2009.bib
@@ -0,0 +1,8 @@
+@inproceedings{Mehnert:2009,
+ author = {Mehnert, Hannes},
+ title = {Automatically generated type-safe GTK+ binding for Dylan},
+ booktitle = {Proceedings of the 2009 International Lisp Conference},
+ series = {ILC '09},
+ year = {2009},
+ location = {Cambridge, MA, USA},
+}
diff --git a/documentation/website/source/_static/documentation/mehnert2010.bib b/documentation/website/source/_static/documentation/mehnert2010.bib
new file mode 100644
index 0000000000..57fa55898e
--- /dev/null
+++ b/documentation/website/source/_static/documentation/mehnert2010.bib
@@ -0,0 +1,17 @@
+@inproceedings{Mehnert:2010:EDT:1869643.1869645,
+ author = {Mehnert, Hannes},
+ title = {Extending Dylan's type system for better type inference and error detection},
+ booktitle = {Proceedings of the 2010 international conference on Lisp},
+ series = {ILC '10},
+ year = {2010},
+ isbn = {978-1-4503-0470-2},
+ location = {Reno/Tahoe, Nevada, USA},
+ pages = {1--10},
+ numpages = {10},
+ url = {http://doi.acm.org/10.1145/1869643.1869645},
+ doi = {http://doi.acm.org/10.1145/1869643.1869645},
+ acmid = {1869645},
+ publisher = {ACM},
+ address = {New York, NY, USA},
+ keywords = {compilers, dylan, dynamic typing, generic functions, gradual typing, lisp, multimethods, multiple dispatch, object-orientation, static typing, type inference},
+} 
diff --git a/documentation/website/source/_static/documentation/publications.bib b/documentation/website/source/_static/documentation/publications.bib
new file mode 100644
index 0000000000..19c4e8bbc6
--- /dev/null
+++ b/documentation/website/source/_static/documentation/publications.bib
@@ -0,0 +1,138 @@
+@inproceedings{Mehnert:2010:EDT:1869643.1869645,
+ author = {Mehnert, Hannes},
+ title = {Extending Dylan's type system for better type inference and error detection},
+ booktitle = {Proceedings of the 2010 international conference on Lisp},
+ series = {ILC '10},
+ year = {2010},
+ isbn = {978-1-4503-0470-2},
+ location = {Reno/Tahoe, Nevada, USA},
+ pages = {1--10},
+ numpages = {10},
+ url = {http://doi.acm.org/10.1145/1869643.1869645},
+ doi = {http://doi.acm.org/10.1145/1869643.1869645},
+ acmid = {1869645},
+ publisher = {ACM},
+ address = {New York, NY, USA},
+ keywords = {compilers, dylan, dynamic typing, generic functions, gradual typing, lisp, multimethods, multiple dispatch, object-orientation, static typing, type inference},
+}
+
+@inproceedings{Mehnert:2009,
+ author = {Mehnert, Hannes},
+ title = {Automatically generated type-safe GTK+ binding for Dylan},
+ booktitle = {Proceedings of the 2009 International Lisp Conference},
+ series = {ILC '09},
+ year = {2009},
+ location = {Cambridge, MA, USA},
+}
+
+@inproceedings{Mehnert:2007:DLM:1622123.1622148,
+ author = {Mehnert, Hannes and Bogk, Andreas},
+ title = {A domain-specific language for manipulation of binary data in Dylan},
+ booktitle = {Proceedings of the 2007 International Lisp Conference},
+ series = {ILC '07},
+ year = {2009},
+ isbn = {978-1-59593-618-9},
+ location = {Cambridge, United Kingdom},
+ pages = {22:1--22:8},
+ articleno = {22},
+ numpages = {8},
+ url = {http://doi.acm.org/10.1145/1622123.1622148},
+ doi = {http://doi.acm.org/10.1145/1622123.1622148},
+ acmid = {1622148},
+ publisher = {ACM},
+ address = {New York, NY, USA},
+}
+
+@techreport{Kidd:2001:ECG:867862,
+ author = {Kidd, Eric},
+ title = {Efficient Compression of Generic Function Dispatch Tables},
+ year = {2001},
+ source = {http://www.ncstrl.org:8900/ncstrl/servlet/search?formname=detail\&id=oai%3Ancstrlh%3Adartmouthcs%3Ancstrl.dartmouthcs%2F%2FTR2001-404},
+ publisher = {Dartmouth College},
+ address = {Hanover, NH, USA},
+}
+
+@techreport{Bachrach:2000,
+ author = {Bachrach, Jonathan and Burke, Glemm},
+ title = {Partial Dispatch: Optimizing Dynamically-Dispatched Multimethod Calls with Compile-Time Types and Runtime Feedback},
+ year = {2000},
+ source = {http://people.csail.mit.edu/jrb/Projects/pd.pdf},
+}
+
+@techreport{Bachrach:1999,
+ author = {Bachrach, Jonathan and Playford, Keith},
+ title = {D-Expressions: Lisp Power, Dylan Style},
+ year = {1999},
+ source = {http://people.csail.mit.edu/jrb/Projects/dexprs.pdf},
+}
+
+@article{Gray:1998:MLM:274946.274957,
+ author = {Gray, David N. and Hotchkiss, John and LaForge, Seth and Shalit, Andrew and Weinberg, Toby},
+ title = {Modern languages and Microsoft's component object model},
+ journal = {Commun. ACM},
+ volume = {41},
+ issue = {5},
+ month = {May},
+ year = {1998},
+ issn = {0001-0782},
+ pages = {55--65},
+ numpages = {11},
+ url = {http://doi.acm.org/10.1145/274946.274957},
+ doi = {http://doi.acm.org/10.1145/274946.274957},
+ acmid = {274957},
+ publisher = {ACM},
+ address = {New York, NY, USA},
+}
+
+@article{Barrett:1996:MSL:236338.236343,
+ author = {Barrett, Kim and Cassels, Bob and Haahr, Paul and Moon, David A. and Playford, Keith and Withington, P. Tucker},
+ title = {A monotonic superclass linearization for Dylan},
+ journal = {SIGPLAN Not.},
+ volume = {31},
+ issue = {10},
+ month = {October},
+ year = {1996},
+ issn = {0362-1340},
+ pages = {69--82},
+ numpages = {14},
+ url = {http://doi.acm.org/10.1145/236338.236343},
+ doi = {http://doi.acm.org/10.1145/236338.236343},
+ acmid = {236343},
+ publisher = {ACM},
+ address = {New York, NY, USA},
+}
+
+@inproceedings{Barrett:1996:MSL:236337.236343,
+ author = {Barrett, Kim and Cassels, Bob and Haahr, Paul and Moon, David A. and Playford, Keith and Withington, P. Tucker},
+ title = {A monotonic superclass linearization for Dylan},
+ booktitle = {Proceedings of the 11th ACM SIGPLAN conference on Object-oriented programming, systems, languages, and applications},
+ series = {OOPSLA '96},
+ year = {1996},
+ isbn = {0-89791-788-X},
+ location = {San Jose, California, United States},
+ pages = {69--82},
+ numpages = {14},
+ url = {http://doi.acm.org/10.1145/236337.236343},
+ doi = {http://doi.acm.org/10.1145/236337.236343},
+ acmid = {236343},
+ publisher = {ACM},
+ address = {New York, NY, USA},
+}
+
+@article{Dumas:1995:DWP:203241.203253,
+ author = {Dumas, Joseph and Parsons, Paige},
+ title = {Discovering the way programmers think about new programming environments},
+ journal = {Commun. ACM},
+ volume = {38},
+ issue = {6},
+ month = {June},
+ year = {1995},
+ issn = {0001-0782},
+ pages = {45--56},
+ numpages = {12},
+ url = {http://doi.acm.org/10.1145/203241.203253},
+ doi = {http://doi.acm.org/10.1145/203241.203253},
+ acmid = {203253},
+ publisher = {ACM},
+ address = {New York, NY, USA},
+}
\ No newline at end of file
diff --git a/documentation/website/source/_static/dylanwwdc94brochure.pdf b/documentation/website/source/_static/dylanwwdc94brochure.pdf
new file mode 100644
index 0000000000..e6dbb66923
Binary files /dev/null and b/documentation/website/source/_static/dylanwwdc94brochure.pdf differ
diff --git a/documentation/website/source/_static/favicon.ico b/documentation/website/source/_static/favicon.ico
new file mode 100644
index 0000000000..47b927bb64
Binary files /dev/null and b/documentation/website/source/_static/favicon.ico differ
diff --git a/documentation/website/source/_static/feed-icon-14x14.png b/documentation/website/source/_static/feed-icon-14x14.png
new file mode 100644
index 0000000000..b3c949d224
Binary files /dev/null and b/documentation/website/source/_static/feed-icon-14x14.png differ
diff --git a/documentation/website/source/_static/images/opendylan-dark.png b/documentation/website/source/_static/images/opendylan-dark.png
new file mode 100644
index 0000000000..ca1ec272d9
Binary files /dev/null and b/documentation/website/source/_static/images/opendylan-dark.png differ
diff --git a/documentation/website/source/_static/images/opendylan-light.png b/documentation/website/source/_static/images/opendylan-light.png
new file mode 100644
index 0000000000..c19a9114c3
Binary files /dev/null and b/documentation/website/source/_static/images/opendylan-light.png differ
diff --git a/documentation/website/source/_static/images/sk8.jpg b/documentation/website/source/_static/images/sk8.jpg
new file mode 100644
index 0000000000..dd188fe1e8
Binary files /dev/null and b/documentation/website/source/_static/images/sk8.jpg differ
diff --git a/documentation/website/source/_templates/placeholder.txt b/documentation/website/source/_templates/placeholder.txt
new file mode 100644
index 0000000000..e69de29bb2
diff --git a/documentation/website/source/_themes/opendylan/layout.html b/documentation/website/source/_themes/opendylan/layout.html
new file mode 100644
index 0000000000..cc4f3a5941
--- /dev/null
+++ b/documentation/website/source/_themes/opendylan/layout.html
@@ -0,0 +1,245 @@
+{#
+    opendylan/layout.html
+    ~~~~~~~~~~~~~~~~~
+
+    :copyright: Copyright 2020 by the Dylan Hackers.
+    :license: MIT.
+#}
+<!DOCTYPE html>
+{%- set render_sidebar = (not embedded) and (not theme_nosidebar|tobool) and
+                         (sidebars != []) %}
+{# URL root should never be #, then all links are fragments #}
+{%- if not embedded and docstitle %}
+  {%- set titlesuffix = " &#8212; "|safe + docstitle|e %}
+{%- else %}
+  {%- set titlesuffix = "" %}
+{%- endif %}
+
+{%- macro sidebar() %}
+      {%- if render_sidebar %}
+      <div class="sphinxsidebar" role="navigation" aria-label="main navigation">
+        <div class="sphinxsidebarwrapper">
+          {%- block sidebarlogo %}
+          {%- if logo_url %}
+            <p class="logo"><a href="{{ pathto(root_doc)|e }}">
+              <img class="logo" src="{{ logo_url|e }}" alt="Logo"/>
+            </a></p>
+          {%- endif %}
+          {%- endblock %}
+          {%- if sidebars != None %}
+            {#- new style sidebar: explicitly include/exclude templates #}
+            {%- for sidebartemplate in sidebars %}
+            {%- include sidebartemplate %}
+            {%- endfor %}
+          {%- else %}
+            {#- old style sidebars: using blocks -- should be deprecated #}
+            {%- block sidebartoc %}
+            {%- include "localtoc.html" %}
+            {%- endblock %}
+            {%- block sidebarrel %}
+            {%- include "relations.html" %}
+            {%- endblock %}
+            {%- block sidebarsourcelink %}
+            {%- include "sourcelink.html" %}
+            {%- endblock %}
+            {%- if customsidebar %}
+            {%- include customsidebar %}
+            {%- endif %}
+            {%- block sidebarsearch %}
+            {%- include "searchbox.html" %}
+            {%- endblock %}
+          {%- endif %}
+        </div>
+        {%- block sidebarextra %}{%- endblock %}
+      </div>
+      {%- endif %}
+{%- endmacro %}
+
+{%- macro script() %}
+    {%- for js in script_files %}
+    {{ js_tag(js) }}
+    {%- endfor %}
+{%- endmacro %}
+
+{%- macro css() %}
+    {%- for css in css_files %}
+      {%- if css|attr("filename") %}
+    {{ css_tag(css) }}
+      {%- else %}
+    <link rel="stylesheet" href="{{ pathto(css, 1)|e }}" type="text/css" />
+      {%- endif %}
+    {%- endfor %}
+{%- endmacro %}
+
+{%- if html_tag %}
+{{ html_tag }}
+{%- else %}
+<html{% if not html5_doctype %} xmlns="http://www.w3.org/1999/xhtml"{% endif %}{% if language is not none %} lang="{{ language }}"{% endif %}>
+{%- endif %}
+  <head>
+    {%- if not html5_doctype and not skip_ua_compatible %}
+    <meta http-equiv="X-UA-Compatible" content="IE=Edge" />
+    {%- endif %}
+    {%- if use_meta_charset or html5_doctype %}
+    <meta charset="{{ encoding }}" />
+    {%- else %}
+    <meta http-equiv="Content-Type" content="text/html; charset={{ encoding }}" />
+    {%- endif %}
+    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
+    {{- metatags }}
+    {%- block htmltitle %}
+    <title>{% if title == "&lt;no title&gt;" %}Open Dylan{% else %}{{ title|striptags|e }}{% endif %}{{ titlesuffix }}</title>
+    {%- endblock %}
+    {%- block css %}
+    {{- css() }}
+    {%- endblock %}
+    {%- if not embedded %}
+    {%- block scripts %}
+    {{- script() }}
+    {%- endblock %}
+    {%- if pageurl %}
+    <link rel="canonical" href="{{ pageurl|e }}" />
+    {%- endif %}
+    {%- if use_opensearch %}
+    <link rel="search" type="application/opensearchdescription+xml"
+          title="{% trans docstitle=docstitle|e %}Search within {{ docstitle }}{% endtrans %}"
+          href="{{ pathto('_static/opensearch.xml', 1) }}"/>
+    {%- endif %}
+    {%- if favicon_url %}
+    <link rel="shortcut icon" href="{{ favicon_url|e }}"/>
+    {%- endif %}
+    {%- endif %}
+{%- block linktags %}
+    {%- if hasdoc('about') %}
+    <link rel="author" title="{{ _('About these documents') }}" href="{{ pathto('about') }}" />
+    {%- endif %}
+    {%- if hasdoc('genindex') %}
+    <link rel="index" title="{{ _('Index') }}" href="{{ pathto('genindex') }}" />
+    {%- endif %}
+    {%- if hasdoc('search') %}
+    <link rel="search" title="{{ _('Search') }}" href="{{ pathto('search') }}" />
+    {%- endif %}
+    {%- if hasdoc('copyright') %}
+    <link rel="copyright" title="{{ _('Copyright') }}" href="{{ pathto('copyright') }}" />
+    {%- endif %}
+    {%- if next %}
+    <link rel="next" title="{{ next.title|striptags|e }}" href="{{ next.link|e }}" />
+    {%- endif %}
+    {%- if prev %}
+    <link rel="prev" title="{{ prev.title|striptags|e }}" href="{{ prev.link|e }}" />
+    {%- endif %}
+{%- endblock %}
+
+{% block extrahead %}
+    <script src="https://cdn.jsdelivr.net/npm/bootstrap@5.0.2/dist/js/bootstrap.min.js"
+            integrity="sha384-cVKIPhGWiC2Al4u+LWgxfKTRIcfu0JTxR+EQDz/bgldoEyl4H0zUF0QKbrJ0EcQF"
+            crossorigin="anonymous"></script>
+    <link href="https://cdn.jsdelivr.net/npm/bootstrap@5.0.2/dist/css/bootstrap.min.css"
+          rel="stylesheet"
+          integrity="sha384-EVSTQN3/azprG1Anm3QDgpJLIm9Nao0Yz1ztcQTwFspd3yD65VohhpuuCOmLASjC"
+          crossorigin="anonymous">
+    <meta name="viewport" content="width=device-width, initial-scale=1.0">
+    <link rel="alternate" type="application/rss+xml" title="Open Dylan" href="/rss.xml" />
+    <link rel="icon" href="/_static/favicon.ico" />
+    <svg xmlns="http://www.w3.org/2000/svg" style="display: none;">
+      <symbol id="chevron-right" viewBox="0 0 16 16">
+        <path fill-rule="evenodd" d="M4.646 1.646a.5.5 0 0 1 .708 0l6 6a.5.5 0 0 1 0 .708l-6 6a.5.5 0 0 1-.708-.708L10.293 8 4.646 2.354a.5.5 0 0 1 0-.708z"/>
+      </symbol>
+    </svg>
+{% endblock %}
+
+  </head>
+  {%- block body_tag %}<body>{% endblock %}
+
+{% block header %}
+
+    {% set navigation_bar = [
+        ('download/index', 'Install'),
+        ('documentation/index', 'Documentation'),
+        ('community/index', 'Participate'),
+        ('https://play.opendylan.org', 'Playground'),
+        ('history/index', 'History'),
+    ] -%}
+    {% set active_page = pagename|default('index') -%}
+
+    {# See examples at https://getbootstrap.com/docs/5.0/components/navbar/ #}
+    <nav class="navbar fixed-top navbar-expand-lg navbar-dark bg-dark">
+      <div class="container-fluid">
+        <img class="logo" src="{{ pathto('_static/opendylan.org/images/dylan-squares.png', 1) }}" alt="Dylan Logo" />
+        <a class="navbar-brand" href="{{ pathto('index') }}"> Open Dylan</a>
+        <button class="navbar-toggler" type="button" data-bs-toggle="collapse" data-bs-target="#navbarSupportedContent"
+                aria-controls="navbarSupportedContent" aria-expanded="false" aria-label="Toggle navigation">
+          <span class="navbar-toggler-icon"></span>
+        </button>
+        <div class="collapse navbar-collapse" id="navbarSupportedContent">
+          <ul class="navbar-nav me-auto mb-2 mb-lg-0">
+            {% for page, caption in navigation_bar -%}
+              <li class="nav-item">
+                <a class="nav-link {% if page == active_page %} active {% endif %}"
+                   href="{% if page[:4] == 'http' %}{{page}}{% else %}{{ pathto(page) }}{% endif %}">{{ caption|e }}</a>
+              </li>
+            {% endfor -%}
+          </ul>
+        </div>
+      </div>
+    </nav>
+{% endblock %}
+
+{%- block content %}
+  {%- block sidebar1 %} {# possible location for sidebar #} {% endblock %}
+
+    <div class="document">
+  {%- block document %}
+      <div class="documentwrapper">
+      {%- if render_sidebar %}
+        <div class="bodywrapper">
+      {%- endif %}
+          <div class="body" role="main">
+            {% block body %} {% endblock %}
+            <div class="clearer"></div>
+          </div>
+      {%- if render_sidebar %}
+        </div>
+      {%- endif %}
+      </div>
+  {%- endblock %}
+
+  {%- block sidebar2 %}{{ sidebar() }}{% endblock %}
+      <div class="clearer"></div>
+    </div>
+{%- endblock %}
+
+{% block footer %}
+   {# TODO(cgay): why do we need all this extra garbage in the footer compared to the "basic" layout? #}
+   <footer class="navbar navbar-static-bottom">
+     <div class="navbar-inner">
+       <div class="container">
+        {%- if show_source and has_source and sourcename %}
+          <p class="pull-left navbar-text">
+          <a href="{{ pathto('_sources/' + sourcename, true)|e }}"
+             rel="nofollow">{{ _('Show Source') }}</a></p>
+        {%- endif %}
+        <p class="pull-right navbar-text">
+        {%- if show_copyright %}
+          {%- if hasdoc('copyright') %}
+            {% trans path=pathto('copyright'), copyright=copyright|e %}&copy; <a href="{{ path }}">Copyright</a> {{ copyright }}.{% endtrans %}
+          {%- else %}
+            {% trans copyright=copyright|e %}&copy; Copyright {{ copyright }}.{% endtrans %}
+          {%- endif %}
+        {%- endif %}
+        {%- if last_updated %}
+          {% trans last_updated=last_updated|e %}Last updated on {{ last_updated }}.{% endtrans %}
+        {%- endif %}
+        {%- if show_sphinx %}
+          {% trans sphinx_version=sphinx_version|e %}Created using <a href="http://sphinx-doc.org/">Sphinx</a> {{ sphinx_version }}.{% endtrans %}
+        {%- endif %}
+        </p>
+       </div>
+     </div>
+      <script type="text/javascript" src="http://www.google.com/cse/brand?form=cse-search-box&amp;lang=en"></script>
+
+   </footer>
+{% endblock %}
+
+  </body>
+</html>
diff --git a/documentation/website/source/_themes/opendylan/static/opendylan.org/css/opendylan.css b/documentation/website/source/_themes/opendylan/static/opendylan.org/css/opendylan.css
new file mode 100644
index 0000000000..caaddef479
--- /dev/null
+++ b/documentation/website/source/_themes/opendylan/static/opendylan.org/css/opendylan.css
@@ -0,0 +1,110 @@
+body {
+    /* Necessary to put content below fixed top navbar. */
+    padding-top: 40px;
+}
+/* Sphinx generates <li><p> for <ul> items. Default margin bottom for P is huge
+   so reduce it to 5px. */
+li > p {
+    margin-bottom: 5px;
+}
+.dylan-top-quote {
+    background-color: #e0e0ff;
+    border-radius: 5px;
+    font-size: large;
+    font-style: italic;
+    max-width: 600px;
+    padding: 20px 40px;
+}
+.navbar .logo {
+  float: left;
+  padding: 5px 5px;
+}
+footer.navbar {
+  margin-top: 20px;
+  margin-bottom: 0;
+}
+/* Reduce heading sizes and add a bit of blank space above. */
+.section h1 {
+    font-size: 31.5px;
+    margin-top: 0px;
+    padding-top: 30px;
+}
+.section h2 {
+    font-size: 24.5px;
+    margin-top: 0px;
+    padding-top: 30px;
+}
+.section h3 {
+    font-size: 17.5px;
+    margin-top: 0px;
+    padding-top: 30px;
+}
+.section h4 {
+    font-size: 14px;
+    margin-top: 0px;
+    padding-top: 30px;
+}
+.section h5 {
+    font-size: 12px;
+    margin-top: 0px;
+    padding-top: 30px;
+}
+/* Make the ugly headerlink invisible unless under the pointer. */
+a.headerlink {
+    opacity: 0;
+}
+a.headerlink:hover {
+    color: silver;
+    opacity: 1.0;
+}
+blockquote div p {
+  font-size: 14px;
+  line-height: 20px;
+  margin: 0 0 10px;
+}
+
+.button,a.button {
+    background-color: #006600;
+    /* border-radius: 5px; */
+    border: none;
+    cursor: pointer;
+    display: inline-block;
+    font-size: 18px;
+    color: white;
+    margin: 4px 2px;
+    padding: 15px 32px;
+    text-align: center;
+    text-decoration: none;
+}
+
+.bi {
+  vertical-align: -.125em;
+  pointer-events: none;
+  fill: currentColor;
+}
+
+/* Responsive Docs
+-------------------------------------------------- */
+@media (max-width: 480px) {
+  /* Reduce padding above body */
+  body {
+    padding-top: 30px;
+  }
+}
+
+@media (max-width: 768px) {
+  /* Remove any padding from the body */
+  body {
+    padding-top: 0;
+  }
+  .bs-docs-sidebar .affix {
+    position: relative;
+  }
+}
+
+@media (min-width: 768px) and (max-width: 980px) {
+  /* Remove any padding from the body */
+  body {
+    padding-top: 0;
+  }
+}
diff --git a/documentation/website/source/_themes/opendylan/static/opendylan.org/images/dylan-squares.png b/documentation/website/source/_themes/opendylan/static/opendylan.org/images/dylan-squares.png
new file mode 100644
index 0000000000..ad0e5fc5df
Binary files /dev/null and b/documentation/website/source/_themes/opendylan/static/opendylan.org/images/dylan-squares.png differ
diff --git a/documentation/website/source/_themes/opendylan/static/opendylan.org/js/html5shim/html5.js b/documentation/website/source/_themes/opendylan/static/opendylan.org/js/html5shim/html5.js
new file mode 100644
index 0000000000..cbb52a0dee
--- /dev/null
+++ b/documentation/website/source/_themes/opendylan/static/opendylan.org/js/html5shim/html5.js
@@ -0,0 +1,4 @@
+// iepp v2.1pre @jon_neal & @aFarkas github.com/aFarkas/iepp
+// html5shiv @rem remysharp.com/html5-enabling-script
+// Dual licensed under the MIT or GPL Version 2 licenses
+/*@cc_on(function(a,b){function r(a){var b=-1;while(++b<f)a.createElement(e[b])}if(!window.attachEvent||!b.createStyleSheet||!function(){var a=document.createElement("div");return a.innerHTML="<elem></elem>",a.childNodes.length!==1}())return;a.iepp=a.iepp||{};var c=a.iepp,d=c.html5elements||"abbr|article|aside|audio|bdi|canvas|data|datalist|details|figcaption|figure|footer|header|hgroup|mark|meter|nav|output|progress|section|subline|summary|time|video",e=d.split("|"),f=e.length,g=new RegExp("(^|\\s)("+d+")","gi"),h=new RegExp("<(/*)("+d+")","gi"),i=/^\s*[\{\}]\s*$/,j=new RegExp("(^|[^\\n]*?\\s)("+d+")([^\\n]*)({[\\n\\w\\W]*?})","gi"),k=b.createDocumentFragment(),l=b.documentElement,m=b.getElementsByTagName("script")[0].parentNode,n=b.createElement("body"),o=b.createElement("style"),p=/print|all/,q;c.getCSS=function(a,b){try{if(a+""===undefined)return""}catch(d){return""}var e=-1,f=a.length,g,h=[];while(++e<f){g=a[e];if(g.disabled)continue;b=g.media||b,p.test(b)&&h.push(c.getCSS(g.imports,b),g.cssText),b="all"}return h.join("")},c.parseCSS=function(a){var b=[],c;while((c=j.exec(a))!=null)b.push(((i.exec(c[1])?"\n":c[1])+c[2]+c[3]).replace(g,"$1.iepp-$2")+c[4]);return b.join("\n")},c.writeHTML=function(){var a=-1;q=q||b.body;while(++a<f){var c=b.getElementsByTagName(e[a]),d=c.length,g=-1;while(++g<d)c[g].className.indexOf("iepp-")<0&&(c[g].className+=" iepp-"+e[a])}k.appendChild(q),l.appendChild(n),n.className=q.className,n.id=q.id,n.innerHTML=q.innerHTML.replace(h,"<$1font")},c._beforePrint=function(){if(c.disablePP)return;o.styleSheet.cssText=c.parseCSS(c.getCSS(b.styleSheets,"all")),c.writeHTML()},c.restoreHTML=function(){if(c.disablePP)return;n.swapNode(q)},c._afterPrint=function(){c.restoreHTML(),o.styleSheet.cssText=""},r(b),r(k);if(c.disablePP)return;m.insertBefore(o,m.firstChild),o.media="print",o.className="iepp-printshim",a.attachEvent("onbeforeprint",c._beforePrint),a.attachEvent("onafterprint",c._afterPrint)})(this,document)@*/
\ No newline at end of file
diff --git a/documentation/website/source/_themes/opendylan/theme.conf b/documentation/website/source/_themes/opendylan/theme.conf
new file mode 100644
index 0000000000..04d520905e
--- /dev/null
+++ b/documentation/website/source/_themes/opendylan/theme.conf
@@ -0,0 +1,3 @@
+[theme]
+inherit = agogo
+stylesheet = opendylan.org/css/opendylan.css
\ No newline at end of file
diff --git a/documentation/website/source/about/examples/classes.rst b/documentation/website/source/about/examples/classes.rst
new file mode 100644
index 0000000000..f56436fa10
--- /dev/null
+++ b/documentation/website/source/about/examples/classes.rst
@@ -0,0 +1,35 @@
+***********************
+Classes & Instantiation
+***********************
+
+Dylan makes it easy to define classes. You don't normally need to
+write constructors or accessor functions, which saves a lot of boring
+typing. You can initialize slots (a.k.a. "fields", "member variables",
+etc.) by providing a default value or expression in the slot spec and
+the caller may override the value using keyword arguments.  A small
+percentage of classes still need "constructors", which can be defined
+by overriding :drm:`initialize`.
+
+.. code-block:: dylan
+
+    define class <car> (<object>)
+      slot serial-number :: <integer> = unique-serial-number();
+      slot model-name :: <string>,
+	required-init-keyword: model:;
+      slot has-sunroof? :: <boolean>,
+	init-keyword: sunroof?:,
+	init-value: #f;
+    end class <car>;
+
+    define variable *unique-serial-number* = 0;
+
+    define function unique-serial-number() => (usn :: <integer>)
+      let serial = *unique-serial-number*;
+      *unique-serial-number* := *unique-serial-number* + 1;
+      serial;
+    end function;
+
+    define constant $blue-car = make(<car>, model: "Viper");
+    define constant $black-car = make(<car>, model: "Town Car", sunroof?: #t);
+    define constant $red-car = make(<car>, model: "F40", sunroof?: #f);
+
diff --git a/documentation/website/source/about/examples/everything_value.rst b/documentation/website/source/about/examples/everything_value.rst
new file mode 100644
index 0000000000..321ea9f741
--- /dev/null
+++ b/documentation/website/source/about/examples/everything_value.rst
@@ -0,0 +1,44 @@
+*********************
+Everything is a value
+*********************
+
+Every Dylan statement or expression returns a value.  Functions and control
+constructs like :drm:`select` and :drm:`for` return the values of the last
+expression in their body.
+
+:drm:`if` returns a value so it may be used in return position:
+
+.. code-block:: dylan
+
+    let abs = if (x >= 0) x else -x end;
+
+Dylan functions return the values of the last expression in their body to be
+evaluated.  This function returns either "foo" or "bar":
+
+.. code-block:: dylan
+
+    define function foobar ()
+      if (odd?(random(100)))
+        "foo"
+      else
+        "bar"
+      end
+    end;
+
+If there is no return value declaration for a function then any number of
+values of any type can be returned. Use ``=> (...decls...)`` to declare return
+values.  This function returns no values:
+
+.. code-block:: dylan
+
+    define function foo () => ()
+      format-out("foo");
+    end;
+
+This function returns an integer and a string:
+
+.. code-block:: dylan
+
+   define function bar () => (size :: <integer>, description :: <string>)
+     values(42, "the meaning of everything")
+   end;
diff --git a/documentation/website/source/about/examples/generic_functions.rst b/documentation/website/source/about/examples/generic_functions.rst
new file mode 100644
index 0000000000..a0d2fdd940
--- /dev/null
+++ b/documentation/website/source/about/examples/generic_functions.rst
@@ -0,0 +1,63 @@
+*****************
+Generic Functions
+*****************
+
+Methods in Dylan aren't tied directly to a particular class like they are in many other languages.
+Instead a method belongs to a generic function (GF).  Which method actually gets called is 
+decided by the types of all of the required arguments passed to the GF.  Consider the built-in
+:drm:`add` generic function:
+
+.. code-block:: dylan
+
+    define open generic add (seq :: <sequence>, new-element) => (new-seq :: <sequence>);
+
+This says that any method defined on :drm:`add` must accept two required arguments.
+The first argument must be a :drm:`<sequence>` and the second can be anything, since
+no type was declared for it.  The methods must return a single value which is a :drm:`<sequence>`.
+
+Also:
+
+#. The methods on this GF may not accept any optional (keyword)  arguments.
+#. The "open" adjective tells the compiler that other libraries may add methods to
+   this GF.
+
+If you try to define a method on ``add`` that breaks any of the above rules, you'll
+get a warning from the compiler.
+
+Note that the ``define generic`` form doesn't contain any actual code; it merely
+defines an API to which all other methods with the same name must conform.  We
+could define a very general method on :drm:`add` this way:
+
+.. code-block:: dylan
+
+    define method add (seq :: <sequence>,  new-element) => (new-seq :: <sequence>)
+      concatenate-as(type-for-copy(seq), list(new-element), seq)
+    end;
+
+Now, let's say you decide it would be good to have a method specifically for
+:drm:`<vector>` because you think it will be more efficient than the default implementation,
+even though the default will do the right thing.  You could write this:
+
+.. code-block:: dylan
+
+    define method add (v :: <vector>, new-element) => (new-v :: <vector>)
+      let new-vector = make(<vector>, size: v.size + 1);
+      map-into!(new-vector, identity, v);
+      new-vector[v.size] := new-element;
+      new-vector
+    end;
+
+(*Note that the above is just an example and isn't intended to be super-efficient.*)
+
+Now, if you use ``add(#[1, 2, 3], 4)`` the method for :drm:`<vector>` will be
+called because the first argument is a :drm:`<vector>`, and if you use
+``add(#(1, 2, 3), 4)`` then the first method will be called because the first
+argument is a :drm:`<list>`, which is a :drm:`<sequence>` but is not a
+:drm:`<vector>`.
+
+Very often, the compiler can figure out which method to call and so no run-time
+overhead for dispatch is incurred in those cases.  (The Open Dylan IDE has a
+tool to show whether method dispatch was optimized.)
+
+Note that the second method above has a more specific return type.  This
+can aid in compiler optimization also.
diff --git a/documentation/website/source/about/examples/getters_setters_functions.rst b/documentation/website/source/about/examples/getters_setters_functions.rst
new file mode 100644
index 0000000000..579a550cd6
--- /dev/null
+++ b/documentation/website/source/about/examples/getters_setters_functions.rst
@@ -0,0 +1,73 @@
+*******************************
+Getters & Setters are functions
+*******************************
+
+Many object-oriented languages force you to manually define ``get_foo`` and
+``set_foo`` functions for each class slot ``foo`` in order to control access to
+the slots and provide for future extensibility.  For example, ``set_foo``
+could be modified to keep a table of values of ``foo``.
+
+Dylan provides for this extensibility without having to write the
+accessor functions yourself. Consider a simple Dylan class:
+
+.. code-block:: dylan
+
+    define class <vehicle> (<object>)
+      slot driver, required-init-keyword: driver:;
+    end;
+
+This creates two functions, ``driver`` and ``driver-setter``.  You can prevent
+``driver-setter`` from being defined by adding the ``constant`` modifier to the slot declaration:
+
+.. code-block:: dylan
+
+   constant slot driver, required-init-keyword: driver:;
+
+Under normal circumstances, both the getter and setter function will be inlined
+and optimized into direct accesses.
+
+If you later discover that you can't allow direct access to the driver slot,
+you can rename the slot and create two explicit functions named ``driver`` and
+``driver-setter`` to replace it, thus changing the internal behavior without
+changing the API for your class. The following example maintains a hash table
+mapping drivers to their cars:
+
+.. code-block:: dylan
+
+    define constant *driver-to-car-map* = make(<table>);
+
+    define class <vehicle> (<object>)
+      // The leading '%' is a convention for naming internal slots.
+      slot %driver, required-init-keyword: driver:;
+    end;
+
+    define method initialize
+        (vehicle :: <vehicle>, #key, #all-keys)
+      *driver-to-car-map*[vehicle.%driver] := vehicle;
+    end;
+
+    // The name "driver" would be exported as the public API.
+    define constant driver = %driver;
+
+    define method driver-setter
+        (driver, vehicle :: <vehicle>) => (value :: <object>)
+      *driver-to-car-map*[driver] := vehicle;
+      vehicle.%driver := driver;
+    end;
+
+Note that Dylan provides some handy syntactic sugar to make slot accessor
+functions look like members of a C structure:
+
+.. code-block:: dylan
+
+    let car = make(<vehicle>, driver: "Frank");
+
+    // These two expressions are semantically identical and return the same value.
+    car.driver;
+    driver(car);
+
+    // These three statements perform the same assignment.
+    car.driver := "Sally";
+    driver(car) := "Sally";
+    driver-setter("Sally", car);
+
diff --git a/documentation/website/source/about/examples/hello_world.rst b/documentation/website/source/about/examples/hello_world.rst
new file mode 100644
index 0000000000..c166ee0143
--- /dev/null
+++ b/documentation/website/source/about/examples/hello_world.rst
@@ -0,0 +1,47 @@
+*************
+Hello, World!
+*************
+
+The canonical "Hello World" program in Dylan.
+
+**File library.dylan:**
+
+.. code-block:: dylan
+
+   Module: dylan-user
+
+   define library hello
+     use dylan;
+     use io, import: { format-out };
+   end;
+
+   define module hello
+     use dylan;
+     use format-out;
+   end;
+
+**File hello.dylan:**
+
+.. code-block:: dylan
+
+   Module: hello
+
+   format-out("Hello!\n");
+
+
+.. hint:: The `dylan new application </package/dylan-tool/index.html#dylan-new-application>`_
+          command will create these files for you, along with a test suite and
+          build files.
+
+How it works
+============
+
+* Every Dylan program defines a library and at least one module in that
+  library, and the simple Hello World program is no exception.
+
+* Every source file has a ``Module:`` header to say which module its
+  definitions should be in. The library and module themselves are defined in
+  the pre-existing ``dylan-user`` module.
+
+* The top level expressions in each source file are executed in order when the
+  library is loaded, so there's no need for a ``main`` function.
diff --git a/documentation/website/source/about/examples/keyword_arguments.rst b/documentation/website/source/about/examples/keyword_arguments.rst
new file mode 100644
index 0000000000..59093a0b82
--- /dev/null
+++ b/documentation/website/source/about/examples/keyword_arguments.rst
@@ -0,0 +1,45 @@
+*****************
+Keyword Arguments
+*****************
+
+Keyword arguments are optional arguments that are passed by name.
+
+Keyword arguments do not take part in method dispatch.  That is, they have no
+role in determining which method of a generic function is actually called.
+
+Keyword arguments in method definitions must match the rules spelled out in the
+generic function.
+
+Keyword arguments can be useful when you need to add occasionally-used
+parameters to existing functions, similar to the way you can use default
+parameter values in C++.
+
+.. code-block:: dylan
+
+  define function describe-list
+      (my-list :: <list>, #key verbose?) => ()
+    format-out("{a <list>, size: %d", my-list.size);
+    if (verbose?)
+      format-out(", elements:");
+      for (item in my-list)
+        format-out(" %=", item);
+      end for;
+    end if;
+    format-out("}");
+  end function;
+
+This function could be invoked in one of several ways. The first specifies no
+keyword arguments, and exhibits the default behavior:
+
+.. code-block:: dylan
+
+  describe-list(#(1, 2, 3))
+  // prints "{a <list>, size: 3}"
+
+Alternatively, the ``verbose?`` keyword argument could be used to indicate the
+verbose behavior was desired:
+
+.. code-block:: dylan
+
+  describe-list(#(5, 7, 3), verbose?: #t);
+  // prints "{a <list>, size: 3, elements: 5 7 3}"
diff --git a/documentation/website/source/about/examples/limited_types.rst b/documentation/website/source/about/examples/limited_types.rst
new file mode 100644
index 0000000000..7fdb828d18
--- /dev/null
+++ b/documentation/website/source/about/examples/limited_types.rst
@@ -0,0 +1,54 @@
+*************
+Limited Types
+*************
+
+Limited types provide a way to define new, restricted types based on
+existing types in a way that is different from subclassing.  For example,
+there is no built-in ``<byte>`` type, but it could be defined as follows:
+
+.. code-block:: dylan
+
+    define constant <byte> = limited(<integer>, min: 0, max: 255);
+
+Open Dylan can often provide improved error checking and
+optimizations for limited types.  For example, this code could
+generate a compile time error:
+
+.. code-block:: dylan
+
+    define function add1 (b :: <byte>) => (b2 :: <byte>) b + 1 end;
+    add1(255);
+
+The set of limited types that are supported depends on the compiler.
+
+Collection classes can be limited to containing a specific type of
+element:
+
+.. code-block:: dylan
+
+    define constant <int-vector> = limited(<vector>, of: <integer>);
+
+Open Dylan will optimize accesses into an ``<int-vector>`` defined
+as above.
+
+Open Dylan can avoid doing bounds checking or
+type checking, and can use an efficient representation of the
+vectors of floating point numbers for this code:
+
+.. code-block:: dylan
+
+    define constant $audio-buffer-size = 2048;
+    define constant <audio-buffer> =
+      limited(<vector>,
+	      of: <single-float>,
+	      size: $audio-buffer-size);
+
+    define function mix-buffers
+	(input1 :: <audio-buffer>, input2 :: <audio-buffer>,
+	 output :: <audio-buffer>)
+     => ()
+      for (i from 0 below $audio-buffer-size)
+	output[i] = 0.5 * input1[i] + 0.5 * input2[i];
+      end;
+    end;
+
diff --git a/documentation/website/source/about/examples/macros.rst b/documentation/website/source/about/examples/macros.rst
new file mode 100644
index 0000000000..6d3723ce3f
--- /dev/null
+++ b/documentation/website/source/about/examples/macros.rst
@@ -0,0 +1,47 @@
+******
+Macros
+******
+
+Dylan macros allow you to create new control constructs and other high-level
+forms. They can be used to automatically release resources, simplify class
+creation, or adapt Dylan for a specific problem domain.
+
+Let's say you find this code a little too verbose:
+
+.. code-block:: dylan
+
+  if (test())
+    f1(many, arguments, here)
+  else
+    long-function-name(and, more, args)
+  end
+
+and you'd rather be able to write it this way:
+
+.. code-block:: dylan
+
+  iff(test(),
+      f1(many, arguments, here),
+      long-function-name(and, more, args))
+
+You can't just define ``iff`` as a function because then the calls to both
+``f1`` and ``long-function-name`` will be evaluated.  Instead, you can write a
+macro:
+
+.. code-block:: dylan
+
+  define macro iff
+      { iff(?test:expression, ?true:expression, ?false:expression) }
+   => { if (?test) ?true else ?false end }
+  end;
+
+See also:
+
+* The `define table macro
+  <https://github.com/dylan-lang/opendylan/blob/master/sources/common-dylan/macros.dylan>`_
+  in common-dylan is a simple example of making a new top-level "define" form.
+* :drm:`Built-in macros <Built-In_Macros_and_Special_Definitions>` -- Many of
+  the basic features of Dylan are implemented as macros.
+* The `Dylan Macro System </articles/macro-system.html>`_ article by Dustin
+  Voss.
+* The :drm:`Macros` chapter in the :drm:`DRM <Index>`.
diff --git a/documentation/website/source/about/examples/multiple_return_values.rst b/documentation/website/source/about/examples/multiple_return_values.rst
new file mode 100644
index 0000000000..06b1a4272d
--- /dev/null
+++ b/documentation/website/source/about/examples/multiple_return_values.rst
@@ -0,0 +1,73 @@
+**********************
+Multiple Return Values
+**********************
+
+Any Dylan expression may return multiple values and those values can
+be captured by :drm:`let`.  Using :drm:`round` as an example:
+
+.. code-block:: dylan
+
+  let (integer, remainder) = round(3.2);
+
+Here ``integer`` is bound to the value ``3`` and ``remainder`` is bound to the
+value ``0.2``.
+
+----
+
+Any function may return multiple values by calling the :drm:`values`
+function in return position:
+
+.. code-block:: dylan
+
+  define function parse-integer
+      (input :: <string>) => (integer :: <integer>, end-pos :: <integer>)
+    let integer = 0;
+    let pos = 0;
+    ...code that sets pos and integer...
+    values(integer, pos)
+  end;
+
+Call it like this:
+
+.. code-block:: dylan
+
+  let (int, epos) = parse-integer("123 blah");
+
+or like this if you don't need the second value:
+
+.. code-block:: dylan
+
+  let int = parse-integer("123 blah");
+
+----
+
+Sometimes you may have a :drm:`<sequence>` of known values and want to
+bind them to variables temporarily:
+
+.. code-block:: dylan
+
+  let point = #(100, 200, 300);
+  let (x, y, z) = apply(values, point);
+
+----
+
+You may bind multiple trailing values to a single variable by using :drm:`#rest
+<Parameter_Lists>`.  In the following example ``more`` will be bound to ``#(3,
+4, 5)``.
+
+.. code-block:: dylan
+
+  let (first, second, #rest more) = values(1, 2, 3, 4, 5);
+
+----
+
+Extra values are ignored and missing values are bound to :drm:`#f`:
+
+.. code-block:: dylan
+
+  let (x, y) = values(1, 2, 3);
+  // x = 1, y = 2
+
+
+  let (x, y, z) = values(1, 2);
+  // x = 1, y = 2, z = #f
diff --git a/documentation/website/source/about/index.rst b/documentation/website/source/about/index.rst
new file mode 100644
index 0000000000..6047f9d934
--- /dev/null
+++ b/documentation/website/source/about/index.rst
@@ -0,0 +1,56 @@
+:hide-toc:
+
+*********************
+A Quick Tour of Dylan
+*********************
+
+Before starting the Tour, a few quick notes:
+
+1. You may find it useful to get a better feel for Dylan by pasting some of the
+   Tour examples into the Dylan Playground: https://play.opendylan.org (We hope
+   to integrate the playground directly into the Tour soon, to make this
+   easier.)
+
+2. A little more background on Dylan's history and goals may be helpful, in
+   which case keep reading below. Otherwise, feel free to go directly to
+   :doc:`examples/hello_world`.
+
+A bit more background on Dylan
+==============================
+
+Scheme and Common Lisp had a strong influence on Dylan. Like Scheme, Dylan is a "LISP-1",
+meaning it has a single namespace for variables and functions. Dylan's object system is
+derived from the Common Lisp Object System (CLOS), but simplified to allow for better
+compiler optimizations.
+
+In general, Dylan attempts to address potential performance issues by
+introducing "natural" limits to the full flexibility of Lisp systems, for
+example by allowing the compiler to clearly understand compilable units (i.e.,
+libraries).
+
+In Dylan, all values (numbers, functions, classes, types, etc.) are first-class
+objects. Dylan supports multiple inheritance, polymorphism, multiple dispatch,
+keyword arguments, object introspection, pattern-based syntax extension macros,
+and many other features.
+
+Dylan programs have fine-grained control over dynamism, for applications that occupy a
+continuum between dynamic and static programming and supporting evolutionary development
+(allowing for rapid prototyping followed by incremental refinement and optimization). The
+Open Dylan compiler provides both "production" and "rapid development" modes. In
+development mode many of the static restrictions are removed from the generated code, for
+increased flexibility.
+
+
+.. toctree::
+    :maxdepth: 1
+    :hidden:
+
+    examples/hello_world
+    examples/everything_value
+    examples/classes
+    examples/generic_functions
+    examples/getters_setters_functions
+    examples/keyword_arguments
+    examples/limited_types
+    examples/macros
+    examples/multiple_return_values
diff --git a/documentation/website/source/articles/beyond-java.rst b/documentation/website/source/articles/beyond-java.rst
new file mode 100644
index 0000000000..34bd43a7f2
--- /dev/null
+++ b/documentation/website/source/articles/beyond-java.rst
@@ -0,0 +1,1045 @@
+:orphan:
+
+************
+Beyond Java?
+************
+
+*Some experiences from building two CORBA IDL compilers.*
+
+by Dr Jason Trenouth
+
+(`Originally published <http://web.archive.org/web/20030409041302/http://fun-o.com/resources/beyond-java.phtml>`_ in 2001.)
+
+------
+
+The Java Age
+============
+
+We have been living through the Java age. It is somewhat of an understatement
+to say that there has been a great deal of interest in the `Java programming
+language
+<http://web.archive.org/web/20030409041302/http://java.sun.com/docs/books/jls/html/index.html>`_
+-- although as far as hype goes `XML
+<http://web.archive.org/web/20030409041302/http://www.xml.org/>`_ is now
+overshadowing it. Initially Java, outside `Sun Microsystems
+<http://web.archive.org/web/20030409041302/http://www.sun.com/>`_ at least, was
+seen as a programming language purely for the Internet. In particular, it came
+with a virtual machine that could be embedded in web browsers and a security
+model to control the activity of Java programs running in such browsers.
+
+These days, however, Java has moved on and developers are using the language
+for all sorts of applications. Java is perceived as a reasonable general
+purpose programming language -- one that is good enough. The tools are
+evolving. JIT compilers like `Sun's Hotspot
+<http://web.archive.org/web/20030409041302/http://www.javasoft.com/products/hotspot/>`_
+are making Java code run faster. UML-based design tools like `Rational Rose
+<http://web.archive.org/web/20030409041302/http://www.rational.com/products/rose/index.jtmpl>`_
+are finding Java's rigid syntax amenable to round-trip engineering. EJB-based
+Application Servers like `BEA's WebLogic
+<http://web.archive.org/web/20030409041302/http://www.bea.com/>`_ are providing
+the background of services needed for many kinds of business applications.
+
+So what's the problem?
+
+------
+
+The Problems
+============
+
+Java may not be up to the job. Linguistically it has a number of faults which
+all seem minor on their own but that add up to awkward and hard to maintain
+code. Some of these faults are born out of engineering compromises and some of
+them are deliberately chosen to reduce the perceived complexity of the
+language. But, for whatever the reason they exist, they are a burden to
+developers and they will be a burden to maintainers. Here are some of the
+problems:
+
+* single implementation inheritance
+* single argument method dispatch
+* primitive types distinct from objects
+* casting required
+* no extensible syntax
+* poor iteration/collection integration
+
+------ 
+
+The Solutions
+=============
+
+The solution is to adopt a more advanced programming language instead of
+Java. This need not mean going back to C++. After all, Java's popularization of
+garbage collection and pointer-free programming has probably significantly
+advanced the cause of reliable software. This also does not mean stepping
+sideways to `C#
+<http://web.archive.org/web/20030409041302/http://msdn.microsoft.com/vstudio/nextgen/technology/csharpintro.asp>`_
+-- a similar language with many of the same problems.
+
+The alternative programming language that I'm proposing in this article is
+Dylan. Dylan already has solutions to the problems listed above for Java:
+
+* multiple implementation inheritance
+* multiple argument method dispatch
+* pure object types
+* no casting required
+* extensible syntax
+* good iteration/collection integration
+
+------
+
+An Example
+==========
+
+Since, according to `Samuel Johnson
+<http://web.archive.org/web/20030409041302/http://www.samueljohnson.com/>`_,
+"example is always more efficacious than precept", I will examine a real
+programming task that is made more awkward by Java and more elegant by Dylan.
+
+In the last few years I've personally been working on some `CORBA
+<http://web.archive.org/web/20030409041302/http://www.corba.org/>`_
+projects. In particular, I've written compilers in both Dylan and Java for
+CORBA's Interface Definition Language (IDL), so I feel able to show how a
+language like Dylan can simplify application development compared to Java. In
+the sections that follow I will use IDL compiler examples while looking at the
+points I listed above where I contend that Dylan is an improvement over Java.
+
+------
+
+Single Implementation Inheritance
+---------------------------------
+
+While Java supports multiple inheritance of interfaces, it only offers single
+inheritance of implementations. Partly, this is because single inheritance is
+easier to implement efficiently and partly this is because multiple inheritance
+is seen, philosophically, as unnecessary. The view is that, in nearly all
+cases, the goal of multiple inheritance is better achieved through composition
+of objects and merging of interfaces rather than the merging of objects.
+
+Let's look at this in reality. In any compiler it is usual to convert the
+textual form of the input language into an internal representation consisting
+of a graph of objects. This graph is sometimes called an abstract syntax tree
+or AST.
+
+The input language, CORBA's IDL, consists of the usual types of construct. Some
+elements of the language textually contain some other parts of the
+language. E.g. an IDL *module* can contain all the other kinds of
+construct including other modules. Suppose we want to model these IDL
+constructs in our internal representation. Let's assume a parser is supplying
+us with calls to allocate these objects. How should we implement them? Well,
+Java advocates would start by concentrating on the interfaces, because the
+implementation details don't matter. So let's look at two pairs of IDL
+constructs:
+
+* *interface* and *string* both define a type in IDL, members of which can be
+  passed to and returned from operations; and
+
+* *module* and *interface* both introduce new scope* for identifier names.
+
+We can define Java interfaces to model the IDL concepts of *type* and
+*scope*. We can subclass these interfaces individually to model *string* and
+*module*, and subclass them together to produce a model for an IDL
+*interface*. However, after you have defined the interfaces, you need to get
+down to the implementation. Whatever the interfaces, you still have to
+implement these objects and their associated operations.
+
+In this case, since the concepts are orthogonal, we would like to be able to
+reuse and so share the implementations, otherwise we are going to have
+maintenance headache. That is, we'd like the implementation of IDL's
+*interface* to share the implementation of both *type* and *scope*.
+
+Unfortunately, in Java, we cannot use inheritance to implement both these kinds
+of sharing. We will have to implement one kind of sharing through inheritance
+and one through composition (aka aggregation). As a colleague of mine put it,
+"if you want multiple inheritance then you have to get off at the next stop as
+the Java bus doesn't go there."
+
+This asymmetry is messy. Here is some putative Java code:
+
+.. code-block:: java
+
+   public interface AbstractIDLType
+   {
+     public TypeInfo getTypeInfo();
+   }
+
+   public interface AbstractIDLScope
+   {
+     public ScopeInfo getScopeInfo();
+   }
+
+   class IDLType implements AbstractIDLType
+   {
+     private TypeInfo _typeInfo;
+     public TypeInfo getTypeInfo()
+     {
+       return _typeInfo;
+     }
+   }
+
+   public class IDLModule implements AbstractIDLScope
+   {
+     private ScopeInfo _scopeInfo;
+     public ScopeInfo getScopeInfo()
+     {
+       return _scopeInfo;
+     }
+   }
+
+   public class IDLInterface extends IDLType implements AbstractIDLScope
+   {
+     private ScopeInfo _scopeInfo;
+     public ScopeInfo getScopeInfo()
+     {
+       return _scopeInfo;
+     }
+   }
+
+   public class IDLString extends IDLType
+   {
+   }
+
+
+Contrast this with the equivalent Dylan code which can use multiple
+implementation inheritance:
+
+.. code-block:: dylan
+
+   define abstract class <IDL-type> ( <object> )
+     slot get-type-info :: <type-info>;
+   end class;
+
+   define abstract class <IDL-scope> ( <object> )
+     slot get-scope-info :: <scope-info>;
+   end class;
+
+   define class <IDL-module> ( <IDL-scope> )
+   end class;
+
+   define class <IDL-interface> ( <IDL-type>, <IDL-scope> )
+   end class;
+
+   define class <IDL-string> ( <IDL-type> )
+   end class;
+
+
+The Dylan code is symmetrical whereas the same sharing in Java has to be
+asymmetrical with redundant code if you want to take advantage of inheritance
+where you can. This symmetry simplifies the code and so speeds initial
+development time and eases later maintenance.
+
+------
+
+Single Argument Method Dispatch
+-------------------------------
+
+Now lets look at another of Java's drawbacks: single argument dispatch. Now,
+many programmers many not even be aware of this limitation if they have only
+programmed in single-dispatch or message-passing OO languages. It can be a case
+of what you've never had you don't miss. However, you tend to miss multiple
+argument dispatch if you've ever had it taken away. Here is an example from our
+IDL compiler. When building the AST from the textual input there comes a point
+when the program has created the new node instance and needs to add it into the
+tree as a new child of the current parent. This is an ideal opportunity to
+check some constraints on what is and is not legal IDL. For example, the
+grammar can tell you that arguments are attached to operations, but not that
+*out* or *inout* arguments make no sense for *oneway* operations. The latter
+constraint is best dealt with during tree construction. So suppose we had a
+method for adding new nodes into the tree called ``addNode``. In Java the above
+constraint might be coded as follows:
+
+.. code-block:: java
+
+   class IDLOperation extends IDLObject
+   {
+     ...
+     void addNode ( IDLObject node ) throws IDLException
+     {
+       if ( node instanceof IDLArgument )
+       {
+         IDLArgument argument = ( IDLArgument )node;
+         int dir = argument.direction();
+         if ( flag() == ONEWAY && ( dir == OUT || dir == INOUT ) )
+         {
+           illegalOneWayOperation( this, argument );
+         }
+       }
+       super.addNode( node );
+     }
+   }
+
+
+Constrast this with the Dylan code which can dynamically dispatch
+on both arguments in the signature: 
+
+.. code-block:: dylan
+
+   define method add-node ( operation :: <IDL-operation>, argument :: <IDL-argument> )
+     let dir :: <integer> = direction( argument );
+     if ( flag( operation ) == ONEWAY && ( dir == OUT || dir == INOUT ) )
+       illegal-one-way-operation( operation, argument );
+     end if;
+     next-method();
+   end method;
+
+
+We don't have to complicate this Dylan method by making it deal with the case
+when the second argument is not of type ``<IDL-argument>`` because the
+language's dispatching mechanism takes care of that for us. And in the case
+when it is an instance of ``<IDL-argument>`` we don't have to do a cast in
+order to call methods on it.
+
+The situation gets more complicated when there are other classes you have to
+care about. IDL operations can raise exceptions, but that doesn't make sense
+for *oneway* operations.  Suppose that we want to protect against that. With
+Java we have to modify the existing definition:
+
+.. code-block:: java
+
+   class IDLOperation extends IDLObject
+   {
+     ...
+     void addNode ( IDLObject node ) throws IDLException
+     {
+       if ( node instanceof IDLArgument )
+       {
+         IDLArgument argument = ( IDLArgument ) node;
+         int dir = argument.direction();
+         if ( flag() == ONEWAY && ( dir == OUT || dir == INOUT ) )
+         {
+           illegalOneWayOperation( this, argument );
+         }
+       }
+       else if ( node instanceof IDLException )
+       {
+         IDLException _exception = ( IDLException ) node;
+         if ( flag() == oneway )
+         {
+           illegalOneWayException( this, _exception );
+         }
+       }
+       super.addNode( node );
+     }
+   }
+
+
+While Dylan lets us define a new modular method.
+
+.. code-block:: dylan
+
+   define method add-node ( operation :: <IDL-operation>, argument :: <IDL-exception> )
+     if ( flag( operation ) == ONEWAY )
+       illegal-one-way-operation( operation, argument );
+     end if;
+     next-method();
+   end method;
+
+
+Single Argument Method Dispatch (Part II : The Visitor Horror)
+--------------------------------------------------------------
+
+The situation gets even more complicated when you want to walk the nodes as
+part of backends that are responsible for emitting stubs and skeletons for all
+the supported languages in your CORBA framework. In Java, one way of doing this
+would be to add new code for each backend to each of the node classes. This is
+clearly the wrong thing since you have to repeatedly edit the same core files
+over and over. Not very modular.
+
+An alternative is the ``visitor`` design pattern. Suppose, as one of the
+backends, you want to just dump out a regurgitated form of the original IDL for
+debugging purposes. We can avoid having to modify the core files for each
+backend if we add a single mechanism that lets us visit each node with an
+object of the backend's choosing.
+
+E.g. in each node class file we would have the class implement the following
+method:
+
+.. code-block:: java
+
+   void accept (Visitor v) {
+     v.visit(this);
+   }
+
+This ``accept`` method switches the recipient of the message from the current
+object to the argument and passes the current object along as an argument. Its
+a kind of callback. The ``Visitor`` interface has to specify visitor methods
+for each node class:
+
+.. code-block:: java
+
+   interface Visitor
+   {
+     void visit ( IDLInterface node );
+     void visit ( IDLOperation node );
+     void visit ( IDLModule node );
+     // etc
+   }
+
+
+Then the backend must define a visitor object that can be passed to the accept
+methods and must define visitor methods that can be called depending on the
+acceptor's class:
+
+.. code-block:: java
+
+   class DumpVisitor implements Visitor
+   {
+     void visit ( IDLInterface node )
+     {
+       ...
+     }
+     void visit ( IDLOperation node )
+     {
+       ...
+     }
+     // etc
+   }
+
+
+So the backend calls into the tree representation as follows:
+
+.. code-block:: java
+
+     ...
+     node.accept( this );
+     ...
+
+
+This sends the visitor (the backend) to the node and lets Java dynamically
+dispatch to an ``accept`` method. The ``accept`` method, as we've seen above is
+just a trampoline that immediately calls back into the visitor:
+
+.. code-block:: java
+
+     ...
+     visitor.visit( this );
+     ...
+
+
+This might seem pointless, but because there is a different ``accept`` method
+for each node class a different visit method is statically selected on the
+backend. In a sense, we have converted a dynamic dispatch into a static one.
+
+Unfortunately, we have lost the inheritance we might have used had we put the
+code directly into the core node class files. The visit methods are separate
+methods. We can't use ``super.visit(node)`` in say the ``IDLInterface`` visit
+method to invoke the inherited visit method on say ``IDLScope``. Instead we
+have to explicitly recode the inheritance by hand:
+
+.. code-block:: java
+
+     void visit ( IDLInterface node )
+     {
+       visit( ( IDLScope ) node );
+         ...
+     }
+
+
+In a kind of Catch-22 situation Java programmers are forced to break modularity
+in order to avoid breaking modularity.
+
+In Dylan, which not only has multiple-argument dispatch, but also lets you
+define methods which dispatch on classes from other libraries (without having
+access to private state), the situation is more straightforward. The dump back
+end can simply define a method (let's also call it ``visit``) that dispatches
+on the IDL node classes:
+
+.. code-block:: dylan
+
+     define method visit ( backend :: <dump-backend>, node :: <IDL-interface> )
+       next-method();
+       ...
+     end method;
+
+
+And that's it. There is nothing more that is required. The Dylan ``visit``
+method can call ``next-method`` and invoke the inherited ``visit`` method on
+``<IDL-scope>`` without having to encode that directly into the method.
+
+Moreover the Dylan ``visit`` method can call ``visit`` directly on sub-objects
+without having to bounce there via the ``accept`` bottleneck. There are no
+``accept`` methods at all in the Dylan solution.
+
+In summary:
+
+* There is no need to define lots of identical ``accept`` methods. (In Java, we
+  might even have had to introduce another ``accept`` method per class to deal
+  with, say, value-returning visitors.)
+
+* There is no need to define a ``Visitor`` interface that redundantly knows all
+  the classes.
+
+* There is no need to give up inheritence and then try and hack it back in!
+
+------
+
+Primitive Types Distinct From Objects
+-------------------------------------
+
+Java has primitive types that lie outside its object system. This can make
+intuitively simple operations into complex nightmares.
+
+In an IDL compiler you have to process arithmetic expressions. Suppose that
+your front end has parsed them into nodes that contain the operations and
+operands. Let's consider just a node for a binary operation: one with two
+sub-nodes with values of their own that need to be combined. For simplicity,
+let's suppose that IDL allows only all-integer or all-float arithmetic so we
+only have to code those two cases. We can record all integers we parse as long
+values and all floating point values we parse as doubles. To distinguish
+between these types we either have two different primitive fields and a flag in
+each node or we can store different kinds of numeric objects: Longs or Doubles.
+
+Given these constraints, the Java code for evaluating addition and subtraction
+nodes might come out looking like the following.  Notice all the casting,
+primitive value accessing, object allocation, and repetition needed to do the
+actual arithmetic.
+
+.. code-block:: java
+
+   class IDLExpression
+   {
+     ...
+     Object evaluate () throws EvaluationError
+     {
+       Object lhs = leftSubExpression().evaluate();
+       Object rhs = rightSubExpression().evaluate();
+       char op = operation();
+       switch ( op )
+       {
+         case '+':
+           if ( lhs instanceof Long && rhs instanceof Long )
+           {
+             return new Long( ( ( Long ) lhs ).longValue +
+                              ( ( Long ) rhs ).longValue );
+           }
+           else if (lhs instanceof Double && rhs instanceof Double)
+           {
+             return new Double( ( ( Double ) lhs ).doubleValue +
+                                ( ( Double ) rhs ).doubleValue);
+           }
+           else
+           {
+             throw new EvaluationError( this );
+           }
+         case '-':
+           if ( lhs instanceof Long && rhs instanceof Long )
+           {
+             return new Long( ( ( Long ) lhs ).longValue -
+                              ( ( Long ) rhs ).longValue);
+           }
+           else if ( lhs instanceof Double && rhs instanceof Double )
+           {
+             return new Double( ( ( Double ) lhs ).doubleValue -
+                                ( ( Double ) rhs ).doubleValue);
+           }
+           else
+           {
+             throw new EvaluationError( this );
+           }
+         ...
+       }
+     }
+   }
+
+
+Now imagine all this ugly code replicated for more arithmetic operations. And
+more realistic constraints on the arithmetic types will make the bloating
+worse.
+
+Dylan does not have primitive types that are distinct from its object types so
+it can express the code above more succinctly while retaining arithmetic
+efficiency:
+
+.. code-block:: dylan
+
+   define method evaluate ( expr :: <IDL-expression> ) => ( value )
+     let lhs = evaluate( left-subexpression( expr ) );
+     let rhs = evaluate( right-subexpression( expr ) );
+     let op = operation( expr );
+     select ( op )
+       '+' =>
+         check-constraints( lhs, rhs );
+         lhs + rhs;
+       '-' =>
+         check-constraints( lhs, rhs );
+         lhs - rhs;
+       ...
+     end select;
+   end method;
+
+   define method check-constraints ( expr :: <IDL-expression>, lhs :: <integer>, rhs :: <integer>)
+   end method;
+
+   define method check-constraints ( expr :: <IDL-expression>, lhs :: <float>, rhs :: <float>)
+   end method;
+
+   define method check-constraints ( expr :: <IDL-expression>, lhs :: <object>, rhs :: <object>)
+     error( make( <evaluation-error>, expression: expr ) );
+   end method;
+
+
+In the Dylan version we only have to test that the arithmetic constraints of
+IDL are met, using multiple argument dispatch again, and then we can perform
+the operation quite naturally in a single intuitive line. By contrast the Java
+version must split up the cases into very long-winded, clumsy, and inefficient
+code.
+
+------
+
+Casting Required
+----------------
+
+In static languages casting seems to be a necessary evil. You have to tell the
+compiler things that it needs to know. In unsafe languages, if you break that
+promise, the computation can become corrupt and go awry. In a safe language
+like Java runtime checks prevent such unfriendly behaviour. But whatever safety
+net is provided for mistakes, cast-ridden code is harder to read and maintain.
+
+The arithmetic example from the section on "Primitive Types Distinct From
+Objects" has already introduced some of the ugliness of casting. The
+``evaluate`` method returns the result of an arithmetic (sub)expression. In
+both Dylan and in Java we don't know exactly what the resulting type is, but in
+Java we have to care because we need to extract a primitive value from that
+result and the primitive accessor we use depends on the type. So in Java we
+have to test and then cast the result to that type.
+
+When you have several layers of abstract protocol that have to work on many
+data types casting can become incredibly ugly. Here is some code that takes a
+name of a constant value that we know in a certain context is used to declare
+the size of an IDL array. Suppose that we want to access that size in Java:
+
+.. code-block:: java
+
+     ( ( Long ) 
+       ( ( IDLConstant )
+         node.resolveIdentifier( name )
+       ).expression().evaluate()
+     ).intValue()
+
+
+Now compare that with Dylan:
+
+.. code-block:: dylan
+
+     evaluate( expression( resolve-identifier( node, name ) ) )
+
+
+In Dylan we can assume that if there is a runtime type mismatch it will be
+detected and signaled for us. We don't have to put in explicit casts at the
+call site just to promise the compiler that we're allowed to call a method. The
+mere fact we are calling a method which expects that type is sufficient.
+
+Dylan does not force you to pay for what you don't use. Elsewhere in your code
+-- away from dynamic cases -- type declarations and domain sealing
+(constraining the extensibility of functions by argument type) can allow Dylan
+compilers to statically dispatch calls or warn of the lack of applicable
+methods.
+
+------
+
+No Extensible Syntax
+--------------------
+
+Java has no macros. After the C preprocessor this was seen as a step
+forward. The two main uses of C preprocessor in C and C++ programs has been for
+naming constants and conditionalizing code. In Java constants can be declared
+via *static final* fields and benefit from the automatic association with a
+class namespace. Conditionalizing code was typically done to enable source code
+to be ported across platforms and also in order to turn on and off debugging
+code. Java deals with cross-platform portability in other ways. For example
+integer types have known fixed sizes no matter what the platform. Finally, for
+debugging, Java compilers will optimize away unreachable code, so debugging
+code can be left in and turned off by manipulating an ordinary constant in one
+place in the code.
+
+However, constants and conditionalized debugging are not the only uses of
+macros. Macros can also be used for syntactic extension. Unfortunately, macros
+defined in the C preprocessor use textual substitution and so extending the
+syntax is hard to get right.
+
+In Dylan, macros are defined using a pattern and template filling notation that
+is smart about the syntax of the language. This lets programmers build
+abstractions, encapsulate details, and map external formats to internal ones
+which can be verified at compile time.
+
+As an example, let us consider the ``dump`` output of an IDL compiler
+again. When reproducing IDL code from the internal tree representation it is
+useful for the human reader if we indent the output. One way to do this would
+be to implement a so called "pretty printer" for the internal
+representation. This could take account of the page width and have heuristics
+for breaking lines and so on.
+
+A full-blown pretty printer is too much work for this IDL re-emitter which is
+really only for debugging purposes, although one could argue that a generalized
+component of this sort would come in handy in other situations.
+
+Instead we will take care of line breaks manually and we only need something to
+keep track of the indentation level. An natural abstraction is an extended I/O
+stream which inserts extra whitespace before each line that is printed, and
+that can be told to add more or less whitespace as the context demands. We will
+call this an "indenting stream" although it will also add braces around the
+nested IDL as well as indenting it.
+
+In Java we might use the indenting stream, wrapped up in some utility calls,
+for dumping out the IDL for an interface as follows:
+
+.. code-block:: java
+
+   void visit (IDLInterface node)
+   {
+     node.dumpName();
+     node.dumpInherits();
+     this.stream.start(); // write out a '{' and increase the indention
+     {
+       node.dumpBody()  
+     }
+     this.stream.finish(); // decrease the indentation and write out a '}'
+   }
+
+
+In the example we add extra indentation for the elements of inteface by calling
+a function ``start`` and we remove the extra indentation by calling
+``finish``. Also, we use a trick and introduce extra indentation into the
+source code by using a Java block. This lets us see the structure of the
+emitted code in the source code. Unfortunately, we have to remember to put the
+call to ``finish`` in ourselves and the Java compiler won't notice if we miss
+it out. There is also no real connection between the indenting in the output
+and the indenting in the source -- we just have to remember to put in the block
+braces.
+
+An alternative might be to use an extra instance (a ``Start`` !) of an
+anonymous inner class that takes care of the indentation by using a ``body``
+callback something like the following.
+
+.. code-block:: java
+
+   void visit (IDLInterface node)
+   {
+     node.dumpName();
+     node.dumpInherits();
+     new Start( this.stream )
+     {
+       public void body ()
+       {
+         node.dumpBody();
+       }
+     }
+     .finish();
+   }
+
+
+The ``finish`` method calls the ``body`` method wrapped with the other calls
+for indenting and exdenting the stream.
+
+However, the Java compiler will still not notice if we miss out the
+``.finish()``. Also this is beginning to look rather strange and potentially
+inefficient if we are creating lots of these "Starts" all over the place. More
+fatally, there is at least one popular Java compiler that cannot cope with more
+than two nested levels of the above construct.
+
+A more typical way of doing this Java would be to use a static method and an
+instance of an anonymous inner class:
+
+.. code-block:: java
+
+   void visit (IDLInterface node)
+   {
+     node.dumpName();
+     node.dumpInherits();
+     Body.with( new Body( this.stream )
+     {
+       public void invoke ()
+       {
+         node.dumpBody();
+       }
+     } );
+   }
+
+
+This at least lets us wrap up the call in a way that enables the Java compiler
+to spot missing delimiters, but we have to pay the cost of an object allocation
+each time.
+
+So what would you do in Dylan using macros? Well, the following
+demonstrates. First we define the macro:
+
+.. code-block:: dylan
+
+   define macro indenting
+     { indenting ( ?stream:expression ) ?body:body end }
+     =>
+     { begin
+         let stream = ?stream;
+         start( stream );
+         ?body;
+         finish( stream );
+       end }
+   end macro;
+
+
+This defines a macro called ``indenting`` which wraps up some code denoted by
+``?body`` with a couple of administrative calls to change the current stream's
+indentation and insert braces. The ``:body`` syntax is a constraint that says
+``?body`` must match a well-formed sequence of Dylan source code
+statements. Similarly, the ``:expression`` syntax is a constraint that says
+``?stream`` must match a well-formed Dylan expression.
+
+Now that we have the macro we can use it as follows:
+
+.. code-block:: dylan
+
+   define method visit ( backend :: <dump-backend>, node :: <IDL-interface> )
+     dump-name( node );
+     dump-inherits( node );
+     indenting ( stream( backend ) )
+       dump-body( node );
+     end;
+   end method;
+
+
+The macro expands into the administrative calls, but lets us see the indented
+source and lets the Dylan compiler check the balanced statements:
+``indenting...end``.
+
+Now suppose that there is a possibility that parts of the output may go awry or
+be terminated and yet we want the bulk of the printing to continue. In
+particular, we want to be able to reset the indentation back to the original
+level in the advent of a non-local exit.
+
+The original Java technique would mean having to insert a try-finally block in
+every use of the pattern:
+
+.. code-block:: java
+
+   void visit ( IDLInterface node )
+   {
+     node.dumpName();
+     node.dumpInherits();
+     try
+     {
+       this.stream.start(); // write out a '{' and increase the indention
+       node.dumpBody()  
+     }
+     finally
+     {
+       this.stream.finish(); // decrease the indentation and write out a '}'
+     }
+   }
+
+
+Now this is beginning to get out of hand. The usual Java technique of defining
+a static method that calls a protocol invoker on an instance of an anonymous
+inner class helps, but at the cost of clumsy boilerplate in the source and
+instance allocation for each call.
+
+In Dylan the solution is simply to extend the macro in one place:
+
+.. code-block:: dylan
+
+   define macro indenting
+     { indenting (?stream:expression) ?body:body end }
+     =>
+     { block
+         let stream = ?stream;
+         start( stream );
+         ?body;
+       cleanup
+         finish( stream );
+       end }
+   end macro;
+
+
+And all the uses of ``indenting ... end`` remain the same.
+
+------
+
+Poor Iteration/Collection Integration
+-------------------------------------
+
+Let's suppose we are implementing ``dumpInherits`` from the above emitter
+code. We need to iterate over the inherited interfaces and dump out their
+names. Suppose also that we want to maintain a degree of abstraction over how
+we implement the sequence of inherited interfaces.
+
+In Java, we might expose the interface to the sequence of inherited interfaces
+as a ``List`` so that we could implement it as a LinkedList or an ArrayList or
+something else depending on other constraints.
+
+Here is some possible code:
+
+.. code-block:: java
+
+   void dumpInherits ()
+   {
+     dumpColon();
+     Iterator it = getInherited().iterator();
+     while ( it.hasNext() )
+     {
+       ( ( IDLInterface )it.next() ).dumpName();
+       if ( it.hasNext() )
+         dumpComma();
+     }
+   }
+
+
+However, if we knew we had an ``ArrayList`` (which can be indexed in constant
+time) we could use an index rather than using an iterator (which is slightly
+more efficient):
+
+.. code-block:: java
+
+   void dumpInherits ()
+   {
+     dumpColon();
+     ArrayList inherited = getInherited();
+     int nInherited = inherited.size();
+     boolean isFirst = false;
+     for ( int i = 0; i < nInherited; i++ )
+     {
+       if ( isFirst ) isFirst = false; else dumpComma();
+
+       ( ( IDLInterface )inherited.get( i ) ).dumpName();
+     }
+   }
+
+
+And if we didn't need the power of the collection classes then we
+use a good old fashioned array.
+
+.. code-block:: java
+
+   void dumpInherits ()
+   {
+     dumpColon();
+     IDLInterface[] inherited = getInherited();
+     int nInherited = inherited.length;
+     boolean isFirst = false;
+     for ( int i = 0; i < nInherited; i++ )
+     {
+       if ( isFirst ) isFirst = false; else dumpComma();
+
+       inherited[ i ].dumpName();
+     }
+   }
+
+
+The situation in Dylan is different. The following code covers any collection
+class from the built-in ones like ``<vector>`` or ``<list>`` to custom ones
+that you've written for your application. Moreover you don't actually need to
+create an explicit iterator or index in order to loop over the elements of any
+collection as that is done for you behind the scenes.
+
+.. code-block:: dylan
+
+   define method dump-inherits ( interface :: <IDL-interface> )
+     dump-colon();
+     for ( inherits in get-inherited( interface ), first? = #t then #f )
+       if ( ~first? )
+         dump-comma();
+       end;
+       dump-name( inherits )
+     end;
+   end method;
+
+
+We could program explicitly using iterators in Dylan, just as in Java, but
+that's a bit of a drag when you have a ``for`` construct that can do the work
+for us automatically.
+
+In fact, using Dylan's macros we can even build an abstraction that lets us
+express the ``dump-inherits`` method even more clearly. First we put a line
+similar to the following one in the module definition.
+
+.. code-block:: dylan
+
+     import dylan, rename: { \for => \dylan/for }
+
+
+This rebinds the original Dylan ``for`` macro on import so that we can define a
+new one and have it expand into the original one.
+
+.. code-block:: dylan
+
+   define macro for
+     { for ( ?clauses:* )
+         ?body:body
+       between
+         ?between:body
+       end }
+      =>
+      { dylan/for ( ?clauses, first? = #t then #f )
+          if ( ~first? )
+            ?between
+          end;
+          ?body
+        end; }
+   end macro;
+
+
+This macro lets us express ``dump-inherits`` as follows:
+
+.. code-block:: dylan
+
+   define method dump-inherits ( interface :: <IDL-interface> )
+     dump-colon();
+     for ( inherits in get-inherited( interface ) )
+       dump-name( inherits )
+     between
+       dump-comma();
+     end;
+   end method;
+
+
+Actually, our ``for`` macro interferes with the facilities of the built-in
+Dylan ``for`` macro more than we might wish. The new macro has deliberately
+been kept simple for the purposes of the example, and the real situation would
+require more propagation of rare syntax from our macro to the the Dylan one.
+
+------
+
+Conclusion
+==========
+
+We've covered some of the awkwardnesses of Java with respect to Dylan, but what
+is the point? Java is clearly here to stay isn't it?  There's been too much
+investment in Java to stop now hasn't there? We don't need another new
+programming language do we?
+
+Well, in 1995 people thought that mainstream programming language development
+had peaked with the widespread use of C++. Of course there were detractors, but
+in the main C++ was seen as the de facto standard application development
+language. On the fringes Smalltalk was gaining currency (pun intended) in
+business application areas, and other languages had their established niches
+(e.g. Common Lisp for R&D).
+
+Since 1995 Java has swept aside C++ as the de facto standard programming
+language for mainstream applications. Even C shops that had not even moved to
+C++ have jumped on the Java bandwagon.
+
+But if you're building the future at the latest e-commerce ".com" you need a
+competitive advantage over the other energetic internet businesses. Games
+developers budget on throwing away their code base every two to three
+years. Internet time is bringing that time-frame to more mainstream
+development. You don't want to be held back by your tool, and if you are using
+the same mediocre tool as everyone else in the herd then you *are* being held
+back.
+
+Equivalently, if you are shoring up the present in a larger organisation then
+it is your duty to ensure that the systems you build are maintainable in the
+future. And you want *maintainable* to mean *really maintainable*. That means
+using a tool that lets you encode abstractions and model the domain in the
+program source, and not just hope that takes place in some surrounding cloud of
+documentation and diagrams.
+
+Ultimately, you have to ask yourself: is Java is really good enough
+for the 21st Century?
+
+------
+
+Acknowledgements
+================
+
+Thanks to Carl L. Gay, Hugh Greene, Scott McKay, and others associated
+with Functional Objects for feedback on drafts of this article.
+
+Copyright; 1999-2001 Functional Objects, Inc.
+All rights reserved.
+All product and brand names are the registered trademarks or trademarks of their respective owners.
diff --git a/documentation/website/source/articles/macro-system.rst b/documentation/website/source/articles/macro-system.rst
new file mode 100644
index 0000000000..7c88266cbb
--- /dev/null
+++ b/documentation/website/source/articles/macro-system.rst
@@ -0,0 +1,1567 @@
+:copyright: Copyright © 2011 Dustin Voss, All Rights Reserved.
+:orphan:
+
+.. sectionauthor:: Dustin Voss <d_j_v@me.com>
+.. default-role:: samp
+.. highlight:: dylan
+
+######################
+The Dylan Macro System
+######################
+
+Dylan macros simplify boilerplate code and provide syntactic shorthand. They are
+useful in small jobs within a particular file (e.g. making a series of
+repetitive declarations) and for larger jobs (e.g. constructing a GUI through
+creating and associating objects). Easy jobs are easy to do with macros, but the
+complicated jobs get hard fast.
+
+This document describes how the Dylan macro system works and some techniques you
+can use when writing your own macros. I gloss over some of the implementation
+details and present this information more informally than the :title:`Dylan
+Reference Manual` does.
+
+
+***********************
+Background and Overview
+***********************
+
+Macros work on the basis of code fragments. The macro system
+does not understand code fragments; it just substitutes some fragments for other
+fragments. Once the macro system has substituted and arranged all the code
+fragments, they are compiled into executable code.
+
+Because the macro system parses and generates code fragments, it can recognize
+the difference between a string containing a macro name and an actual invocation
+of a macro. Macros are not affected by such syntactical issues; strings and
+other expressions are treated as opaque units.
+
+The following are all examples of elementary code fragments, or `parsed
+fragments`. These combine to form the larger code fragments upon which macros
+operate.
+
+.. code-block:: none
+
+   'a'
+   "end times"
+   35.552
+   3/4
+   (3 + 7)
+   #t
+   #"red"
+   red:
+   cinnamon
+   ==
+   #[1, 2, 3]
+   as(...)
+   list.size
+
+
+Anatomy and terms
+=================
+
+Macros have `main rules` and `auxiliary rules`. Each of the main or auxiliary
+rules has a `pattern` and a `template`. Patterns are matched against the code
+fragments of your source code. A main rule is matched against the code fragment
+that comprises the entire macro call. An auxiliary rule is matched against parts
+of that code fragment. The matched code is then replaced by the template.
+
+A pattern can contain code fragments and `pattern variables`. If a code
+fragment in the source code matches what is in the pattern, parts of that code
+fragment may be pulled out into pattern variables. The rest is discarded.
+
+A template can contain other code fragments and `substitutions`. Substitutions
+are placeholders; the contents of a pattern variable are processed and inserted
+into the template in place of every corresponding substitution. The template's
+combined fragments and substitutions form the macro's `expansion`, which
+replaces the original code fragment.
+
+This happens recursively: after a macro is expanded, its expansion is scanned
+for additional macro call code fragments, and those are expanded in turn. The
+parser recognizes a macro call code fragment by way of a `distinguishing word`
+and the type of syntax associated with the macro (discussed further in
+`Macro Types`_).
+
+Let us examine this function macro:
+
+   .. code-block:: dylan
+      :linenos:
+
+      define macro table
+          { table(?table-class:expression, ?table-contents) }
+       => { let ht = make(?table-class); ?table-contents; ht }
+
+          { table(?rest:*) }
+       => { table(<table>, ?rest) }
+
+       table-contents:
+           { ?key:expression => ?value:expression, ... }
+        => { ht[?key] := ?value; ... }
+
+           { }
+        => { }
+      end macro table
+
+Here are the parts of the macro:
+
+- The distinguishing word is `table`. Whenever the compiler sees `table(...)`,
+  it will expand this macro rather than creating a call to a function named
+  "table".
+- The main rules are in lines 2–6.
+- The macro has one set of auxiliary rules in lines 8-13. A set of auxiliary
+  rules has a title written as a symbol. This set of auxiliary rules is titled
+  `table-contents:`.
+- The pattern of the first main rule is in line 2.
+- The template of the first main rule is in line 3.
+- The patterns in this macro include the pattern variables `?table-class`,
+  `?table-contents`, `?rest`, `?key`, and `?value`.
+- The substitutions in this macro include those same names.
+
+This macro might be called as follows:
+
+   .. code-block:: dylan
+
+      let lights = table(<string-table>, "red" => "stop", "green" => "go");
+
+But this actual call fragment is what the parser will attempt to match:
+
+   .. code-block:: dylan
+
+      table(<string-table>, "red" => "stop", "green" => "go")
+
+The macro's expansion will be
+
+   .. code-block:: dylan
+
+      let ht = make(<string-table>);
+      ht["red"] := "stop";
+      ht["green"] := "go";
+      ht
+
+and the replacement code will then become
+
+   .. code-block:: dylan
+
+      let lights = begin
+        let ht = make(<string-table>);
+        ht["red"] := "stop";
+        ht["green"] := "go";
+        ht
+      end;
+
+Note that the expansion is surrounded by `begin` and `end`. Macro expansions
+are always surrounded by a begin...end block. This helps with macro hygiene (i.e.
+preventing bindings outside of a macro call from being affected by bindings used
+in a macro's expansion). See `Hygiene`_.
+
+
+***********
+Macro Types
+***********
+
+There are four types of macro.
+
+`Body-style definition macro`:dfn:
+      This kind of macro lets you create `define x ... end` syntax. This is the
+      most popular kind of macro. Example: `define function`
+      (see `DEP-002 <https://opendylan.org/proposals/dep-0002-define-function.html>`_).
+
+`List-style definition macro`:dfn:
+      This kind of macro lets you create `define x ...` syntax, such as `define
+      variable $pi`.
+
+`Statement macro`:dfn:
+      This kind of macro lets you create `do-something ... end` syntax. Use this
+      kind of syntax to simplify blocks or to create new kinds of loops. It is
+      most commonly used to simplify resource management. Examples include
+      :drm:`block`, :drm:`for`, and `with-open-file`.
+
+`Function macro`:dfn:
+      This kind of macro lets you create `x(...)` syntax. Use this instead of a
+      function call if the syntax you want in the parentheses is more
+      complicated than a normal function call, or if there is additional setup
+      needed around a normal function call.
+
+
+Macro definitions
+=================
+
+All macros are defined by the :drm:`define macro` macro, which follows this general
+syntax, with optional parts in brackets::
+
+      define macro MACRO-NAME
+         MAIN-RULE-SET
+         [AUXILIARY-RULE-SETS]
+      end macro MACRO-NAME
+
+`{MACRO-NAME}`
+      For statement and function macros, this is the macro's distinguishing
+      word. For body-style and list-style definition macros, though, it is the
+      distinguishing word plus `-definer`.
+
+`{MAIN-RULE-SET}`
+      One or more pattern/template pairs. The syntax that the patterns all
+      follow determine the type of the macro, and are described :ref:`below
+      <main-rules>`. The patterns are matched in order; see `Patterns`_.
+
+`{AUXILIARY-RULE-SETS}`
+      One or more auxiliary rule sets, described in more detail in
+      `Auxiliary Rules`_. Each rule set has a name (which is syntactically a
+      symbol) and one or more pattern/template pairs. The name may be written as
+      `my-aux-ruleset:` or `#"my-aux-ruleset"`; both are the same.
+
+
+.. _main-rules:
+
+Main Rules
+==========
+
+The pattern of each main rule of a macro (and thus the way the macro is called)
+must follow a specific syntactic style depending on the type of macro.
+
+When the Dylan compiler sees a macro call, it first finds the end of the call,
+and only afterwards attempts to expand the macro. While looking for the end of
+the call, the compiler recognizes inner macro calls along the way and
+recursively looks for the end of them first. If a code fragment *looks* like
+the end of a macro call, the parser will assume that that code fragment *is*
+the end of the macro call. Below, I describe what the end of each type of macro
+call *looks* like.
+
+
+Body-style definition macro
+---------------------------
+
+The main rules' patterns must follow this syntax, with optional parts in
+brackets::
+
+      { define [MODIFIERS] DISTINGUISHING-WORD [NAME]
+          [BODY-PATTERNS] [;]
+        end }
+
+`{MODIFIERS}`
+      One or more words or pattern variables.
+
+`{NAME}`
+      A name or a pattern variable with a name constraint.
+
+`{BODY-PATTERNS}`
+      One or more sets of code fragments and pattern variables separated by
+      semicolons and/or commas.
+
+The parser will end the macro call at the first matching `end`. The final `end`
+in each main rule is the only `end` that the macro's patterns can have.
+
+As a special case, the final `end` matches these code fragments::
+
+      end
+      end DISTINGUISHING-WORD
+      end DISTINGUISHING-WORD NAME
+
+
+List-style definition macro
+---------------------------
+
+The main rules' patterns must follow this syntax, with optional parts in
+brackets::
+
+      { define [MODIFIERS] DISTINGUISHING-WORD [LIST-PATTERNS] }
+
+`{MODIFIERS}`
+      One or more words or pattern variables.
+
+`{LIST-PATTERNS}`
+      One or more sets of code fragments and pattern variables separated by
+      commas.
+
+The parser will end the macro call at the first matching `;` or the end of the
+enclosing source code. None of the macro's patterns can have a semicolon, and it
+is probably better to avoid `?:body` or `?:case-body` pattern variables.
+
+
+Statement macro
+---------------
+
+The main rules' patterns must follow this syntax, with optional parts in
+brackets::
+
+      { DISTINGUISHING-WORD [BODY-PATTERNS] [;] end }
+
+`{BODY-PATTERNS}`
+      One or more sets of code fragments and pattern variables separated by
+      semicolons and/or commas.
+
+The parser will end the macro call at the first matching `end`. The final `end`
+in each main rule is the only `end` that the macro's patterns can have.
+
+As a special case, the final `end` matches these code fragments::
+
+      end
+      end DISTINGUISHING-WORD
+
+
+Function macro
+--------------
+
+The main rules' patterns must follow this syntax, with optional parts in
+brackets::
+
+      { DISTINGUISHING-WORD ( [BODY-PATTERNS] ) }
+
+`{BODY-PATTERNS}`
+      One or more sets of code fragments and pattern variables separated by
+      semicolons and/or commas.
+
+The parser will end the macro call when it sees the closing parenthesis. Other
+patterns in the macro can also include parentheses, so long as they are matched;
+the parser understands nested parentheses.
+
+As a special case, function macros can be called using operator, slot access, or
+element access syntax. The function macro has to accept expressions for its
+`{BODY-PATTERN}` arguments like a normal function call in order to be used with
+these syntaxes.
+
+
+********
+Patterns
+********
+
+Pattern matching follows these basic rules:
+
+- Pattern-matching starts and ends with the main rule set.
+- Patterns in a rule set are tried in order. If a pattern does not match the
+  code fragment, the next pattern is tried, and so on. If none of the patterns
+  in a rule set match, macro expansion fails.
+- When determining whether a pattern matches a code fragment, the compiler will
+  not consider auxiliary rules. Any pattern variable corresponding to an
+  auxiliary rule matches like any other pattern variable with the same
+  constraint.
+- If no patterns in an auxiliary rule set match, macro expansion fails. The
+  compiler does not backtrack and try a different earlier rule.
+
+
+Subdivisions
+============
+
+A main rule pattern has elements like `define` and `end` as described in
+`Macro Types`_, but in general, a pattern is a list of fragments or
+pattern variables separated at the highest level by semicolons, then by commas.
+That is, a pattern has this syntax::
+
+        FRAGMENTS, FRAGMENTS, ...; FRAGMENTS, FRAGMENTS, ...; ...
+
+The parser matches each semicolon-separated sub-pattern individually, and only
+then matches the comma-separated sub-patterns within. This can have surprising
+side effects in combination with recursive auxiliary rules.
+
+A pattern can include a trailing comma or semicolon, but this is strictly
+decorative. The pattern will match a trailing separator in the code fragment
+whether or not the pattern contains a trailing separator. Keep this in mind. The
+following patterns are equivalent::
+
+        { ?:name }
+        { ?:name; }
+        { ?:name, }
+
+Any of them will match any of these code fragments::
+
+        alpha
+        alpha,
+        alpha;
+        alpha,;
+
+You can use parentheses, curly brackets ("{...}"), and square brackets to nest
+comma- or semicolon-separated patterns inside of other patterns, as in this
+example::
+
+        { ?name:name, { ?true-expr:expression; ?false-expr:expression }, ?final:name }
+
+Such a pattern will only match a code fragment with matching bracket characters.
+The above pattern will match the first line of the following, but not the
+second::
+
+      alpha, {#t; #f;}, beta
+      alpha, (#t; #f;), beta
+
+
+.. _final-items:
+
+Final items
+===========
+
+A pattern with at least two list items treats the last item specially. For example, the
+pattern `{ ?item-1:*, ?item-2:*, ?item-3:* }` will match any of these code fragments,
+
+   .. code-block:: none
+      :linenos:
+
+      alpha, beta, gamma
+      alpha, beta
+      alpha, beta, gamma, delta, epsilon
+
+and will set the pattern variables as follows:
+
+==============  =======  =======  =======================
+Code Fragments  ?item-1  ?item-2  ?item-3
+==============  =======  =======  =======================
+Line 1          `alpha`  `beta`   `gamma`
+Line 2          `alpha`  `beta`
+Line 3          `alpha`  `beta`   `gamma, delta, epsilon`
+==============  =======  =======  =======================
+
+This special behavior is usually only relevant when the last item in the list is a
+wildcard pattern variable (see :ref:`wildcard-variables`). If the pattern were `{
+?item-1:*, ?item-2:*, ?item-3:name }` instead, the only matching code fragment would be
+line 1, because neither an empty fragment (from line 2) nor `gamma, delta, epsilon` (from
+line
+3) match the `name` constraint of `?item-3`.
+
+
+Property lists
+==============
+
+The end of a comma-separated list of pattern fragments can include `#rest`,
+`#key`, and `#all-keys`, as in this example::
+
+        { ..., #rest ?keys:token, #key ?alpha:token, ?beta:token, #all-keys }
+
+This syntax is *not* used to match a code fragment that contains literal
+`#rest`, `#key`, and `#all-keys` fragments. Instead, this syntax matches a code
+fragment consisting of keyword/value pairs, called a `property list`:dfn:. An
+example of a property list is::
+
+        alpha: "a", beta: "b"
+
+In this code fragment, `alpha:` and `beta:` are the keyword or `symbol
+parts`:dfn: of the property list and `"a"` and `"b"` are the `value parts`:dfn:.
+
+If you want to match literal `#rest`, `#key`, or `#all-keys` fragments, escape
+them in the pattern like `\\#rest`, `\\#key`, or `\\#all-keys`.
+
+If you write a pattern that contains `#all-keys`, you must also include `#key`.
+There are several variations on this syntax; they are described in
+:ref:`proplist-variables`.
+
+`#rest`, `#key`, and `#all-keys` must be the only pattern fragments in their
+comma-separated sub-pattern, and that sub-pattern must be the last of several
+comma-separated sub-patterns. Here are some examples of when it **is** or **is
+not** valid to use this syntax in a pattern::
+
+        /* valid */     { #key ?alpha:token }
+        /* not valid */ { ?alpha:token #key ?beta:token }
+        /* valid */     { ?anything:*, #key ?alpha:token, #all-keys }
+        /* not valid */ { #key ?alpha:token, #all-keys, ?anything:* }
+        /* valid */     { #key ?alpha:token, #all-keys; ?anything:* }
+        /* not valid */ { #key ?alpha:token, #key ?beta-token }
+        /* valid */     { #key ?alpha:token; #key ?beta-token }
+
+
+*****************
+Pattern Variables
+*****************
+
+A macro pattern variable pulls out and transforms part of a code fragment. This
+partial code fragment is then substituted into the macro's expansion. The
+substitution can be altered in some ways, or intercepted and more extensively
+transformed using auxiliary rules.
+
+Every pattern variable has a name and a `constraint`:dfn:. The constraint forces
+the pattern variable to only match certain code fragments. If the pattern
+variable cannot match, the pattern containing the variable will not match.
+Unless the pattern variable has the wildcard (or `*`) constraint, it can only
+match a code fragment that is part of the core language or a macro call; a
+pattern variable cannot match a code fragment that is only legal with respect to
+a given inner macro. An example of this is given in the discussion of the
+`?:body` constraint below.
+
+The scope of a pattern variable is the rule that uses it. Other rules or
+auxiliary rule sets cannot use the pattern variable.
+
+
+Simple pattern variables
+========================
+
+`?{name}:{constraint}`
+        This is the basic pattern variable.
+
+`?:{constraint}`
+        This is a pattern variable where its constraint is also its name. For
+        example, `?:expression` is equivalent to `?expression:expression`,
+        that is, a pattern variable named `expression` with a constraint of
+        `expression`.
+
+`?{name}:name`
+        This matches a name.
+
+`?{name}:token`
+        This matches a name, operator, or simple literal such as a string,
+        character constant, or number. It does not match vector literals or
+        function calls.
+
+`?{name}:expression`
+        This matches any expression, including vector literals, function calls,
+        and begin...end blocks.
+
+`?{name}:variable`
+        This matches a variable name and optional specialization, for example,
+        `color` or `color :: <color>`.
+
+`?{name}:name :: ?{specialization}:expression`
+        This matches a variable name and optional specialization, like
+        `?:variable`, but lets you extract each part separately. If the code
+        fragment just has the name part, the substitution for
+        `?{specialization}` will be `<object>`. Note that `?{specialization}`
+        will not match every expression; it will only match an expression that
+        happens to also be a valid type specialization.
+
+
+.. _proplist-variables:
+
+Property list pattern variables
+===============================
+
+`#rest ?{name}:{constraint}`
+        This matches a property list where every value part meets the
+        constraint. If the constraint is `*`, any value part will match. The
+        substitution for `?{name}` is the entire property list code fragment,
+        including both the symbol and value parts of each property.
+
+`#key ?{prop-1}:{constraint}, ?{prop-2}:{constraint}`
+        This matches a property list that only includes the `{prop-1}:` and
+        `{prop-2}:` properties. If the property list includes any other property
+        such as `alpha:` or if either `{prop-1}:` or `{prop-2}:` are missing,
+        this pattern variable will not match. Additionally, the properties'
+        value parts have to meet the constraints given. If the constraint is
+        `*`, any value part will match.
+
+        The substitution for `?{prop-1}` is the value part of the `{prop-1}:`
+        property.
+
+`#key ??{prop-1}:{constraint}, ??{prop-2}:{constraint}`
+        This matches a property list that has several properties with a symbol
+        part of `{prop-1}:` or `{prop-2}:`. The substitution for `??{prop-1}` is
+        several code fragments, each being the value part of a `{prop-1}:`
+        property. The substitution may use one of the separators listed in
+        :ref:`finalitems-subst` between each code fragment.
+
+        For example, consider this pattern::
+
+                { #key ??my-key:name }
+
+        It will match the following code fragment::
+
+                my-key: alpha, my-key: beta
+
+        The substitution will be the following code fragment::
+
+                alpha beta
+
+        If the property list did not include a `my-key:` property, the
+        substitution for `??my-key` would have been empty.
+
+`#key ?{prop}:{constraint}, #all-keys`
+        This matches a property list that contains `{prop}:`, but also matches
+        if the property list contains other properties in addition to
+        `{prop}:`.
+
+        For example, consider this code fragment::
+
+                my-key: alpha, another-key: beta
+
+        This pattern would not match::
+
+                { #key ?my-key:name }
+
+        However, this pattern would::
+
+                { #key ?my-key:name, #all-keys }
+
+`#key ?{prop}:{constraint} = {default-value}`
+        This matches a property list that contains `{prop}:`, but also matches
+        a property list that is missing that property. If the property is
+        missing, the substitution will be the default value given.
+
+        The default value is not evaluated during macro expansion. Instead, it
+        is simply treated as a code fragment and substituted for `?{prop}` in
+        the template. The default value code fragment does not have to abide by
+        the pattern variable's constraint. For example, the following pattern is
+        valid even though `#f` is not a name::
+
+                { #key ?name:name = #f }
+
+`#key ??{prop}:{constraint} = {default-value}`
+        This matches a property list containing zero or more `{prop}:`
+        properties. If `{prop}:` properties are present, the substitution for
+        `??{prop}` will be a sequence of value parts as it is for the `#key
+        ??{prop}:{constraint}` pattern. However, if the property list does not
+        have any `{prop}:` properties, the substitution will be a sequence of
+        only one code fragment — the default value code fragment.
+
+`#rest {...}, #key {...}`
+        With these two syntaxes are combined, both match separately against the
+        same property list.
+
+
+Body and macro pattern variables
+================================
+
+`?{name}:body`
+        This matches a series of semicolon-separated statements and expressions.
+        If the code fragment does not have any statements or expressions, the
+        substitution will be `#f`. The substitution will wrap the code
+        fragment in `begin` and `end` to make an expression.
+
+        A `?:body` pattern variable matches statements and expressions in a code
+        fragment until it reaches some word, called an `intermediate word`:dfn:.
+        You must ensure that all your `?:body` pattern variables are either
+        followed by a word, or followed by a pattern variable referring to an
+        auxiliary rule set whose rules all start with a word. Those word will
+        become the intermediate words that tells the parser to stop matching the
+        pattern variable.
+
+        In this example, the `?:body` variable matches all code fragments up to
+        `endif`::
+
+                { if (?:expression) ?:body endif }
+
+        In this example with auxiliary rules, the `?:body` variable matches
+        all code fragments up to `endif` or `else`::
+
+                { if (?:expression) ?:body ?else-or-end }
+                else-or-end:
+                { endif }
+                { else ?:body endif }
+
+        In this example, the macro will not work because the pattern does not
+        include an intermediate word following the `?:body` variable::
+
+                { when (?:expression) ?:body }
+
+        A `?:body` pattern variable matches semicolons. It cannot be used in a
+        series of comma- or semicolon-separated sub-patterns, and cannot itself
+        be followed by a comma or semicolon in the pattern. The following will
+        not work::
+
+                { if (?:expression) ?:body; ?else-or-end }
+
+        A `?:body` pattern variable does not match things that are not
+        statements or expressions. For example, the following pattern is
+        designed to be used with the above `if` macro::
+
+                { if-into (?:expression) ?rest:body => ?:name } => { let ?name = if (?expression) ?rest }
+
+        You might expect that you can use this macro on the following code::
+
+                if-into (x = #f) format-out("false") else x + 1 endif => x
+
+        However, the `?rest:body` variable will not match the words `else` or
+        `endif` because they are not part of the core Dylan language. They are
+        not statements or expressions. Those words are actually an extension to
+        the language allowed by the `if` macro, but the `if` macro will never
+        see them because the `?rest:body` variable does not match or pass them
+        on to the `if` macro. To match arbitrary fragments for the `if` macro,
+        the `if-into` macro must use the wildcard constraint on the variable
+        instead, like `?rest:*`.
+
+`?{name}:case-body`
+        This matches a list of cases separated by semicolons, where each case
+        consists of: a list of expressions, an arrow, and a body. For example,
+        this pattern variable would match the following::
+
+                "red" => "stop";
+                "green", "blue" => "go";
+                otherwise => error("I don't know what this means.")
+
+        Since a case includes a body, a `?:case-body` pattern variable must be
+        followed with an intermediate word just like a `?:body` pattern
+        variable and cannot be followed by a comma or semicolon.
+
+`?{name}:macro`
+        This matches any macro call. The substitution will be the expanded
+        macro, without the begin...end block that normally surrounds macro
+        expansions.
+
+        While you can use `?:expression` and `?:body` pattern variables to match
+        macro calls, their substitutions will include a called macro's begin...end
+        wrapper, and `?:expression` can only match function macro calls.
+
+
+.. _wildcard-variables:
+
+Wildcard pattern variables
+==========================
+
+`?{name}:*`
+        Wildcard pattern variables match as many code fragments as can be
+        matched before the next comma, semicolon, or other pattern fragment in
+        the pattern. For example, consider the following pattern::
+
+                { ?many-things:* ?:name }
+
+        `?many-things` will match everything up to but not including a name. The
+        substitution for `?many-things` will be everything except that name. If
+        the code fragment only has a name, the substitution for `?many-things`
+        will be empty.
+
+        There can only be one wildcard pattern variable in a comma- or
+        semicolon-separated sub-pattern. Each must be separated from other
+        wildcards by a semicolon or comma. For example, this is not a legal
+        pattern::
+
+                { ?first:* ?second:* }
+
+        However, this is::
+
+                { ?first:*, ?second:* }
+
+        As a special case, main rules of definition macros can have wildcards in
+        both the `{MODIFIERS}` part and the `{LIST-PATTERN}` or `{BODY-PATTERN}`
+        part without an intervening comma or semicolon. This allows patterns
+        like the following that would normally not be allowed::
+
+                { define ?modifiers:* collection ?:name ?contents:* end }
+
+        Finally, consider this pattern::
+
+                { ?first:*, ?second:* }
+
+        As described in `Patterns`_, it will match any of the following::
+
+                alpha, beta
+                alpha, beta, gamma
+                alpha,
+                alpha
+
+        In all cases, the wildcard constraint on `?first` will match up to the
+        first comma in the code fragment. `?first` will contain `alpha`.
+        `?second` will contain nothing, `beta`, or `beta, gamma`.
+
+
+Auxiliary rule set pattern variables
+====================================
+
+`?{aux-rules}`
+        This syntax can only be used when there is an auxiliary rule set named
+        the same as the pattern variable. It is equivalent to `?{aux-rules}:*`.
+        See `Auxiliary Rules`_.
+
+`...`
+        This syntax can only be used within an auxiliary rule set. If the rule
+        set is named `my-aux-rules`, `...` is equivalent to `?my-aux-rules:*`.
+
+
+*************
+Substitutions
+*************
+
+Pattern variables contain code fragments, which can be inserted into the macro
+expansion via a substitution. A substitution looks much like a pattern variable,
+but it is on the template side of the rule and has different syntax forms.
+
+A template can only use pattern variables from its corresponding pattern. It
+cannot use pattern variables from other rules' patterns.
+
+
+.. _finalitems-subst:
+
+Final items
+===========
+
+As a special case, if the template has a separator followed by any of the
+substitution forms below, and the substituted code fragment is empty, the
+preceding separator is removed. For example, consider this template::
+
+        { ?alpha, ?beta }
+
+If `?alpha` contains `a` and `?beta` is empty, the expansion will not be `a,`, but will
+instead be `a`. This special case applies with any of the following separators in place
+of the comma: `, ; + - * / ^ = == ~= ~== < <= > >= & | :=`
+
+
+
+Simple substitutions
+====================
+
+`?{name}`
+        This is the basic substitution. The pattern variable's code fragment is
+        inserted into the expansion according to the syntax used in the pattern,
+        as described in `Pattern Variables`_.
+
+
+Conversion substitutions
+========================
+
+`?#"{name}"`
+        The code fragment of the pattern variable `{name}`, which must be a
+        simple name, is turned into a symbol and inserted into the expansion.
+
+`?"{name}"`
+        The code fragment of the pattern variable `{name}`, which must be a
+        simple name, is turned into a string and inserted into the expansion.
+
+
+Concatenation substitutions
+===========================
+
+`"{prefix}" ## ?{name} ## "{suffix}"`
+        The prefix and suffix are added to the pattern variable's code fragment,
+        which must be a simple name. The result is inserted into the expansion.
+        Either the prefix or the suffix may be omitted.
+
+        For example, consider a pattern variable, `?name-part`, that contains
+        the following code fragment::
+
+                alpha
+
+        The pattern variable is used by the following template::
+
+                { ?name-part ## "-function" }
+
+        The expansion will be the following code fragment::
+
+                alpha-function
+
+`"{prefix}" ## ?"{name}" ## "{suffix}"`
+        As above, but results in a string. In the above example, the resulting
+        code fragment would be the following::
+
+                "alpha-function"
+
+`"{prefix}" ## ?#"{name}" ## "{suffix}"`
+        As above, but results in a symbol::
+
+                #"alpha-function"
+
+        Or, equivalently::
+
+                alpha-function:
+
+
+List substitutions
+==================
+
+`??{name} ...`
+        Used with a `??`-style pattern variable to make a list. Consider a
+        pattern variable, `??name-parts`, that contains the following code
+        fragments::
+
+                alpha beta gamma
+
+        The pattern variable is referenced by the following template and
+        substitution::
+
+                { ??name-parts ... }
+
+        The expansion will be the following code fragment::
+
+                alpha beta gamma
+
+`??{name}, ...`
+        As above, but the expansion would be the following::
+
+                alpha,beta,gamma
+
+        Consider if `??name-parts` contained the following code fragment::
+
+                alpha
+
+        The expansion would be the following, without any commas::
+
+                alpha
+
+        Any of the following separators may be used in place of a comma in
+        the template: `, ; + - * / ^ = == ~= ~== < <= > >= & | :=`
+
+
+Auxiliary rule set substitution
+===============================
+
+`...`
+        This syntax can only be used within an auxiliary rule set. If the rule
+        set is named `my-aux-rules`, this syntax is equivalent to
+        `?my-aux-rules`.
+
+
+Unhygienic reference
+====================
+
+`?={binding}`
+        This is not a substitution, but a way to refer to a binding in the
+        macro's caller. See `Hygiene`_.
+
+
+******************************
+Auxiliary Rules and Expansions
+******************************
+
+Auxiliary Rules
+===============
+
+Auxiliary rules transform the code fragment contained in a pattern variable
+before it is substituted into a template.
+
+Auxiliary rule sets follow the syntax described in `Patterns`_ and have the
+behaviors described in that section. They do not have the special elements like
+`define` or `{modifiers}` shown in `Main Rules`_, but the macro type does
+place certain *de facto* restrictions on what can appear in auxiliary rule
+patterns:
+
+- `end` cannot usefully appear in an auxiliary rule pattern of a body-style
+  definition macro or a statement macro unless it is enclosed in bracketing
+  characters.
+- `;` cannot usefully appear in an auxiliary rule pattern of a list-style
+  definition macro unless enclosed in bracketing characters.
+
+An auxiliary rule set comes into play when a pattern variable matches a code
+fragment and that pattern variable is named the same as the auxiliary rule set.
+Usually, the pattern variable is a wildcard variable written without a
+constraint, but the pattern variable can use any of the forms described in
+`Patterns`_, including the `#key` and `??{name}:{constraint}` forms.
+
+After the pattern variable matches and is set to a code fragment, that code
+fragment is matched against the rules of the auxiliary rule set. If a rule's
+pattern matches the code fragment, that rule's template is expanded and replaces
+the code fragment contained by the pattern variable. If no rules match the code
+fragment, macro expansion fails.
+
+If the pattern variable being examined is a `??`-style pattern variable, the
+process is similar, except each code fragment in the pattern variable is
+individually matched and transformed by the auxiliary rules.
+
+
+Expansions
+==========
+
+This section discusses expansions through a series of examples. The examples are
+all variations of a function macro named `version` that builds a version number
+in a specific format and sets it by calling a function `set-version`. The
+`set-version` function is declared like this::
+
+      define function set-version (version-string :: <string>) => ()
+
+
+Simple expansion
+----------------
+
+First, let us consider the `version` macro below.
+
+   .. code-block:: dylan
+      :linenos:
+
+      define macro version
+        { version(?number:expression, ?type:name) }
+          => { set-version(?number ?type) }
+      type:
+        { alpha } => { "a" }
+        { beta } => { "b" }
+        { release } => { }
+      end macro
+
+The macro is called like this
+
+   .. code-block:: dylan
+
+      version("1.2", alpha)
+
+and the generated code looks like this:
+
+   .. code-block:: dylan
+
+      set-version("1.2" "a")
+
+   .. tip:: Dylan compilers concatenate consecutive literal strings such as `"1.2" "a"`,
+            giving `"1.2a"`.
+
+The `?type` pattern variable in line 1 of the macro definition matches `alpha`
+in the call. After the variable matches, the `type:` auxiliary rule set in lines
+4–7 rewrites the contents of the pattern variable according to the matching rule
+in line 5. The matching rule expands to the string `"a"`, which replaces the
+`alpha` code fragment in the pattern variable. In the main rule's template (line
+3), the pattern variable (now containing `"a"`) is substituted into the
+expansion.
+
+Effect of constraints
+^^^^^^^^^^^^^^^^^^^^^
+
+Now consider if the auxiliary rules were rewritten this way:
+
+   .. code-block:: dylan
+      :linenos:
+      :emphasize-lines: 5-7
+
+      define macro version
+        { version(?number:expression, ?type:name) }
+          => { set-version(?number ?type) }
+      type:
+        { alpha, ?n:expression } => { "a" ?n }
+        { beta, ?n:expression } => { "b" ?n }
+        { release, ?n:expression } => { }
+      end macro
+
+This macro is intended to be called like this
+
+   .. code-block:: dylan
+
+      version("1.0", alpha, "1")
+
+to create a version number like `"1.0a1"`. However, the macro will never succeed. `?type`
+in line 2 has the `name` constraint, so it cannot match the call, which includes a comma
+and an additional clause. The `type:` auxiliary rule set will not even be consulted and
+macro expansion will fail.
+
+
+Empty and missing code fragments
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+An auxiliary rule set can match against a missing code fragment. Consider the
+following macro call in relation to the `version` macros above.
+
+.. code-block:: dylan
+
+   version("1.0")
+
+With this macro call, the `?number` pattern variable would contain `"1.0"` and
+`?type` would be empty, as described in :ref:`final-items`. The macro would fail
+to match this code fragment, since the `name` constraint of the `?type`
+variable does not match a missing code fragment.
+
+If we changed the macro definition to include a wildcard constraint, like this,
+
+   .. code-block:: dylan
+      :linenos:
+      :emphasize-lines: 2
+
+      define macro version
+        { version(?number:expression, ?type:*) }
+          => { set-version(?number ?type) }
+      type:
+        { alpha } => { "a" }
+        { beta } => { "b" }
+        { release } => { }
+      end macro
+
+the macro would still fail to match the code fragment because,
+while the `?type` pattern variable itself will match, the `type:` auxiliary rule
+set does not have a pattern that matches a missing code fragment. We would also
+have to add the rule highlighted below:
+
+   .. code-block:: dylan
+      :linenos:
+      :emphasize-lines: 8
+
+      define macro version
+        { version(?number:expression, ?type:*) }
+          => { set-version(?number ?type) }
+      type:
+        { alpha } => { "a" }
+        { beta } => { "b" }
+        { release } => { }
+        { } => { }
+      end macro
+
+
+Complex expansion
+-----------------
+
+Now suppose we wanted to support this syntax:
+
+   .. code-block:: dylan
+
+      version(major: 1, rev: 0, rev: 4, rev: 2, type: alpha)
+
+This macro should expand to
+
+   .. code-block:: dylan
+
+      set-version(concatenate(format-to-string("%s", 1),
+                              ".",
+                              format-to-string("%s", 0),
+                              format-to-string("%s", 4),
+                              format-to-string("%s", 2),
+                              "a"))
+
+to generate a version number like `"1.042a"`. The macro could be defined like this:
+
+   .. code-block:: dylan
+      :linenos:
+
+      define macro version
+        { version(#key ?major:expression, ??rev:expression, ?type:name = none) }
+          => { set-version(concatenate(?major, ".", ??rev, ..., ?type)) }
+      major:
+        { ?rev } => { ?rev }
+      rev:
+        { ?:expression } => { format-to-string("%s", ?expression) }
+      type:
+        { alpha } => { "a" }
+        { beta } => { "b" }
+        { release } => { }
+        { none } => { }
+      end macro
+
+
+Property lists and optional properties
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The macro call must include the `major:` property, but the `rev:` and `type:`
+properties are optional.
+
+`rev:` is optional because it is a `??`-type pattern variable and, as described
+in :ref:`proplist-variables`, that type of pattern variable can handle a missing
+property. If the macro call did not include any `rev:` properties, the
+substitution for `??rev, ...` would be empty. This would also cause the comma
+after `"."` in line 3 to vanish, as described in :ref:`finalitems-subst`.
+
+`type:` is optional because the pattern variable includes a default value. If
+the macro call did not include `type:`, the substitution for `?type` in line 3
+would be empty. It would initially be `none`, but then the pattern variable
+would be processed by the `type:` auxiliary rule set and matched by the rule in
+line 12, and its contents replaced by the empty template for that rule. Because
+`?type` in line 3 would be empty, the comma after `??rev, ...` would vanish.
+
+You may have noted that the `major:`, `rev:`, and `type:` auxiliary rule sets do
+not include the actual `major:`, `rev:`, or `type:` symbols found in the macro
+call. This is because `#key`-type pattern variables contain only the value parts
+of properties, not the symbol parts.
+
+Auxiliary rule sets in auxiliary rules
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+In line 5, `?rev` is equivalent to `?rev:*`. The code fragment matched by that
+pattern variable is the code fragment initially contained by the `?major`
+pattern variable matched in line 2. This code fragment will be an expression.
+Because `rev` is also the name of an auxiliary rule set, that code fragment will
+be matched and transformed by the `rev:` rule set. That transformed code
+fragment will be inserted in place of the `?rev` substitution in line 5 and then
+subsequently inserted in place of the `?major` substitution in line 3.
+
+`??` and `?` pattern variables
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The main rule and the `major:` auxiliary rule set both contain a pattern
+variable named `rev`, though it is `??rev:expression` in the main rule (line 2)
+and `?rev` in the auxiliary rule (line 5). Both pattern variables are
+transformed by the `rev:` auxiliary rule in line 7 because both pattern
+variables have the name `rev`, but they are transformed differently because of
+the different natures of the two pattern variables.
+
+Because the `?major` pattern variable in line 2 is a simple pattern variable
+that contains only one code fragment, the `rev:` rule in line 7 that acts on it
+(for reasons described above) transforms that fragment as you would expect:
+`?major` will become a call to `format-to-string`.
+
+However, the `??rev` pattern variable in line 2 is a `??`-type pattern variable
+containing zero or more code fragments, so when acting on *it*, the `rev:`
+rule transforms each code fragment individually. The `??rev, ...` substitution
+in line 3 then joins each of the transformed code fragments with a comma and
+includes the entire collection in the main rule expansion, transforming the list
+of revision numbers to a list of calls to `format-to-string`.
+
+Empty `??` pattern variables
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+In line 2, the `?type` variable has a default. If the macro call does not
+contain a `type:` property, the default provides a code fragment to match
+against the `type:` auxiliary rule set.
+
+In contrast, the `??rev` variable does not have a default. If the call does not
+include any `rev:` properties then the pattern variable will not contain a code
+fragment. Since the `rev:` rule does not include an empty pattern, you might
+expect the macro to fail.
+
+But the macro still works. The `rev:` rule will be applied to each code fragment
+in `??rev` individually because it is a `??`-type pattern variable. Since there
+are no code fragments in `??rev`, the `rev:` rule set is not applied even once,
+so its lack of an empty pattern is irrelevant.
+
+
+Recursive expansion
+-------------------
+
+Any pattern variable named the same as an auxiliary rule is processed by that
+rule. That includes pattern variables in the auxiliary rule referring to the
+auxiliary rule set itself. This recursive behavior is useful for processing
+lists of items.
+
+The `...` pattern variable and substitution syntaxes draw attention to a recursive rule
+and make the author's intention explicit. Using that syntax, these two `path` macros are
+equivalent:
+
+   .. code-block:: dylan
+      :linenos:
+      :emphasize-lines: 4-7
+
+      define macro path
+        { path(?steps) } => { let x = 0; let y = 0; ?steps; values(x, y) }
+      steps:
+        { north ?:token, ?steps:* } => { y := y - ?token; ?steps }
+        { south ?:token, ?steps:* } => { y := y + ?token; ?steps }
+        { west ?:token, ?steps:* } => { x := x - ?token; ?steps }
+        { east ?:token, ?steps:* } => { x := x + ?token; ?steps }
+        { } => { }
+      end macro
+
+   .. code-block:: dylan
+      :linenos:
+      :emphasize-lines: 4-7
+
+      define macro path
+        { path(?steps) } => { let x = 0; let y = 0; ?steps; values(x, y) }
+      steps:
+        { north ?:token, ... } => { y := y - ?token; ... }
+        { south ?:token, ... } => { y := y + ?token; ... }
+        { west ?:token, ... } => { x := x - ?token; ... }
+        { east ?:token, ... } => { x := x + ?token; ... }
+        { } => { }
+      end macro
+
+But if I may editorialize, I feel there is a good argument for avoiding that syntax for
+the sake of consistency.
+
+Let us trace the following macro call to show how macro recursion works::
+
+      let (x, y) = path(north 5, east 3, south 1, east 2)
+
+The patterns and templates will be evaluated as follows:
+
+1. The main rule pattern matches. `?steps` is set to
+   `north 5, east 3, south 1, east 2`.
+#. The contents of `?steps` is rewritten by the `steps:` auxiliary rule set.
+
+   a. The "north" rule is matched against `north 5, east 3, south 1, east 2`.
+      The pattern is a comma-separated pattern, which matches the code fragment.
+      The word `north` and the token `5` match. As described in
+      :ref:`final-items`, the `?steps` pattern variable belonging to this
+      pattern-match operation is set to `east 3, south 1, east 2`.
+   #. The contents of this rule's `?steps` variable is rewritten by the `steps:`
+      auxiliary rule set.
+
+      i. The "north," "south," and "west" rules fail to match against
+         `east 3, south 1, east 2`.
+      #. The "east" rule matches and the `?steps` pattern variable of this
+         pattern-match operation (different from any other `?steps` variable
+         being dealt with) is set to `south 1, east 2`.
+      #. `?steps` is rewritten by another pass through the `steps:` rule set.
+
+         1. The "south" rule matches and its `?steps` is set to `east 2`.
+         #. `?steps` is again rewritten.
+
+            a. The "north," "south," and "west" rules fail to match.
+            #. The "east" rule is matched against `east 2`. The word `east` and
+               the token `2` match. The code fragment does not contain a comma,
+               but the pattern matches the code fragment without the comma per
+               :ref:`final-items`. The `?steps` pattern variable will contain an
+               empty code fragment.
+            #. Even though `?steps` contains an empty code fragment, it is still
+               rewritten by the `steps:` auxiliary rule set.
+
+               i. The "north," "south," "west," and "east" rules fail to match
+                  against an empty code fragment.
+               #. The empty pattern matches. Its expansion is an empty fragment.
+
+            #. The `?steps` pattern variable of the "east" rule is set to the
+               expansion of the auxiliary rule set, i.e., an empty fragment.
+            #. The rule's expansion is therefore `x := x + 2`.
+
+         #. The `?steps` pattern variable of the "south" rule is set to
+            `x := x + 2`.
+         #. The rule's expansion is therefore `y := y + 1; x := x + 2`.
+
+      #. The `?steps` pattern variable of the "east" rule is set to
+         `y := y + 1; x := x + 2`.
+      #. The rule's expansion is therefore `x := x + 3; y := y + 1; x := x + 2`
+
+\...and so on. The key ideas to note are:
+
+- The rule set has to have a non-recursing rule (in this case, `{ } => { }`)
+- Each rule's matching and expansion has its own `?token` and `?steps`
+  pattern variable.
+
+
+*******
+Hygiene
+*******
+
+Macro expansions are hygienic, meaning there can be no name conflict between
+a local binding in scope that calls the macro and a local binding in the macro
+expansion.
+
+Let us say we have two macros A and B. The expansion of A calls B. The following
+diagram shows the lexical scopes of bindings used in A and B. The table after
+describes the scopes in more detail.
+
+.. raw:: html
+
+   <pre style="line-height: 1em; font-family: Andale Mono, Courier New">
+   ╒═════════════════════════════════════╕
+   │ [1] Module or lexical scope of a    │
+   │     call to macro A                 │
+   │                                     │
+   │  ┌───────────────────────────────┐  │
+   │  │ [2] Expansion of A            │  │
+   │  │                               │  │
+   │  │  ┌─────────────────────────┐  │  │
+   │  │  │ [3] Expansion of B      │  │  │
+   │  │  │                         │  │  │
+   │  │  └─────────────────────────┘  │  │
+   │  │                               │  │
+   │  └───────────────────────────────┘  │
+   │                                     │
+   ╘═════════════════════════════════════╛
+
+   ╒═════════════════════════════════════╕
+   │ [4] Module containing definition of │
+   │     macro A                         │
+   │                                     │
+   ╘═════════════════════════════════════╛
+
+   ╒═════════════════════════════════════╕
+   │ [5] Module containing definition of │
+   │     macro B                         │
+   │                                     │
+   ╘═════════════════════════════════════╛
+   </pre>
+
+In this table, each lexical scope is identified by its number as "Box 1"
+through "Box 5". The table describe which bindings defined in each column's
+lexical scope are visible in the lexical scope of each row. For example, the
+table shows that the only bindings from Box 1 visible in Box 2 are those that
+are captured by one of Macro A's pattern variables and included in the
+expansion.
+
++------------+---------------------+---------------------+---------------------+-------+--------+
+| Definition | Definition Location                                                              |
+| Visibility +---------------------+---------------------+---------------------+-------+--------+
+|            | Box 1               | Box 2               | Box 3               | Box 4 | Box 5  |
++============+=====================+=====================+=====================+=======+========+
+| Box 1      | All                 | Only if defined     | Only if defined     |       |        |
+|            |                     | with unhygienic     | with unhygienic     |       |        |
+|            |                     | reference to name   | reference to name   |       |        |
+|            |                     | from 1, captured by | from 1, captured by |       |        |
+|            |                     | pattern variable of | pattern variable of |       |        |
+|            |                     | A                   | A and recaptured by |       |        |
+|            |                     |                     | pattern variable of |       |        |
+|            |                     |                     | B                   |       |        |
++------------+---------------------+---------------------+---------------------+-------+--------+
+| Box 2      | Only if captured by | All                 | Only if defined     | All   |        |
+|            | pattern variable of |                     | with unhygienic     |       |        |
+|            | A                   |                     | reference to name   |       |        |
+|            |                     |                     | from 2, captured by |       |        |
+|            |                     |                     | pattern variable of |       |        |
+|            |                     |                     | B                   |       |        |
++------------+---------------------+---------------------+---------------------+-------+--------+
+| Box 3      | Only if captured by | Only if captured by | All                 |       | All    |
+|            | pattern variable of | pattern variable of |                     |       |        |
+|            | A and recaptured by | B                   |                     |       |        |
+|            | pattern variable of |                     |                     |       |        |
+|            | B                   |                     |                     |       |        |
++------------+---------------------+---------------------+---------------------+-------+--------+
+| Box 4      |                     |                     |                     | All   |        |
++------------+---------------------+---------------------+---------------------+-------+--------+
+| Box 5      |                     |                     |                     |       | All    |
++------------+---------------------+---------------------+---------------------+-------+--------+
+
+
+Breaking hygiene
+================
+
+A template can prefix a binding with `?=`. This makes the binding come from
+and be visible in the macro's caller. This can be illustrated by an example from
+:title:`Dylan Programming`.
+
+Say this is the Macro A defined in Box 4,
+
+.. code-block:: dylan
+   :linenos:
+   :emphasize-lines: 3
+
+   define macro repeat
+     { repeat ?:body end }
+       => { block (?=stop!)
+              local method again() ?body; again(); end;
+              again();
+            end }
+   end macro
+
+and it is called in Box 1 like so:
+
+.. code-block:: dylan
+
+   let i = 0;
+   repeat
+     if (i == 100) stop!() end;
+     i := i + 1;
+   end
+
+The `?=stop!` substitution in line 3 of the macro becomes a reference to a
+binding visible in Boxes 1 and 2. In Box 1, the binding is visible as `stop!`.
+In Box 2 (the expansion itself), the binding is visible as `?=stop!` and can be
+used like any binding (e.g., `format-out("%=", ?=stop!)`).
+
+Note that that a macro expansion cannot create a new name visible outside of the
+macro call itself. In other words, Box 2 cannot create a binding for use
+elsewhere in Box 1 unless Box 1 supplies the name to be defined.
+
+For example, given this macro,
+
+   .. code-block:: dylan
+      :linenos:
+
+      define macro do-then-foo
+        { do-then-foo(?:expression) ?:body end }
+          => { let ?=foo = ?expression; ?body }
+      end macro
+
+one might expect the macro call
+
+   .. code-block:: dylan
+
+      do-then-foo("Hello\n") format-out(foo) end;
+      format-out(foo)
+
+would print "Hello" twice, but the code does not compile. Because every macro expansion
+is implicitly surrounded by `begin...end` as described in `Background and Overview`_,
+the example expands into:
+
+   .. code-block:: dylan
+
+      begin
+        let foo = "Hello\n";
+        format-out(foo)
+      end;
+      format-out(foo)
+
+After the macro call, `foo` is no longer in scope.
+
+
+************
+FAQ and Tips
+************
+
+General advice and troubleshooting
+==================================
+
+- The best way to design a macro is:
+   1. Come up with the best non-macro interface you can.
+   2. Design the syntax of the macro call up front.
+   3. Implement that design.
+- Gwydion Dylan sometimes has issues with trailing semi-colons or commas. In
+  general, don't include a separator at the end of a template.
+- In both Gwydion Dylan and Open Dylan, the variable declaration for a variable
+  used in the lexical scope of a macro needs to be in that macro. The variable
+  cannot be declared in an auxiliary macro and exposed to the macro through the
+  `?=` mechanism. However, the variable can be declared in an auxiliary rule of
+  the macro.
+- Ensure you haven't accidently given a pattern variable the same name as an
+  auxiliary rule set.
+- In Open Dylan, use `define traced macro` to get additional debug output while
+  developing macros.
+
+
+How can I combine multiple names into one?
+==========================================
+
+There is no real way to do this for names or symbols. The concatenating
+substitution forms do not scale, so this template will not work::
+
+   { define ?name-1 ## "-" ## ?name-2 ## "-function" () }
+
+However, you can easily combine multiple names into a string by taking advantage
+of adjacent string concatenation::
+
+   { format-out(?"name-1" "-" ?"name-2" "-function") }
+
+Your best bet may be to do some sort of string-based introspection, or create
+anonymous definitions stored in a table keyed by a string.
+
+
+How can I write macros that follow a BNF-like syntax?
+=====================================================
+
+Macros are designed to follow Dylan language conventions, so you may not be able
+to support arbitrary BNF-based syntax. But here are some tricks to help with
+common BNF forms.
+
+`{x}?`
+      An optional item can be handled by a wildcard pattern variable using an
+      auxiliary rule with two patterns::
+
+         x-opt:
+           { x }
+           { }
+
+`{x}? {y}? {z}?`
+      If there are several space-separated optional items, put them all in the
+      same auxiliary rule, since the upper rule can't have adjacent wildcard
+      pattern variables that call out to an individual auxiliary rule for each
+      item::
+
+         x-y-z-opts:
+           { x ... }
+           { y ... }
+           { z ... }
+           { }
+
+`{x}? | {x} (, {x})*`
+      This is a list that may have 0–*n* items. Handle this by calling out to an
+      auxiliary rule that calls itself recursively like so::
+
+         x-list:
+           { ?x:*, ?x-list:* }
+           { }
+
+      Note that the calling rule needs to use a wildcard pattern variable to
+      collect the comma'd items for the `x-list:` rule set; this pattern
+      variable needs to be well-separated from the syntax that follows it by a
+      semicolon or intermediate word.
+
+`{x} (, {x})*`
+      This is a list that may have 1–*n* items. You simply cannot do this in the
+      general case; your best bet is design your macro to handle 0 items
+      gracefully and then use a 0-*n* list.
+
+      The following does not work because `?{x}:*` allows an empty code
+      fragment, which allows 0 items::
+
+         x-list:
+           // Doesn't work
+           { ?x:*, ?x-list:* }
+           { ?x:* }
+
+      Of course, if you can put a constraint on `?x`, it will work fine, but
+      remember that a secondary rule can't be used to provide a constraint in a
+      primary rule.
+
+
+I can't make a bare list!
+=========================
+
+A macro that makes a bare list (by which I mean a simple list of comma-separated
+names) cannot do anything useful with it. Macros build cohesive code fragments,
+and a bare list is not such a code fragment.
+
+For example, this will not compile::
+
+   define macro setter-names
+     { setter-names(?names) } => { ?names }
+   names:
+     { ?:name, ... } => { ?name ## "-setter", ... }
+   end macro;
+
+   vector(setter-names(alpha, beta, gamma, delta))
+
+It does not compile because the expansion of `setter-names` is wrapped in a
+begin...end, resulting in this invalid syntax::
+
+   vector(begin alpha-setter, beta-setter, gamma-setter, delta-setter end)
+
+Instead, do something with the list in the macro itself:
+
+.. code-block:: dylan
+   :emphasize-lines: 2, 7
+
+   define macro setter-vector
+     { setter-vector(?names) } => { vector(?names) }
+   names:
+     { ?:name, ... } => { ?name ## "-setter", ... }
+   end macro;
+
+   setter-vector(alpha, beta, gamma, delta)
diff --git a/documentation/website/source/articles/procedural-dylan/1-distance.rst b/documentation/website/source/articles/procedural-dylan/1-distance.rst
new file mode 100644
index 0000000000..65dcab076b
--- /dev/null
+++ b/documentation/website/source/articles/procedural-dylan/1-distance.rst
@@ -0,0 +1,226 @@
+A Simple Function: Distance
+---------------------------
+
+To get the flavor of the language, let us first consider a few simple
+Pascal subroutines and their equivalents in Dylan. Here we have a Pascal
+function for calculating the distance between two points in a two
+dimensional plane, using the Pythagorean theorem:
+
+.. code-block:: pascal
+
+      function distance(x1: real; y1: real; x2: real; y2: real): real;
+      begin
+        distance := sqrt((x2-x1) * (x2-x1) + (y2-y1) * (y2-y1))
+      end;
+
+and here's an equivalent function in Dylan:
+
+.. code-block:: dylan
+
+      define method distance (x1 :: <real>, y1 :: <real>, x2 :: <real>, y2 :: <real>)
+       => distance :: <real>;
+        sqrt((x2 - x1) * (x2 - x1) + (y2 - y1) * (y2 - y1))
+      end method distance;
+
+Let's first look at the syntactic differences between the two functions.
+First, Pascal introduces the definition with the keyword ``function``
+where Dylan uses the phrase ``define method``. ``Define`` is used in
+Dylan when defining all *module variables*, which are the equivalent of
+program variables, types, functions, and procedures in Pascal. We'll see
+later why Dylan calls this function a *method*; for now, it is useful to
+think of methods in Dylan as the same as functions in Pascal.
+
+The next thing to notice is that Dylan uses the double colon symbol
+(``::``) to separate variables from their types; we'll see later that a
+single colon is used for another purpose, which is why the double colon
+is used in type declarations. Also note that the Dylan program has a
+space between the variable name and the double colon.
+
+The next important difference between the two examples is that the name
+of the type, ``real``, is enclosed in "angle brackets" (the less-than
+and greater-than signs) in the Dylan version. The reason for this is
+that, unlike in Pascal, types and variables live in the same *name
+space* in Dylan. For example, in Pascal, one can have a type named
+``list`` and a variable named ``list`` at the same time, and the meaning
+of the identifier ``list`` refers to one or the other depending on
+context. In Dylan, there isn't always enough context to know whether
+something is a type or value -- and, in fact, types *are* values in
+Dylan -- so a convention is used to separate types from non-types in
+order to avoid confusion and name clashes. That convention is putting
+angle brackets around the names of types. (C programmers face a similar
+problem, and at least two distinct conventions have evolved: using
+identifiers with the first letter capitalized or with a suffix of ``_t``
+for type names.)
+
+The convention for type names brings up another difference between Dylan
+and Pascal: What characters are legal in names? Pascal, C, and many
+traditional languages restrict the set of characters allowed in names to
+the letters, digits, and perhaps a few graphical characters, such as the
+underscore or dollar sign. Dylan is more flexible: all those characters
+are legal, but so are many graphical characters, such as hyphens,
+asterisks, question marks, exclamation marks, and, as we have seen, the
+greater-than and less-than signs. The general rule is that a Dylan
+identifier can't start with a digit and should contain at least one
+letter, but any characters that don't otherwise have special meaning are
+allowed.
+
+This flexibility does come at some cost: because the character set for
+variable names overlaps with the character set for operators, we need to
+put spaces between variable names and operators. For example,
+``x2 - x1`` is two two-character long variables separated by the minus
+operator and means the same thing as it does in Pascal, but ``x2-x1`` is
+a single five-character long variable name in Dylan. This may seem
+confusing or awkward at first to programmers not used to putting space
+between variables and operators, but it adds flexibility in the choice
+of names.
+
+Now back to the example function. In Pascal, the return type of the
+function is declared with a colon, just like the type of a variable,
+where Dylan uses an arrow (``=>``) combined with what looks like a
+variable declaration. The return description for our function says that
+the function returns the distance, and that the result has the type
+``<real>``. The name used in a return description is for documentation
+purposes only. Upon reflection, one might come to the conclusion that
+the name is unnecessary as documentation, since the function name should
+describe the meaning of the return value. Later, we'll see a reason why
+Dylan puts the name in the result.
+
+Let's skip the contents of the function body of the function for a
+moment, and notice that Pascal surrounds the body with the words
+``begin`` and ``end``. Dylan is similar, except that the word ``begin``
+is omitted. All methods must have bodies, so where it begins is
+implicit: right after the declaration of parameters and return values.
+The word ``method`` and the name of the method are repeated after the
+word ``end``; both ``method`` and the name are optional after the
+``end``, but I personally prefer to put them in, so I've done that here.
+Individual styles vary, and people who think that the words after
+``end`` clutter the program are free to leave them out.
+
+Now, let's look at the bodies of the functions. Aside from the spaces
+separating the operators from the variable names in the Dylan version,
+there is one major difference. In Pascal, the pseudo-variable with the
+same name as the function, ``distance``, is assigned the value to return
+from the function. In Dylan, on the other hand, the body is treated as
+an expression, and the value of that expression is returned by the
+function. If that body contains multiple statements or expressions
+separated by semicolons, the function returns whatever the last
+expression returns. (C is different from both Dylan and Pascal in this
+regard: it uses the ``return`` statement to both return the value and
+exit immediately from the function.)
+
+The last important detail to notice is that, aside from the issue of
+spaces, the expression used to calculate the distance is the same in
+both Dylan and Pascal.
+
+--------------
+
+In Pascal, the programmer has to declare types for all variables,
+parameters, and functions. In Dylan, type declarations may be omitted;
+if no type is declared for a variable, any value may be used. Similarly,
+the description of what a method returns may be left out. Thus a more
+concise version of distance would be:
+
+.. code-block:: dylan
+
+      define method distance (x1, y1, x2, y2)
+        sqrt((x2 - x1) * (x2 - x1) + (y2 - y1) * (y2 - y1))
+      end method distance;
+
+When used with four real numbers, this distance function produces the
+same result as the original. But this version will work just as well on
+integers. (In fact, the original version also works on integers, because
+the type ``<integer>`` is a *subtype* of ``<real>``; that is, all
+integers are also reals, which matches our mathematical intuition. The
+type ``<float>`` in Dylan corresponds more directly with Pascal's
+``real`` type.)
+
+Since any value can be used as an argument to distance, what happens if
+we use something which doesn't make sense, like
+``distance(0, 0, 3, "four")``? The function starts as normal, but when
+it tries to subtract ``0`` from ``"four"``, the program stops with an
+error, since it makes no sense to subtract a number from a string. If
+we had used the original version of the distance function, we would have
+gotten the error when we tried to call distance.
+
+For now, we'll omit most type declarations in our Dylan examples. Later,
+we'll see some of the reasons for using them other than catching errors.
+
+--------------
+
+Looking back at the distance function, we see that the subtraction
+``x2 - x1`` is done twice in order to multiple the result by itself; the
+same is then done for the y values. To reduce the work that the function
+does, we can store the results of the subtractions in local variables.
+(Many compilers will do this kind of optimization -- known as *common
+subexpression elimination* -- without requiring the code to be
+rewritten.) In Pascal, that might look like:
+
+.. code-block:: pascal
+
+      function distance(x1: real; y1: real; x2: real; y2: real): real;
+      var
+        deltaX, deltaY: real;
+      begin
+        deltaX := x2 - x1;
+        deltaY := y2 - y1;
+        distance := sqrt(deltaX * deltaX + deltaY * deltaY)
+      end;
+
+which could be written in Dylan as
+
+.. code-block:: dylan
+
+      define method distance (x1, y1, x2, y2)
+        let delta-x = x2 - x1;
+        let delta-y = y2 - y1;
+        sqrt(delta-x * delta-x + delta-y * delta-y)
+      end method distance;
+
+First, we see that where Pascal puts the definition of the local
+variables in a separate section of the function definition, Dylan puts
+them in the body. Next, we see that the definition of the local
+variables includes the initialization. In general, when you define a
+variable in Dylan, you give it a value at the same time -- in this way,
+you do not have to worry about initialized variables.
+
+Also notice that where, in Pascal, ``mixedCaseNames`` are often used to
+separate words in long identifiers, Dylan conventionally uses
+``hyphen-separated-names``.
+
+--------------
+
+Another way to rewrite the distance function to only do the
+subtractions once would be to abstract out the squaring operation as a
+local function. In Pascal, this would look like:
+
+.. code-block:: pascal
+
+      function distance(x1: real; y1: real; x2: real; y2: real): real;
+        function square(n: real): real;
+        begin
+          square := n * n
+        end;
+      begin
+        distance := sqrt(square(x2 - x1) + square(y2 - y1))
+      end;
+
+which could be written in Dylan as
+
+.. code-block:: dylan
+
+      define method distance (x1, y1, x2, y2)
+        local method square (n :: <real>)
+                n * n
+              end method square;
+        sqrt(square(x2 - x1) + square(y2 - y1))
+      end method distance;
+
+Like local variables created with ``let``, local methods can appear
+anywhere inside a body.
+
+--------------
+
+`Next -- Conditions and Multiple Values: The Quadratic
+Formula <2-quadratic.html>`_
+
+Copyright © 1995 Paul Haahr. All rights reserved.
diff --git a/documentation/website/source/articles/procedural-dylan/2-quadratic.rst b/documentation/website/source/articles/procedural-dylan/2-quadratic.rst
new file mode 100644
index 0000000000..a1e6545db2
--- /dev/null
+++ b/documentation/website/source/articles/procedural-dylan/2-quadratic.rst
@@ -0,0 +1,234 @@
+Conditions and Multiple Values: The Quadratic Formula
+-----------------------------------------------------
+
+Now we'll look at a slightly more complex function, one which finds the
+roots of a quadratic equation. A Pascal version of such a function might
+be:
+
+.. code-block:: pascal
+
+      (* Solve quadratic equation, putting roots in root1 and root2
+         and returning the number of roots found. *)
+      function solveQuadratic(a, b, c: real; var root1, root2: real): int;
+      var
+        discriminant: real;
+        sqrtDiscriminant: real;
+      begin
+        discriminant := b * b - 4.0 * a * c;
+        if discriminant < 0.0 then
+          solveQuadratic := 0
+        else if discriminant = 0.0 then
+          begin
+            solveQuadratic := 1;
+            root1 := -b/(2.0 * a)
+          end
+        else
+          begin
+            solveQuadratic := 2;
+            sqrtDiscriminant := sqrt(discriminant);
+            root1 := (-b + sqrtDiscriminant)/(2.0 * a);
+            root2 := (-b - sqrtDiscriminant)/(2.0 * a)
+          end
+      end;
+
+There are a few things to note here. The first is the interface to the
+function: since we want to return up to two separate numbers, but maybe
+zero or one in the degenerate cases, we can't just use the normal
+paradigm of returning the result, because Pascal lets functions accept
+many values, but return only one. To work around this restriction, we
+return an integer indicating how many roots there were, and use ``var``
+parameters (also known as *call by reference parameters*) to pass the
+actual results from the function back to its caller. In order for this
+mechanism to work, the function which calls ``solveQuadratic`` must
+define two variables for receiving the results. The caller also has to
+be careful not to use the variable ``root2`` if there was only one root
+returned. Other approaches, such as returning a record containing the
+roots and the number of roots found, are also possible.
+
+There are several other things worth mentioning. The local variable
+``sqrtDiscriminant`` is defined for the entire function, even though it
+is only used in the body of the second ``else`` clause. Because Pascal
+is strongly typed and does not allow operations between integers and
+real numbers, we have to write all the constants, even though they are
+integers, as real numbers in decimal notation. Finally, we see that the
+body of the first ``if`` clause does not have a ``begin`` and ``end``
+because it is a single statement.
+
+--------------
+
+A Dylan function for the same operation would have a different
+interface, at very least because Dylan does not have ``var``
+parameters. Here's one approach:
+
+.. code-block:: dylan
+
+      // Solve quadratic equation, returning the roots
+      define method solve-quadratic(a, b, c) => (root1, root2);
+        let discriminant = b * b - 4 * a * c;
+        if (discriminant < 0)
+          values()
+        elseif (discriminant = 0)
+          values(- b / (2 * a))
+        else
+          let sqrt-discriminant = sqrt(discriminant);
+          values((- b + sqrt-discriminant) / (2 * a),
+                 (- b - sqrt-discriminant) / (2 * a))
+        end if
+      end method solve-quadratic;
+
+The first thing we notice is the notation for comments. Dylan has two
+forms of comments. The sequence ``//`` introduces a comment that
+continues to the end of the line; all the intervening text is ignored by
+the language. The sequence ``/*`` introduces a block comment that
+encloses all the text up to a ``*/``; the enclosed text is ignored
+except that pairs of ``/*`` and ``*/`` inside the comment are matched,
+so block comments nest. The nesting property of block comments means
+that it is safe to use ``/*`` and ``*/`` to comment out code even if
+that code contains block comments. (Dylan shares this comment convention
+with C++, except that in C++, block comments don't nest.)
+
+The most significant difference between this function and the Pascal
+version is what it returns. For the Dylan function, the comment says
+"returning the roots," and that is what it does. In Pascal, C, Fortran,
+and, in fact, most programming languages, a function can take an
+arbitrary number of arguments but the number of values returned can be
+only zero or one. (In Pascal, a function returning no values is called a
+procedure.) In Dylan, functions can return as many values as are
+appropriate for the task at hand, just as they can accept as many
+arguments as make sense.
+
+How does a function return multiple values? We saw earlier that a
+function returns the value of the last expression that makes up its
+body. There is a built-in function named values which returns all of its
+arguments. By calling values as the last statement of a body, the
+arguments passed to values are used as the value of the body. For
+example, the following method could be used to return the sine and
+cosine of an angle:
+
+.. code-block:: dylan
+
+      define method sincos (angle) => (sin :: <real>, cos :: <real>);
+        values(sin(angle), cos(angle))
+      end method sincos;
+
+To use both values returned returned by ``sincos``, one uses a special
+form of ``let`` which is said to *accept multiple values*:
+
+.. code-block:: dylan
+
+      let (s, c) = sincos(theta);
+      ...
+
+Inside the body of the let, the variable s will hold the sine of theta
+and c the cosine. Note, by the way, the return declaration for
+``sincos`` indicates that the method returns two real numbers. The
+reason that names are used in return declarations is to document which
+value is which in the case of multiple-value returning functions.
+
+As a special but typical case, when you are calling a function that
+returns more than one value and you are only interested in the first
+value, you don't have to bind the values with let, you can just use the
+function as an expression. In fact, there is no difference between
+calling a function that returns one value and calling a function that
+returns multiple values if you only want the first value returned.
+
+Let's return to our quadratic equation solver. To see what the function
+returns, we have to look for the last expression in the body. In this
+case, the last statement is an ``if`` statement. In Dylan, an ``if``
+statement is an expression and can be used anywhere a value is expected.
+The value of an if statement is the value of the body of the branch that
+is taken. For example, in the simple case of:
+
+.. code-block:: dylan
+
+      if (even?(n))
+        "even"
+      else
+        "odd"
+      end if
+
+If the number ``n`` is even, the value of the if statement is the string
+``"even"``; otherwise, the value is the string ``"odd"``. Incidentally,
+Dylan is classified as an "expression language" because all statements
+can return values and be used as expressions.
+
+In Pascal and C, one can construct a series of tests by putting if
+statements in the ``else`` clause of another ``if`` statement. In Dylan
+``elseif`` is one word and not two, and the ``elseif`` branch is
+actually part of the if statement. There can be any number of ``elseif``
+clauses between the ``if`` clause and the optional ``else`` clause.
+
+In ``solve-quadratic``, the last statement of every branch of the ``if``
+statement is a call to ``values``. If the first test is true, ``values``
+is called with no arguments, so the function returns no values. If the
+test for the ``elseif`` clause is true, the function returns one value,
+the single root. (In this case, the call to values is unnecessary, but
+it is useful as documentation to contrast with the cases where zero and
+two values are returned.) Finally, if there are two roots, both are
+returned.
+
+How is this function used? In particular, how does a caller determine
+how many roots were found? If a caller is expecting more results than a
+function returns, all the variables for which no value was returned are
+given the false value. So, for example, we could write a function to
+count the number of roots as
+
+.. code-block:: dylan
+
+      define method number-of-quadratic-roots(a, b, c)
+        let (r1, r2) = solve-quadratic(a, b, c);
+        if (r2)
+          2
+        elseif (r1)
+          1
+        else
+          0
+        end if
+      end method number-of-quadratic-roots;
+
+--------------
+
+Before we leave this example behind, let's look at another way to write
+it in Dylan, keeping the same interface:
+
+.. code-block:: dylan
+
+      // Solve quadratic equation, returning the roots
+      define method solve-quadratic(a, b, c) => (root1, root2);
+        let discriminant = b * b - 4 * a * c;
+        case
+          negative?(discriminant) =>
+            values();
+          zero?(discriminant) =>
+            values(- b / (2 * a));
+          otherwise =>
+            let sqrt-discriminant = sqrt(discriminant);
+            values((- b + sqrt-discriminant) / (2 * a),
+                   (- b - sqrt-discriminant) / (2 * a))
+        end case
+      end method solve-quadratic;
+
+There are two differences here. First, the ``if`` statement has been
+rewritten as a ``case`` statement. A ``case`` statement contains a
+series of tests and bodies, separated by the arrow symbol. The tests are
+checked in order and the clause that corresponds to the first test which
+evaluates to true is run, and the value of that clause is used as the
+result of the whole statement. The last test in a ``case`` statement may
+be ``otherwise``: the ``otherwise`` clause is used if none of the tests
+are true. ``Case`` statements are often easier to read than long chains
+of ``elseif`` statements, but choosing one or the other is simply a matter
+of personal style.
+
+Also, the tests have been changed from explicit comparisons with zero to
+calls to function which do those tests. There is no real difference
+between writing ``x < 0`` and ``negative?(x)``, but sometimes one form
+is clearer than the other. A function which returns a boolean value is
+called a *predicate* in Dylan, and, by convention, the names of
+predicates end in question marks, as we can see from ``negative?`` and
+``zero?``.
+
+--------------
+
+`Back -- A Simple Function: Distance <1-distance.html>`_ | `Next -- Iteration and Sequences: Dot Product <3-dot-product.html>`_
+
+Copyright © 1995 Paul Haahr. All rights reserved.
diff --git a/documentation/website/source/articles/procedural-dylan/3-dot-product.rst b/documentation/website/source/articles/procedural-dylan/3-dot-product.rst
new file mode 100644
index 0000000000..23da429299
--- /dev/null
+++ b/documentation/website/source/articles/procedural-dylan/3-dot-product.rst
@@ -0,0 +1,527 @@
+Iteration and Sequences: Dot Product
+------------------------------------
+
+The next function we'll look at calculates the inner product, or *dot
+product*, of two one-dimensional arrays of numbers. This is defined as
+the sum of the pairwise products of numbers from the arrays. As an added
+complication, we'll not fix the length of the arrays, so our Pascal
+version will use conformant arrays, a late addition to the language.
+
+.. The following code block used to be "pascal", but that isn't supported
+   by Sphinx (anymore?).
+
+.. code-block:: none
+
+      function dotProduct(x: array[xlo..xhi: integer] of real,
+                          y: array[ylo..yhi: integer] of real): real;
+      var
+        i: integer;
+        sum: real;
+      begin
+        if (xhi - xlo <> yhi - ylo)
+          error("dotProduct: arrays of different lengths");
+        sum := 0.0;
+        for i := xlo to xhi do
+          sum := sum + x[i] * y[i - xlo + ylo];
+        dotProduct := sum
+      end;
+
+Because a dot product only makes sense for arrays of the same length, we
+need to check that the arrays have the same length before proceeding.
+Since Pascal has no built-in error-handling facilities, we've invented a
+minimal interface -- a procedure named ``error`` which takes a string
+description of the error -- that has to be implemented on every
+different system using non-standard facilities.
+
+There is one other complication worth mentioning here. Since the two
+arrays can have different lower bounds and the loop index ``i`` starts
+at the value for the array ``x``, it has to be adjusted before being
+used as a subscript for ``y``.
+
+--------------
+
+Our first Dylan version of this function uses a while loop:
+
+.. code-block:: dylan
+
+      define method dot-product (x, y)
+        if (size(x) ~= size(y))
+          error("dot-product: arrays of different lengths")
+        end if;
+        let sum = 0;
+        let i = 0;
+        while (i < size(x))
+          sum := sum + x[i] * y[i]
+        end while;
+        sum
+      end method dot-product;
+
+Let's first look at the syntactic differences. Other than using ``~=``
+for the "is not equal to" relationship, Dylan is very similar to Pascal
+for the operations needed in this function. The operator ``:=`` is used
+for assignment to an existing variable (as opposed to ``=``, which is
+used for setting the initial value for a variable created with ``let``)
+and the notation ``*array*[*index*]`` is used for subscripting. As
+with ``if``, the ``while`` statement is always ended with ``end``, and
+no explicit ``begin`` is needed.
+
+The main difference between these two functions is in how they
+manipulate the arrays. When declaring an array in Pascal, a programmer
+specifies both the lower and upper bound; these bounds can be integers,
+characters, or enumerated types. In this regard, Dylan is less flexible
+than Pascal: arrays are always indexed with increasing integers starting
+at zero. (Many other languages, such as C, share this restriction.
+Fortran is similar, but it starts all arrays at one.)
+
+In standard Pascal, the length of all arrays must be known ahead of
+time. The one exception to this is the conformant array feature of ISO
+Pascal, where the bounds of the array are treated as an extra set of
+parameters to a function which accepts an array as an argument. In
+Dylan, all arrays carry with them their length, so we only have to
+specify the size of an array when it is not already known, such as when
+the array is first created. The function ``size`` is used to obtain the
+length of the array. For any array ``a``, the valid indexes of the array
+are from ``0`` to ``size(a) - 1``; that is, ``size(a)`` elements,
+starting at zero.
+
+One more thing to note is that, in Pascal, we had to invent the
+``error`` procedure and say that it is implemented in some
+platform-dependent way. Our Dylan version also calls a function named
+``error``, but this function is a part of the Dylan language. The full
+behavior of ``error`` is rather complicated and beyond the scope of this
+tutorial -- Dylan has a powerful exception handling and recovery
+mechanism for dealing with and possibly correcting errors discovered
+while a program is running -- but if you're running the program in a
+debugger, a call to error will generally result in the debugger stopping
+the program and reporting the message.
+
+--------------
+
+The original Pascal version of this function used a ``for`` loop, which
+has a direct equivalent in Dylan, as we see in this version of the
+function:
+
+.. code-block:: dylan
+
+      define method dot-product (x, y)
+        unless (size(x) = size(y))
+          error("dot-product: arrays of different lengths")
+        end unless;
+        let sum = 0;
+        for (i :: <integer> from 0 to size(x) - 1)
+          sum := sum + x[i] * y[i]
+        end for;
+        sum
+      end method dot-product;
+
+We've changed the error check at the beginning of the function from an
+``if`` statement to an ``unless``, which executes its body if the
+condition is false. Sometimes, often with error checks, it is clearer to
+write a conditional with ``unless`` than with an ``if`` that tests the
+opposite condition. Note that there is no ``else`` clause for
+``unless``; if you need to do one thing if something is true and another
+if it is false, use ``if`` or ``case``.
+
+The ``for`` loop in Dylan takes several forms, one of which we see
+above, which is called a *numeric for clause*. The syntax of ``for`` in
+Dylan is similar to the ``while`` statement, except instead of a
+condition inside parentheses, we have a clause that describes the loop.
+A numeric for clause counts from a number to some other. In this case,
+the for-clause counts from zero to one less than the size of the array.
+The syntax of the clause is straightforward:
+
+    ``variable from initial-value to bounding-value``
+
+As in Pascal's ``for`` statement and unlike the ``while`` loop, the
+initial value and the bounding value are evaluated exactly once, before
+the first iteration of the loop.
+
+Unlike the Pascal ``for`` loop, Dylan's ``for`` defines the loop
+variable -- ``i`` in this example -- as part of its job. That is, no
+declaration of ``i`` outside the loop is needed or used. This also means
+that the loop variable can't be used outside the body of the loop. (I
+included a type declaration for ``i`` above, just to show that one could
+be used; typically, it would be omitted.)
+
+--------------
+
+The for loop above is not very typical Dylan code. If written first in
+Dylan, it might look more like this, taking advantage of a few
+constructs that don't correspond directly to ones in Pascal:
+
+.. code-block:: dylan
+
+      define method dot-product (x, y)
+        let sum = 0;
+        for (i from 0 below x.size)
+          sum := sum + x[i] * y[i]
+        finally
+          sum
+        end for
+      end method dot-product;
+
+(We've eliminated the error check at the beginning of the function from
+this and future versions, not because it is unnecessary, but because it
+would stay the same -- there is no need to repeat it.)
+
+We see here a slight variation on numeric iteration. The word ``to`` in
+the iteration clause has been changed to ``below``. While ``to`` means
+all values between the initial value through, and including, the final
+value, ``below`` means all those values from the initial value that are
+less than, but not equal to, the bounding value.
+
+In addition to what we've seen here, numeric iteration clauses can use
+the ``by`` keyword, which introduces an amount to count by, as in
+Pascal. The ``by`` phrase can be omitted, as we've seen, in which case
+the value is incremented by one each time through the loop. Also, we can
+identify the ending condition with ``above``, the opposite of ``below``,
+which means the loop runs while the values are greater than the bound.
+The ending condition can even be omitted, which leaves a (potentially)
+infinite loop -- something other than finishing the numeric iteration
+would have to happen to terminate the loop.
+
+The value specified by ``below`` in the loop is also a new construct,
+``x.size``. This is a Dylan shorthand for calling a function of one
+argument. That is, ``expression.function-name`` is the same thing as
+``function-name(expression)``. So the expression here is exactly
+the same as ``size(x)``, just written somewhat differently. (The
+hecklers in the audience might observe that it isn't much of a
+shorthand: just one fewer character.)
+
+Pascal and C programmers, among others, are used to using the syntax
+``expression.name`` for referring to fields of a compound object
+like a record. It makes sense to wonder why this notation was chosen for
+something else in Dylan, especially when that something else -- calling
+functions -- already had a perfectly reasonable syntax. The reason is
+that calling a function in Dylan is the only way to access fields in
+compound objects; we'll see more of this later.
+
+The last thing to note about this version of the function is that the
+``for`` statement is the last one in the function, so the value returned
+by ``dot-product`` is the value of the ``for``. What value does the loop
+return? Normally, there is no meaningful value to return from a loop, so
+an arbitrary one -- the false value -- was picked in Dylan. But
+sometimes it's useful to return a value from a loop, and that's what the
+``finally`` clause is for. After the ``for`` loop is done, all the
+statements in the ``finally`` clause -- here it's just one expression --
+are evaluated, and the value of the last is returned. One detail worth
+knowing is that the statements after ``finally`` are still part of the
+``for`` statement, so the variable from the numeric iteration clause can
+still be used.
+
+--------------
+
+All our versions of ``dot-product`` so far have worked in basically the
+same way: step through the arrays by counting from 0 to one less than
+the size of the array, and doing something with each element in the
+array. This is all we use the variable ``i`` for, and it's pretty common
+that loop variables are used in this way. Dylan provides a very
+convenient way of doing this kind of iteration, using what's known as a
+*collection iteration clause*:
+
+.. code-block:: dylan
+
+      define method dot-product (x, y)
+        let sum = 0;
+        for (xi in x, yi in y)
+          sum := sum + xi * yi
+        finally
+          sum
+        end for
+      end method dot-product;
+
+Here we've done away with the numeric iteration clause, and replaced it
+with two collection iteration clauses. Note that a ``for`` loop may have
+an arbitrary number of iteration clauses, and when any of them
+completes, the loop is done. The iteration clause *variable* ``in``
+*expression*, where the expression is an array, means execute the loop
+for each element in the array, from first to last, setting the variable
+to each value in succession. Thus the first time the loop executes,
+``xi`` holds the value ``x[0]`` and ``yi`` holds ``y[0]``; the second
+time through, ``xi`` holds ``x[1]`` and ``yi`` holds ``y[1]``; and so
+on.
+
+The use of multiple iteration clauses in a ``for`` is relatively common.
+Note that a single loop can mix numeric and collection iteration clause,
+along with a third form, general iteration, which we'll see later. The
+important thing to realize is that the loop ends when *any* of the
+clauses causes it to end.
+
+Again, we haven't declared types for the parameters ``x`` and ``y`` and
+have just referred to them as arrays. This is inaccurate in two ways.
+The first, and more minor, is that one-dimensional arrays are referred
+to as *vectors* in Dylan. While the code will work on multi-dimensional
+arrays, it doesn't really make mathematical sense except for vectors --
+there is no dot product of an array of two or more dimensions.
+
+The more important reason that describing the arguments to
+``dot-product`` as arrays is wrong is that this function will work for
+other types of arguments as well. Dylan has several different types
+known collectively as *sequences*, all of which share several
+properties: they hold a collection of objects which are numbered from
+zero. Vectors are one kind of sequence; others are strings, linked
+lists, ranges of numbers, and queues. The subscripting notation using
+``[]``, the ``size`` function, and collection iteration clauses -- among
+many other operations -- may be used with all sequences.
+
+Sequences are just one kind of *collection* in Dylan. A collection is a
+kind of object which can hold other objects. The most commonly used
+collection which isn't a sequence is a *table*, which is Dylan's
+built-in version of a hash table. Where sequences use integers starting
+at zero as indexes, tables can use any object.
+
+Collections are used extensively by most Dylan programs. This should not
+be a surprise to people who know Pascal: many complex data structures in
+Pascal programs are collections of other objects, usually built up from
+arrays, linked lists, etc. One major difference is that where Pascal
+only defines the array type, in Dylan there are a variety of existing
+collection types to use. Moreover, there is powerful set of operations
+predefined on collections and sequences; we'll see two of these in our
+next version of ``dot-product``.
+
+Another aspect of collections is that users can define their own
+collection types. Again, this is no surprise. What is different from
+Pascal is that, when programmers follow a few rules when creating a new
+kind of collection, it can be used with any of the predefined functions
+that operate on collections. We'll see more about this in a later
+section.
+
+Turning back to the example at hand, there is one more thing to
+understand about using collection iteration clauses instead of numeric
+iteration and indexing: the performance impact of the choice. When we
+used numeric iteration, to calculate the dot-product we had to evaluate
+``x[i]`` and ``y[i]`` each time through the loop. For vectors this makes
+perfect sense, as indexing into a vector is an efficient operation. But
+if ``x`` is a linked list, for example, finding ``x[i]`` requires
+stepping through the first ``i - 1`` elements of the list, which makes
+evaluating ``x[i]`` inside the loop an expensive operation. In more
+precise terms, it changes the computational complexity of the function
+from *O(n)* for vectors to *O(n^2)* for lists, where *n* is the length
+of the arguments.
+
+On the other hand, collection iteration is designed to be efficient when
+possible. For both linked lists and arrays, iterating through the
+collection takes time proportional to the length of the list, so the
+version of ``dot-product`` which uses collection iteration has *O(n)*
+complexity for both vectors and lists. In general, one should use
+collection iteration when iterating over the elements of a collection
+without concern for what their index values are.
+
+--------------
+
+Now let's take a look at a very different version of ``dot-product``,
+this time using two built-in collection operations, ``reduce`` and
+``map``:
+
+.. code-block:: dylan
+
+      define method dot-product (x, y)
+        local method add(a, b)
+                a + b
+              end method add;
+        local method multiply(m, n)
+                m * n
+              end method mul;
+        let x*y-sequence = map(multiply, x, y);
+        reduce(add, 0, x*y-sequence)
+      end method dot-product;
+
+The thing to note about this function is that there is no explicit
+iteration clause. Instead, the iteration is done by the built-in
+functions.
+
+Let's carefully step through what this function does. First, it defines
+two local functions -- ``add`` and ``mul`` -- which, respectively, add
+and multiply their arguments. It then calls the function ``map``.
+``Map`` is what is known as a *higher-order function*, which means it is
+a function that takes a function as an argument. ``Map`` creates a new
+collection from the results of calling a function on each element of one
+or more existing collections. The first argument to ``map`` is the
+function to use; all the other arguments are collections to draw
+elements from. In this case, we've applied ``map`` to the function
+``multiply`` and the two sequences which were arguments, so it produces
+a sequence that has ``x[0] * y[0]`` as its first element,
+``x[1] * y[1]`` as its second, and so on. (The resulting sequence is
+only as long as the shorter of the original sequences. If one is longer,
+only the elements which have corresponding members in the shorter
+sequence are used. As above, we'll assume that the sequences are of the
+same length.)
+
+The result of map, a sequence of the products of the elements of ``x``
+and ``y`` is then attached to the local variable named ``x*y-sequence``.
+There's nothing special about the use of the asterisk in this name --
+it's just one of the characters which is legal in Dylan as part of a
+name -- but sometimes it is convenient to name a variable with a
+mathematical expression.
+
+Next, we call the function ``reduce``, which is also a higher-order
+function. Where ``map`` applies a function to the elements of one or
+more collections to produce a new collection, ``reduce`` combines the
+elements of a collection with a function to produce a single value.
+``Reduce`` takes three arguments: a function, an initial value, and a
+collection. It keeps track of the result value, which starts off as the
+initial value argument. For each element of the collection, it computes
+the result of the function called with the value of the result so far
+and the current element, and uses that as the next value of the result.
+When every element of the collection has been seen, the value that has
+been computed so far is retuned.
+
+In our call to ``reduce``, the function used for combining values is
+``add``, which sums two numbers, and the initial value is ``0``, which
+is the identity for addition. Therefore, this call to ``reduce``
+produces the sum of the members of a collection. In this case, the
+collection being summed contains the products of the elements of the
+arguments, so the result is the dot product.
+
+However, there is a potential drawback to using this approach for
+implementing ``dot-product``: it might be less efficient than a version
+that directly used a loop. The reason is that memory might have to be
+allocated for the intermediary result ``x*y-sequence``, and allocating
+that memory takes some time, as does freeing it when it is no longer in
+use. (Dylan uses *garbage collection*, also known as *automatic storage
+reclamation*, to free memory that isn't being used anymore, but whether
+the programmer or the system does it, freeing the memory does take some
+time. A full discussion of garbage collection is beyond the scope of
+this essay.) So we potentially have a bigger (more memory) and slower
+(more time) program. A very clever compiler could eliminate this use of
+extra memory, perhaps by inlining the functions and rewriting them
+internally as loops, but programmers concerned with efficiency probably
+shouldn't count on such an optimization unless they know their compiler
+very well.
+
+By the way, there is nothing special about higher-order functions:
+anyone can write them. Here, for example, is a portable version of
+``reduce``, which could be used if it wasn't already part of the
+language:
+
+.. code-block:: dylan
+
+      define method reduce
+          (function :: <function>, initial, collection :: <collection>)
+       => value;
+        let result = initial;
+        for (element in collection)
+          result := function(result, element)
+        finally
+          result
+        end for
+      end method reduce;
+
+This implementation is a direct translation into Dylan of the
+description given above. For once, I've given types for the arguments,
+because that's how the types are specified by the language definition.
+The major difference from other functions we've seen so far is an
+argument, ``function``, is used as a function, inside the ``for`` loop;
+that works just as one might expect it to.
+
+--------------
+
+The previous version of ``dot-product`` used three locally-bound
+identifiers (``add``, ``multiply``, and ``x*y-sequence``) that were only
+used once. As in Pascal, if an expression is used only once, there is no
+need to associate it with a name. Unlike Pascal, though, functions in
+Dylan are expressions, and can be created anonymously, that is, without
+names. So we can rewrite ``dot-product`` as:
+
+.. code-block:: dylan
+
+      define method dot-product (x, y)
+        reduce(method (a, b) a + b end,
+               0, map(method (m, n) m * n end, x, y))
+      end method dot-product;
+
+In this version of ``dot-product``, the function we use as the first
+argument to ``reduce`` is the expression:
+
+.. code-block:: dylan
+
+      method (a, b)
+        a + b
+      end
+
+This expression creates a method -- with exactly the same meaning as the
+``add`` method from our previous version -- but doesn't give it a name.
+Nonetheless, this method can be used anywhere ``add`` could have been.
+Similarly, ``multiply`` has been changed to another anonymous method.
+
+We also eliminated the variable ``x*y-sequence``, substituting the
+``map`` expression for it in the call to ``reduce``. The meaning of the
+function hasn't changed, however, so the potential inefficiency of
+allocating extra memory for the result of ``map`` remains.
+
+The full syntax for an anonymous method is
+
+.. code-block:: dylan
+
+      method (arguments ...) => results ...;
+        body
+      end method
+
+and, as with all other methods, the description of the results and the
+word ``method`` after ``end`` can be omitted. Since it doesn't have a
+name, there is no name to put after the ``end method``.
+
+--------------
+
+These examples of ``map`` and ``reduce`` have been somewhat artificial
+in order to introduce the use of higher-order functions. A version of
+``dot-product`` in Dylan would more likely be written as:
+
+.. code-block:: dylan
+
+      define method dot-product (x, y)
+        reduce(\+, 0, map(\*, x, y))
+      end method dot-product;
+
+In the previous two examples, we created a function which took two
+arguments and added them. The first time it was named ``add``; the
+second, it was anonymous and passed as the first argument to ``reduce``.
+In fact, there is no real need to create such a function, because one
+already exists: it's called ``+``.
+
+Because ``+`` is normally used as an operator in traditional arithmetic
+notation, it is easy to forget that it's a function. In Pascal and C, in
+fact, operators like ``+`` have different rules from functions and can't
+just be used like any other function, but in Dylan they can. To avoid
+syntactic confusion with ``+`` used as an operator, when, for example,
+we refer to the function name in order to pass it as an argument to
+another function we have to precede it with a backslash, as above.
+
+This function has the same result as the previous two, but we have
+avoided introducing the intermediate functions and let ``map`` and
+``reduce`` call ``*`` and ``+`` directly.
+
+This version of ``dot-product`` is very concise and, for a programmer
+used to ``map`` and ``reduce``, easy to read. There are some very common
+idioms in Dylan built around these and other operators. For example,
+there is no built-in function to sum a sequence: ``reduce`` obviates the
+need for it.
+
+The use of higher-order functions is usually associated with the
+*functional* style of programming, which is identified with languages
+such as Standard ML, Haskell, and some dialects of Lisp, notably Scheme.
+In Dylan it is often convenient to use this style for parts of programs
+-- often those dealing with operations on collections, as we've seen --
+and use other styles, such as object-oriented or procedural, in other
+parts. One of the goals for Dylan is to support multiple styles, because
+there is no one single, "right" way to structure a program. The
+functional style is a useful one, and is well supported in Dylan; we'll
+see more of it later.
+
+On the other hand, it is possible to take this approach to extremes and
+write large, complicated expressions with no named intermediate values.
+While some people enjoy writing large blocks of code that way, the
+result is often an unreadable program. APL, another language which makes
+pervasive use of higher-order functions, is often criticized for
+encouraging a "write-only" programming style, with very complex
+expressions. Introducing a few named values with ``let`` or splitting
+one method into several that calculate different parts of a result can
+often turn a large, hard-to-follow expression into something more
+readable and maintainable.
+
+--------------
+
+`Back -- Conditions and Multiple Values: The Quadratic
+Formula <2-quadratic.html>`_
+
+Copyright © 1995 Paul Haahr. All rights reserved.
diff --git a/documentation/website/source/articles/procedural-dylan/index.rst b/documentation/website/source/articles/procedural-dylan/index.rst
new file mode 100644
index 0000000000..cab8842615
--- /dev/null
+++ b/documentation/website/source/articles/procedural-dylan/index.rst
@@ -0,0 +1,31 @@
+:orphan:
+
+Procedural Dylan
+================
+
+or How to write Pascal programs in Dylan
+----------------------------------------
+
+Dylan is promoted as an object-oriented, dynamic language, but it also
+offers a rich set of constructs for programming in other styles. This
+essay explores Dylan from the perspective of a programmer used to
+traditional procedural languages, such as Pascal or C, who may want to
+use the facilities offered by Dylan development environments without
+changing programming style or thinking in a different way. Also, some
+features of Dylan which mesh well with the procedural programming style
+but have no direct analogs in Pascal or C may make an appropriate
+addition to one's bag of tricks.
+
+This essay is intended to be used as a tutorial introduction and not as
+a complete reference work. To avoid bogging down the discussion, much
+has been omitted and some details have been ignored. For more complete
+information, see the `Dylan Reference Manual </books/drm/>`__.
+
+.. toctree::
+   :titlesonly:
+
+   1-distance
+   2-quadratic
+   3-dot-product
+
+Copyright © 1995 Paul Haahr. All rights reserved.
diff --git a/documentation/website/source/building-with-duim b/documentation/website/source/building-with-duim
new file mode 120000
index 0000000000..06eca3c8f9
--- /dev/null
+++ b/documentation/website/source/building-with-duim
@@ -0,0 +1 @@
+../_packages/opendylan/current/src/documentation/building-with-duim
\ No newline at end of file
diff --git a/documentation/website/source/community/gsoc/2012/cilk.rst b/documentation/website/source/community/gsoc/2012/cilk.rst
new file mode 100644
index 0000000000..5629e94cbe
--- /dev/null
+++ b/documentation/website/source/community/gsoc/2012/cilk.rst
@@ -0,0 +1,14 @@
+============
+Dylan / Cilk
+============
+
+The purpose of this project would be to provide a library and compiler
+plugin that transforms Dylan code into a form where it can work with the
+Cilk runtime.
+
+Another approach would be to implement our own form of Cilk rather than
+trying to interoperate with the existing Cilk runtime.
+
+Cilk information:
+
+- https://software.intel.com/content/www/us/en/develop/tools/compilers/c-compilers.html
diff --git a/documentation/website/source/community/gsoc/2012/cocoa.rst b/documentation/website/source/community/gsoc/2012/cocoa.rst
new file mode 100644
index 0000000000..cf7e8083f5
--- /dev/null
+++ b/documentation/website/source/community/gsoc/2012/cocoa.rst
@@ -0,0 +1,21 @@
+=============
+Dylan / Cocoa
+=============
+
+The purpose of this project is to use Apple's *Bridge Support* to assist
+in generating wrappers around the Cocoa libraries. This would include
+the creation of a bridge between Dylan and Objective C using the low
+level C API provided by Objective C's runtime.
+
+Bridge Support documentation:
+
+- `BridgeSupport MacOSForge project page <https://web.archive.org/web/20120607030727/http://bridgesupport.macosforge.org/trac/>`_
+- `BridgeSupport Mac OS X Manual Page <https://web.archive.org/web/20150923043041/https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man5/BridgeSupport.5.html>`_
+
+Interesting prior art:
+
+- `jscocoa BridgeSupport usage <https://web.archive.org/web/20170102104926/https://code.google.com/archive/p/jscocoa/wikis/BridgeSupport.wiki>`_
+- `LuaCocoa <https://playcontrol.net/opensource/LuaCocoa/>`_
+- `Clozure CL Objective C bridge <https://ccl.clozure.com/docs/ccl.html#the-objective-c-bridge>`_
+- `LispWorks Objective C interface <http://www.lispworks.com/documentation/lw61/OBJC/html/objc.htm>`_
+- `A list of a lot of Cocoa Bridges <https://web.archive.org/web/20150627011332/http://cocoadev.com/CocoaBridges>`_
diff --git a/documentation/website/source/community/gsoc/2012/dispatch.rst b/documentation/website/source/community/gsoc/2012/dispatch.rst
new file mode 100644
index 0000000000..140c909fe4
--- /dev/null
+++ b/documentation/website/source/community/gsoc/2012/dispatch.rst
@@ -0,0 +1,16 @@
+=====================
+Dispatch Optimization
+=====================
+
+Since Dylan is dynamically typed and uses multiple dispatch, this has to be fast. This is in most applications the major performance bottleneck (unless annotated with types such that the dispatches are done at compile time).
+
+We've recently updated Dylan to use the C3 algorithm for superclass linearization, which leads to monotonic method orderings.
+
+Eric Kidd already wrote a technical report about the possibility of compressing the dispatch tables, which waits to be implemented. Additionally further research by Yoav Zibin evaluates other optimizations, which need to be evaluated and applied to Dylan.
+
+For this project some algorithmic knowledge is needed. The code will be mainly in the Dylan runtime.
+
+Useful links:
+
+- `Eric Kidds technical report on compression of generic function tables <http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.68.9146&rep=rep1&type=pdf>`_
+- `Yoav Zibin thesis about efficient runtime algorithms <https://yoav-zibin.github.io/homepage/publications/my-thesis.pdf>`_
diff --git a/documentation/website/source/community/gsoc/2012/documentation.rst b/documentation/website/source/community/gsoc/2012/documentation.rst
new file mode 100644
index 0000000000..1f97c1476b
--- /dev/null
+++ b/documentation/website/source/community/gsoc/2012/documentation.rst
@@ -0,0 +1,27 @@
+=========================
+Dylan Documentation Tools
+=========================
+
+The purpose of this project is to improve our documentation tools
+in interesting ways.
+
+Searchable, Browsable API documentation
+=======================================
+
+The purpose of this project is to provide searchable, browsable API
+documentation based on the reference materials. The idea would be to
+extract documentation into JSON by writing an extension to Sphinx, put
+that JSON into something like ElasticSearch and building a web-based
+user interface on top of that.  This information could also be exposed
+via an API for use in an IDE or other editing tools.
+
+Interactive Graphs
+==================
+
+A class hierarchy diagram need not just be a static image.
+
+We have a lot of information encoded in our documentation markup including
+superclasses, related ("see also") items, available operations and 
+example code.  This provides a pretty rich basis for a graphical visualization
+of a library or module.  We could include generated SVG, HTML or JS using
+the Canvas into the documentation to let people interact with this data.
diff --git a/documentation/website/source/community/gsoc/2012/dylint.rst b/documentation/website/source/community/gsoc/2012/dylint.rst
new file mode 100644
index 0000000000..3bf24d3f90
--- /dev/null
+++ b/documentation/website/source/community/gsoc/2012/dylint.rst
@@ -0,0 +1,13 @@
+======
+DyLint
+======
+
+The purpose of this project is to create a framework for doing analysis
+and warnings of Dylan code using compiler plugins that can walk the
+internal compiler datastructures.
+
+This can draw inspiration from:
+
+- `PMD <https://web.archive.org/web/20121222162208/https://pmd.sourceforge.net/>`_
+- `PyLint <https://pypi.org/project/pylint/>`_
+- Clang plugins
diff --git a/documentation/website/source/community/gsoc/2012/frontend-lisp.rst b/documentation/website/source/community/gsoc/2012/frontend-lisp.rst
new file mode 100644
index 0000000000..016dcf3be4
--- /dev/null
+++ b/documentation/website/source/community/gsoc/2012/frontend-lisp.rst
@@ -0,0 +1,17 @@
+=============
+Frontend/LISP
+=============
+
+The purpose of this project would be to write another syntax for Dylan based on the original S-Expression syntax.
+
+The project would include to write (or revive) a S-Expression lexer and parser for Dylan and translating this into the ``dfmc-definitions`` structure by using a macro-expander for Dylan macros.
+
+The change towards the infix syntax was done before the programming language was finalized, thus not all features are present in the prefix syntax. This has to be taken into consideration and adjusted appropriately (by redefining the prefix syntax).
+
+Using this approach both surface syntaxes (apart from macros) can be completely exchanged. Also, the semantics (control/data flow, optimization, type inference, backends) does not have to be touched at all. Every dylan file already has rfc822 headers, one of these is ``Language:``, which values can be ``prefix-dylan`` and ``infix-dylan`` (where the latter is the default).
+
+Some references:
+
+- `Dylan Interim Reference Manual <https://jim.studt.net/dirm/interim-contents.html>`_
+- `Dylan Macros with S-Expressions <https://www.cs.cmu.edu/afs/cs/project/clisp/OldFiles/hackers/wlott/dylan/moon/Dylan-Macros.RTF>`_
+- `S-Expression Syntax <https://github.com/dylan-hackers/historic-dylan-svn/tree/393e3fa2089bce8f02d950b561dee7bb3de7fe02/old/Sources/emulator/lib>`_
diff --git a/documentation/website/source/community/gsoc/2012/gtk.rst b/documentation/website/source/community/gsoc/2012/gtk.rst
new file mode 100644
index 0000000000..d0c4300107
--- /dev/null
+++ b/documentation/website/source/community/gsoc/2012/gtk.rst
@@ -0,0 +1,15 @@
+============
+Dylan / Gtk+
+============
+
+The purpose of this project is to:
+
+- Use the ``.gir`` files from `gobject-introspection`_ to generate Gtk+ bindings.
+- Use the bindings to implement a backend for DUIM that runs on Linux and Mac OS X.
+
+Some code already exists for this:
+
+- https://github.com/dylan-lang/opendylan/tree/master/sources/gtk
+- https://github.com/dylan-lang/opendylan/tree/master/sources/duim/gtk
+
+.. _gobject-introspection: https://wiki.gnome.org/action/show/Projects/GObjectIntrospection?action=show&redirect=GObjectIntrospection
diff --git a/documentation/website/source/community/gsoc/2012/index.rst b/documentation/website/source/community/gsoc/2012/index.rst
new file mode 100644
index 0000000000..c838358b74
--- /dev/null
+++ b/documentation/website/source/community/gsoc/2012/index.rst
@@ -0,0 +1,31 @@
+============================
+Google Summer of Code - 2012
+============================
+
+This page is to help organize our (hopeful) participation in the Google
+Summer of Code, 2012.
+
+Submissions and edits to this content can be done by submitting a pull
+request to the `website repository
+<https://github.com/dylan-lang/website/>`_ or by :doc:`contacting us via
+IRC or the mailing list </community/index>`.
+
+If you are interested in being a mentor, please contact Bruce Mitchener
+via one of the above means.
+
+.. toctree::
+   :titlesonly:
+   
+   dylint
+   javascript
+   tracing
+   documentation
+   cilk
+   numerics
+   speed
+   cocoa
+   gtk
+   staticlink
+   frontend-lisp
+   project_manager
+   dispatch
diff --git a/documentation/website/source/community/gsoc/2012/javascript.rst b/documentation/website/source/community/gsoc/2012/javascript.rst
new file mode 100644
index 0000000000..48fe269dbe
--- /dev/null
+++ b/documentation/website/source/community/gsoc/2012/javascript.rst
@@ -0,0 +1,9 @@
+===========================
+JavaScript Compiler Backend
+===========================
+
+The Open Dylan compiler supports multiple backends, currently supporting
+C, LLVM and the HARP native backend. In the past, it also had partial
+support for the JVM.
+
+This project would be to create a new backend that outputs JavaScript.
\ No newline at end of file
diff --git a/documentation/website/source/community/gsoc/2012/numerics.rst b/documentation/website/source/community/gsoc/2012/numerics.rst
new file mode 100644
index 0000000000..459951a795
--- /dev/null
+++ b/documentation/website/source/community/gsoc/2012/numerics.rst
@@ -0,0 +1,11 @@
+================
+Dylan / Numerics
+================
+
+The purpose of this project is to improve numerical computing performance in Dylan.
+
+It could include:
+
+- BLAS / LAPack integration.
+- SSE code generation.
+- Auto-vectorization.
diff --git a/documentation/website/source/community/gsoc/2012/project_manager.rst b/documentation/website/source/community/gsoc/2012/project_manager.rst
new file mode 100644
index 0000000000..ec56f52bba
--- /dev/null
+++ b/documentation/website/source/community/gsoc/2012/project_manager.rst
@@ -0,0 +1,241 @@
+Rethinking the Project Manager
+******************************
+
+Problem
+=======
+
+The current project manager has a variety of problems that we would
+like to solve.  These include:
+
+* It combines install with build.
+* Similarly, it doesn't distinguish between a library that I'm using
+  and one that I'm developing. Not all dependencies should be treated
+  in the same manner.  While this is seen by some to be an advantage,
+  I don't believe that it is in any larger scale setting with multiple
+  endeavors happening at once.
+* It provides no versioning of libraries.
+* Everything is always built into a shared location. This is pretty
+  confusing for new users.
+* It provides no way of locating, downloading or otherwise managing
+  dependencies. You still have to download everything yourself, set
+  up registries, and get things to work.
+
+Example Application
+===================
+
+Given a software application like Network Night Vision which consists of
+an executable and multiple libraries, this is an ideal demonstration of
+how the new system could work.
+
+Network Night Vision depends on externally provided (and maintained)
+libraries like Monday and the Dylan runtime.
+
+It is also consists of a collection of libraries which are part of the
+application and linked into the final executable.
+
+Current Situation
+-----------------
+
+Currently, there is a registry for Network Night Vision which lists
+all of these libraries, both internal and external, and requires that
+they be on disk in a particular location (relatively).  When building
+NNV, all of these libraries are built and installed into a common build
+directory (``~/Open-Dylan``).  Any changes to any of the sources for
+these libraries results in everything getting appropriately rebuilt.
+This rebuild happens even for a change in the Dylan runtime or the
+Monday libraries even though they are external dependencies and aren't
+being developed as part of NNV.
+
+When talking to the compiler, you give the compiler a single project
+or LID file which is used to automatically get all dependencies, look
+them up in the registry, and build them as needed.
+
+Better World?
+-------------
+
+In a better world, external dependencies would be available from the
+system as a whole.  These external dependencies would have a version
+number or identifier associated with them so that changes in the
+dependency wouldn't require that everything using it be rebuilt or
+updated. The internal (component) libraries would be handled roughly
+as they are now: changes in them would cause rebuilds.
+
+It would be great if one didn't have to manually go and download,
+build, and install external dependencies that didn't exist or if the
+process were at least easier than it is now.
+
+Proposal
+========
+
+Workspaces
+----------
+
+Workspaces are a new concept to Open Dylan and are a layer above the
+project.  (A project corresponds to a single library or executable.)
+
+Taking Network Night Vision as an example, you would have a top level
+``nnv.workspace`` file which contained (among other things) a list of the
+projects that were part of the Network Night Vision application, using
+relative paths from the workspace file:
+
+* ``flow-printer/flow-printer.lid``
+* ...
+* ``gui-sniffer/gui-sniffer.lid``
+* ...
+* ``vector-table/vector-table.lid``
+
+Upon opening this workspace, the projects would also be loaded.
+Libraries referenced from these projects would be resolved by:
+
+#. First, look for a project in the workspace that provides the
+   specified library.
+#. If not found, look to the system-installed libraries.
+#. See `Package Manager`_.
+
+Libraries that are provided by the workspace are treated as they are
+now and changes to them trigger rebuilds.  However, libraries that
+are provided by the system are entirely an external dependency, just
+like system-provided libraries in any other language or environment.
+
+Package Manager
+---------------
+
+The second big piece of this proposal is the creation of a package
+management system for Open Dylan. This is something along the lines of
+what many other programming language communities provide:
+
+* Clojure: `Leiningen <https://github.com/technomancy/leiningen>`_
+* Common Lisp: `QuickLisp <https://www.quicklisp.org/beta/>`_
+* Emacs Lisp: `Marmalade <https://web.archive.org/web/20121103132251/https://marmalade-repo.org/>`_ / `ELPA  <http://tromey.com/elpa/>`_
+* Erlang: `EPM <https://web.archive.org/web/20111205025106/http://jkvor.com/erlang-package-manager>`_
+* haXe: `haxelib <https://haxe.org/manual/haxelib.html>`_
+* Lua: `LuaRocks <https://luarocks.org/>`_
+* NodeJS: `NPM <https://www.npmjs.com/>`_
+* Haskell: `Hackage <http://hackage.haskell.org/>`_
+* Ocaml: `GODI <http://godi.camlcity.org/archive/godi/index.html>`_
+* PHP: `PEAR <https://pear.php.net/>`_
+* Perl: CPAN
+* Python: PIP / CheeseShop / easy_install
+* Racket: `Raco <https://docs.racket-lang.org/raco/index.html>`_
+* Ruby: `RubyGems <https://rubygems.org/>`_
+
+Our package manager would feature a global catalog of packages, the
+ability to download, build and install those packages, and integration
+of these features in the build system and IDE.
+
+Catalog
+~~~~~~~
+
+The catalog is a mapping of library names to metadata about those
+libraries.
+
+This metadata should be able to include:
+
+* Author
+* Version
+* Synopsis
+* Description
+* Keywords / Tags
+* Source repository location
+* Software license
+
+The catalog may be maintained independently of the various libraries
+or it might be the result of a mechanical process which extracts the
+metadata from the workspace and project files of the libraries. There
+are advantages and disadvantages to both, so this should be discussed.
+
+Software Distribution
+~~~~~~~~~~~~~~~~~~~~~
+
+I propose that we initially rely upon Git for retrieving the source code
+for a library.  We can always add additional methods later (HTTP, Mercurial,
+Subversion, etc), but for now, it would be easiest if we could avoid having
+to write our own HTTP interfaces, deal with unzipping and unpacking tarballs
+and all of the other associated details.
+
+Upon locating a package that we wish to install, the package manager
+would look at the metadata that it received from the catalog for the
+Git repository and run a git client to retrieve the source code prior
+to building and installing the package.
+
+User Interface
+~~~~~~~~~~~~~~
+
+The package manager should support at least these operations:
+
+* Search / Apropos. Given some text, find all packages that
+  reference that text. This can have features added over time
+  to search by author, version, etc.
+* Install. Retrieve the
+* Uninstall. This would be nice to have, but is probably going
+  to come later. When installing a package, a manifest of all
+  installed files should be generated. This can then be used
+  to uninstall the package.
+* Bundle. Take an executable with the libraries that it depends
+  upon and put them in a directory structure independent of
+  the typical install location. This is probably mainly required
+  on Mac OS X where we have to deal with ``install_name_tool``
+  and other OS X specific concerns.
+
+Over time, the package metadata should be accessible by a variety
+of means:
+
+* Packages website which allows browsing all metadata as well
+  as perhaps hosting the generated documentation for the package
+  if it is using the standard Sphinx-based structure.
+* Command line tools, including within ``dylan-compiler``.
+* A GUI browser tool within the IDE.
+
+Versioning
+----------
+
+I haven't thought much yet about what will be involved here.
+
+Development Process
+===================
+
+A big (and reasonable) fear is that some of this work is fairly large
+and extensive and that may make it more difficult.  To help mitigate
+this, I propose that we:
+
+* Work iteratively. Small steps that eventually get us somewhere
+  awesome are better than getting nowhere at all.
+* Accept that this isn't ever going to be perfect. But it will surely
+  be better than what we have now.
+* Make technology decisions to simplify things and add more features
+  later.  An example of this is the proposed reliance upon Git via
+  ``run-application()``.
+
+Glossary
+========
+
+Project:
+
+    Each project represents a single target. It contains:
+
+    * A collection of Dylan source files.
+    * A set of dependencies which are expected to be satisfied by the
+      system.
+    * A set of dependencies which are expected to be resolved within
+      the current workspace.
+
+Registry:
+
+    In Open Dylan, the registry provides a way to map from a library
+    name to the associated LID file (with sources) for that library.
+
+Target:
+
+    A target is the final build product that results from a project, be
+    that a library or an executable.
+
+Workspace:
+
+    A workspace is a new concept to Open Dylan.  It is a collection of
+    projects which, together, represent a software project.
+
+    A given project within the workspace can be specified as the default
+    project which is the one which is built first, is the target of a
+    'Run' or 'Debug' command and so on. The user can change the current
+    active project within the workspace so that the subsequent 'Run' or
+    'Debug' commands are directed at the new active project.
diff --git a/documentation/website/source/community/gsoc/2012/speed.rst b/documentation/website/source/community/gsoc/2012/speed.rst
new file mode 100644
index 0000000000..719ab56f2b
--- /dev/null
+++ b/documentation/website/source/community/gsoc/2012/speed.rst
@@ -0,0 +1,13 @@
+=====
+Speed
+=====
+
+The purpose of this project is to implement a number of benchmarks in
+Dylan and provide infrastructure for recording and observing performance
+data over time.
+
+Inspiration (and benchmark ideas) can be borrowed from:
+
+- `pypy speed center <https://speed.pypy.org/>`_
+- `Boinkmarks <https://web.archive.org/web/20120822233940/http://sbcl.boinkor.net/boinkmarks/index>`_
+- `microbench for numerics in CL <https://github.com/nikodemus/microbench>`_
diff --git a/documentation/website/source/community/gsoc/2012/staticlink.rst b/documentation/website/source/community/gsoc/2012/staticlink.rst
new file mode 100644
index 0000000000..a7c5984aed
--- /dev/null
+++ b/documentation/website/source/community/gsoc/2012/staticlink.rst
@@ -0,0 +1,13 @@
+==============
+Static Linking
+==============
+
+The purpose of this project would be to:
+
+- Implement static linking within the compiler toolchain.
+- Optimize sealing information to take advantage of the lack of
+  extensibility.
+
+Some code for this already exists:
+
+- *fill in details*
diff --git a/documentation/website/source/community/gsoc/2012/tracing.rst b/documentation/website/source/community/gsoc/2012/tracing.rst
new file mode 100644
index 0000000000..dcb9c42337
--- /dev/null
+++ b/documentation/website/source/community/gsoc/2012/tracing.rst
@@ -0,0 +1,7 @@
+=======
+Tracing
+=======
+
+The purpose of this project is to integrate with system-level tracing frameworks such as DTrace and SystemTap.
+
+*fill in more details*
diff --git a/documentation/website/source/community/gsoc/index.rst b/documentation/website/source/community/gsoc/index.rst
new file mode 100644
index 0000000000..3676aaad0f
--- /dev/null
+++ b/documentation/website/source/community/gsoc/index.rst
@@ -0,0 +1,8 @@
+:orphan:
+
+Google Summer of Code
+=====================
+
+.. toctree::
+
+   2012/index
diff --git a/documentation/website/source/community/index.rst b/documentation/website/source/community/index.rst
new file mode 100644
index 0000000000..fd24493199
--- /dev/null
+++ b/documentation/website/source/community/index.rst
@@ -0,0 +1,51 @@
+********************************
+Connect with the Dylan Community
+********************************
+
+The Dylan community is quite small and most of our day-to-day activity takes
+place in `the Matrix channels
+<https://app.element.io/#/room/#dylan-language:matrix.org>`_. If you don't have
+a Matrix account you can sign in with GitHub, GitLab, Google, etc. and use any
+Matrix client.
+
+To ask questions about code you can use `play.opendylan.org
+<https://play.opendylan.org>`_ to share an example, or `create a gist on
+GitHub <https://gist.github.com>`_ and paste a link to it.
+
+.. _contribute:
+
+How to Contribute
+  The :doc:`Hacker Guide <../hacker-guide/source/index>` has details on how to
+  contribute to the project.
+
+Report Bugs
+  Bugs may be reported against the `opendylan repository`_ on GitHub. If you know the bug
+  is in a specific library repository you can report it there instead. If unsure, use
+  `opendylan`_.
+
+.. _opendylan:
+.. _opendylan repository: https://github.com/dylan-lang/opendylan/issues
+
+.. _gitter:
+
+.. _mailing-lists:
+
+Mailing List
+  dylan-lang@googlegroups.com, also `browsable on the web
+  <https://groups.google.com/forum/#!forum/dylan-lang>`_, is dedicated to discussion of
+  Dylan.  If you have a question that's more detailed or doesn't required the quick
+  back-and-forth of chat, this is the preferred place for it.
+
+  `comp.lang.dylan
+  <http://groups.google.com/forum/#!forum/comp.lang.dylan>`_ also exists,
+  but dylan-lang@ is the preferred forum.
+
+Dylan on Other Sites
+  - Follow us on `Fosstodon <https://fosstodon.org/@DylanLang>`_!
+  - `Reddit <https://www.reddit.com/r/dylanlang/>`_
+  - `Stack Overflow <https://stackoverflow.com/questions/tagged/dylan>`_
+
+Pick a Project to Work On
+  If you're looking for ideas, maybe you'll find something in the
+  old `Google Summer of Code suggestions <gsoc/index>`_ or on the
+  `opendylan GitHub wiki <https://github.com/dylan-lang/opendylan/wiki>`_.
diff --git a/documentation/website/source/conf.py b/documentation/website/source/conf.py
new file mode 100644
index 0000000000..0cc57979bd
--- /dev/null
+++ b/documentation/website/source/conf.py
@@ -0,0 +1,42 @@
+# These configuration settings are documented here:
+# https://www.sphinx-doc.org/en/master/usage/configuration.html
+
+import os
+import sys
+sys.path.insert(0, os.path.abspath('../_packages/sphinx-extensions/current/src/sphinxcontrib'))
+extensions = [
+    'dylan.domain',
+    'sphinx.ext.graphviz',
+    'sphinx.ext.intersphinx',
+]
+primary_domain = 'dylan'
+
+project = 'Open Dylan'
+copyright = '2011-2023, Dylan Hackers'
+version = '2023.1'
+release = '2023.1'
+show_authors = True
+
+html_theme = 'furo'             # https://pradyunsg.me/furo/customisation/
+html_theme_options = {
+    'sidebar_hide_name': True,
+    'light_logo': 'images/opendylan-light.png',
+    'dark_logo': 'images/opendylan-dark.png',
+
+    # https://pradyunsg.me/furo/customisation/edit-button/
+    'source_repository': 'https://github.com/dylan-lang/website',
+    'source_branch': 'master',
+    'source_directory': 'source/',
+}
+html_theme_path = ['_themes']   # still needed? add furo submodule here?
+
+htmlhelp_basename = 'OpenDylandoc'
+html_title = 'Open Dylan'
+html_static_path = ['_static']
+html_favicon = '_static/favicon.ico'
+
+templates_path = ['_templates']
+
+exclude_patterns = [
+    '**/sphinx_rtd_theme/**',
+]
diff --git a/documentation/website/source/corba-guide b/documentation/website/source/corba-guide
new file mode 120000
index 0000000000..b4da65822e
--- /dev/null
+++ b/documentation/website/source/corba-guide
@@ -0,0 +1 @@
+../_packages/opendylan/current/src/documentation/corba-guide
\ No newline at end of file
diff --git a/documentation/website/source/documentation/cheatsheets/collections.rst b/documentation/website/source/documentation/cheatsheets/collections.rst
new file mode 100644
index 0000000000..4eb519d140
--- /dev/null
+++ b/documentation/website/source/documentation/cheatsheets/collections.rst
@@ -0,0 +1,167 @@
+***********************
+Collections Cheat Sheet
+***********************
+
+Common Collection Types
+=======================
+
++--------------------------+------------------------------------+----------------------------------------+
+| Class                    | Location                           | Description                            |
++==========================+====================================+========================================+
+| :drm:`<array>`           | ``dylan:dylan``                    | Multi-dimensional data, much like a    |
+|                          |                                    | matrix.                                |
++--------------------------+------------------------------------+----------------------------------------+
+| :drm:`<vector>`          | ``dylan:dylan``                    | A one-dimensional array. Vectors       |
+|                          |                                    | provide fast random access.            |
++--------------------------+------------------------------------+----------------------------------------+
+| :drm:`<stretchy-vector>` | ``dylan:dylan``                    | A vector that can have elements        |
+|                          |                                    | directly added and removed without     |
+|                          |                                    | requiring a complete copy.             |
++--------------------------+------------------------------------+----------------------------------------+
+| :drm:`<list>`            | ``dylan:dylan``                    | A linked list.                         |
++--------------------------+------------------------------------+----------------------------------------+
+| :drm:`<deque>`           | ``dylan:dylan``                    | A double-ended queue.                  |
++--------------------------+------------------------------------+----------------------------------------+
+| `\<set>`_                | ``collections:set``                | A set is for efficiently tracking      |
+|                          |                                    | membership.                            |
++--------------------------+------------------------------------+----------------------------------------+
+| `\<bit-set>`_            | ``collections:bit-set``            | A set with bits for members.           |
++--------------------------+------------------------------------+----------------------------------------+
+| `\<bit-vector>`_         | ``collections:bit-vector``         | A vector optimized for storing bit     |
+|                          |                                    | values.                                |
++--------------------------+------------------------------------+----------------------------------------+
+| `\<byte-vector>`_        | ``collections:byte-vector``        | A vector of bytes.                     |
++--------------------------+------------------------------------+----------------------------------------+
+| :drm:`<table>`           | ``dylan:dylan``                    | A mapping between keys and values.     |
++--------------------------+------------------------------------+----------------------------------------+
+| `\<string-table>`_       | ``collections:table-extensions``   | A ``<table>`` with strings for keys.   |
++--------------------------+------------------------------------+----------------------------------------+
+
+.. note::
+
+   Because of the default comparison function for ``<table>``, it is
+   important to use ``<string-table>`` when the keys will be strings.
+
+Mutable vs. Immutable
+=====================
+
+Many operations don't modify the collection passed in. The exception
+is when you use an operation ending in ``!`` on a *stretchy* collection.
+
+For this reason, if you want to modify a collection frequently, be sure
+to pay attention to the type of collection that you're working with.
+
+In many cases, you will need to assign the result of an operation
+back to the source collection:
+
+.. code-block:: dylan
+
+    threads := add(threads, thread);
+
+In cases where you are modifying a collection frequently, you may want
+to consider using a :drm:`<stretchy-vector>` rather than a `<vector>`
+or some other type of collection.
+
+Common Operations
+=================
+
++---------------------+------------------------------+------------------------------------------------------+
+| Class               | Operation                    | Summary                                              |
++=====================+==============================+======================================================+
+| :drm:`<collection>` | :drm:`any?`                  | Returns the first true value obtained by iterating   |
+|                     |                              | over one or more collections.                        |
+|                     +------------------------------+------------------------------------------------------+
+|                     | :drm:`do`                    | Iterates over one or more collections for side       |
+|                     |                              | effect.                                              |
+|                     +------------------------------+------------------------------------------------------+
+|                     | :drm:`empty?`                | Returns true if its argument is empty.               |
+|                     +------------------------------+------------------------------------------------------+
+|                     | :drm:`every?`                | Returns true if a predicate returns true when        |
+|                     |                              | applied to all corresponding elements of a set of    |
+|                     |                              | collections.                                         |
+|                     +------------------------------+------------------------------------------------------+
+|                     | :drm:`fill!`                 | Fills a collection with a specified value.           |
+|                     +------------------------------+------------------------------------------------------+
+|                     | :drm:`find-key`              | Returns the key in a collection such that the        |
+|                     |                              | corresponding collection element satisfies a         |
+|                     |                              | predicate.                                           |
+|                     +------------------------------+------------------------------------------------------+
+|                     | :drm:`key-sequence`          | Returns a sequence containing the keys of its        |
+|                     |                              | collection argument. This is commonly used with      |
+|                     |                              | :drm:`<table>` instances.                            |
+|                     +------------------------------+------------------------------------------------------+
+|                     | :drm:`map`                   | Iterates over one or more collections and collects   |
+|                     |                              | the results in a freshly allocated collection.       |
+|                     |                              | See also :drm:`map-as` and :drm:`map-into`.          |
+|                     +------------------------------+------------------------------------------------------+
+|                     | :drm:`member?`               | Returns true if a collection contains a particular   |
+|                     |                              | value.                                               |
+|                     +------------------------------+------------------------------------------------------+
+|                     | :drm:`reduce`                | Combines the elements of a collection and a seed     |
+|                     |                              | value into a single value by repeatedly applying a   |
+|                     |                              | binary function. See also :drm:`reduce1`.            |
+|                     +------------------------------+------------------------------------------------------+
+|                     | :drm:`replace-elements!`     | Replaces those collection elements that satisfy a    |
+|                     |                              | predicate.                                           |
+|                     +------------------------------+------------------------------------------------------+
+|                     | :drm:`size`                  | Returns the size of its argument.                    |
++---------------------+------------------------------+------------------------------------------------------+
+| :drm:`<sequence>`   | :drm:`add` / :drm:`add!`     | Adds an element to a sequence.                       |
+|                     +------------------------------+------------------------------------------------------+
+|                     | :drm:`add-new` /             | Adds a new element to a sequence.                    |
+|                     | :drm:`add-new!`              |                                                      |
+|                     +------------------------------+------------------------------------------------------+
+|                     | :drm:`choose`                | Returns those elements of a sequence that satisfy a  |
+|                     |                              | predicate. See also :drm:`choose-by`.                |
+|                     +------------------------------+------------------------------------------------------+
+|                     | :drm:`concatenate`           | Returns the concatenation of one or more sequences   |
+|                     |                              | in a sequence of a type determined by the            |
+|                     |                              | :drm:`type-for-copy` of its first argument.          |
+|                     |                              | See also :drm:`concatenate-as`.                      |
+|                     +------------------------------+------------------------------------------------------+
+|                     | :drm:`copy-sequence`         | Returns a freshly allocated copy of some subsequence |
+|                     |                              | of a sequence.                                       |
+|                     +------------------------------+------------------------------------------------------+
+|                     | :drm:`intersection`          | Returns the intersection of two sequences.           |
+|                     +------------------------------+------------------------------------------------------+
+|                     | :drm:`remove` /              | Removes an element from a sequence.                  |
+|                     | :drm:`remove!`               |                                                      |
+|                     +------------------------------+------------------------------------------------------+
+|                     | :drm:`remove-duplicates`     | Returns a sequence without duplicates.               |
+|                     +------------------------------+------------------------------------------------------+
+|                     | :drm:`replace-subsequence!`  | Replaces a portion of a sequence with the elements   |
+|                     |                              | of another sequence.                                 |
+|                     +------------------------------+------------------------------------------------------+
+|                     | :drm:`reverse` /             | Returns a sequence with elements in the reverse      |
+|                     | :drm:`reverse!`              | order of its argument sequence.                      |
+|                     +------------------------------+------------------------------------------------------+
+|                     | :drm:`sort` / :drm:`sort!`   | Returns a sequence containing the elements of its    |
+|                     |                              | argument sequence, sorted.                           |
+|                     +------------------------------+------------------------------------------------------+
+|                     | :drm:`subsequence-position`  | Returns the position where a pattern appears in a    |
+|                     |                              | sequence.                                            |
+|                     +------------------------------+------------------------------------------------------+
+|                     | :drm:`union`                 | Returns the union of two sequences.                  |
++---------------------+------------------------------+------------------------------------------------------+
+| :drm:`<list>`       | :drm:`head`                  | Returns the head of a list.                          |
+|                     +------------------------------+------------------------------------------------------+
+|                     | :drm:`tail`                  | Returns the tail of a list.                          |
++---------------------+------------------------------+------------------------------------------------------+
+| :drm:`<deque>`      | :drm:`push`                  | Adds an element to the front of a deque.             |
+|                     +------------------------------+------------------------------------------------------+
+|                     | :drm:`pop`                   | Removes and returns the first element of a deque.    |
+|                     +------------------------------+------------------------------------------------------+
+|                     | :drm:`push-last`             | Adds an element to the end of a deque.               |
+|                     +------------------------------+------------------------------------------------------+
+|                     | :drm:`pop-last`              | Removes and returns an element from the end of a     |
+|                     |                              | deque.                                               |
++---------------------+------------------------------+------------------------------------------------------+
+| :drm:`<table>`      | :drm:`remove-key!`           | Modifies an explicit key collection so it no longer  |
+|                     |                              | has a particular key.                                |
++---------------------+------------------------------+------------------------------------------------------+
+
+.. _<set>: library-reference/collections/set.html
+.. _<bit-set>: library-reference/collections/bit-set.html
+.. _<bit-vector>: library-reference/collections/bit-vector.html
+.. _<byte-vector>: library-reference/common-dylan/byte-vector.html
+.. _<string-table>: library-reference/collections/table-extensions.html#collections:table-extensions:[string-table]
diff --git a/documentation/website/source/documentation/cheatsheets/conditionals.rst b/documentation/website/source/documentation/cheatsheets/conditionals.rst
new file mode 100644
index 0000000000..2579f979a5
--- /dev/null
+++ b/documentation/website/source/documentation/cheatsheets/conditionals.rst
@@ -0,0 +1,86 @@
+************************
+Conditionals Cheat Sheet
+************************
+
+``if``
+======
+
+:drm:`if` is pretty straightforward:
+
+.. code-block:: dylan
+
+    if (test-expression)
+      // if test-expression is true
+    elseif (other-test)
+      // otherwise, if other-test is true
+    else
+      // If no tests above were true
+    end;
+
+``case``
+========
+
+:drm:`case` tests a series of conditions and executes the body
+of code corresponding to the first condition that is true.
+
+.. code-block:: dylan
+
+    case
+       player1.money <= 0
+         => end-game(player1);
+       player2.money <= 0
+         => end-game(player2);
+       otherwise
+         => move(player1);
+            move(player2);
+    end case;
+
+``select``
+==========
+
+:drm:`select` takes a target object and compares it against
+a series of matches and executes the body of code corresponding
+to the first match found.
+
+.. code-block:: dylan
+
+    select (as-uppercase(char))
+      'D' => collect(number-to-string(argument(char, <number>)));
+      'B' => collect(integer-to-string(argument(char, <integer>), base: 2));
+      'O' => collect(integer-to-string(argument(char, <integer>), base: 8));
+      'X' => collect(integer-to-string(argument(char, <integer>), base: 16));
+      'C' => collect-character(argument(char, <character>));
+      'S' => print-pretty-name(buffer, argument(char, <object>));
+      '=' => print-unique-name(buffer, argument(char, <object>));
+      '%' => collect-character('%');
+      otherwise =>
+        error("Invalid format directive '%s' in \"%s\"",
+              char, format-string);
+    end;
+
+``unless``
+==========
+
+:drm:`unless` executes a body of code when the test expression
+is false:
+
+.. code-block:: dylan
+
+    unless (test-expression)
+      // do work, if test-expression is false
+    end;
+
+``when``
+========
+
+This is just a shorthand for :drm:`if` when there's no ``elseif`` or
+``else`` branches.
+
+.. code-block:: dylan
+
+    when (test-expression)
+      // if test-expression is true
+    end;
+
+:macro:`when` isn't defined in the DRM. To use it, you must :drm:`use
+<define_module>` the ``dylan-extensions`` module from the ``dylan`` library.
diff --git a/documentation/website/source/documentation/cheatsheets/index.rst b/documentation/website/source/documentation/cheatsheets/index.rst
new file mode 100644
index 0000000000..9a17a13304
--- /dev/null
+++ b/documentation/website/source/documentation/cheatsheets/index.rst
@@ -0,0 +1,12 @@
+************
+Cheat Sheets
+************
+
+.. toctree::
+   :maxdepth: 1
+
+   Syntax <syntax>
+   Conditionals <conditionals>
+   Collections <collections>
+   Iteration <iteration>
+   For Schemers <scheme>
diff --git a/documentation/website/source/documentation/cheatsheets/iteration.rst b/documentation/website/source/documentation/cheatsheets/iteration.rst
new file mode 100644
index 0000000000..8de9549854
--- /dev/null
+++ b/documentation/website/source/documentation/cheatsheets/iteration.rst
@@ -0,0 +1,197 @@
+*********************
+Iteration Cheat Sheet
+*********************
+
+
+Simple iteration with ``while`` and ``until``
+=============================================
+
+.. code-block:: dylan
+
+    while (condition?)
+      // do something while the test condition? is true
+    end;
+
+.. code-block:: dylan
+
+    until (condition?)
+      // do something until the test condition? is true
+    end;
+
+Read more in the DRM: :drm:`while` and :drm:`until`.
+
+The ``for`` loop
+================
+
+The :drm:`for` loop can be used in many different ways. We demonstrate some of the
+most commonly used features here:
+
+Iterating over a collection
+---------------------------
+
+.. code-block:: dylan
+
+    for (element in collection)
+      // do something with element
+    end;
+
+Iterating over a range
+----------------------
+
+.. code-block:: dylan
+
+    for (count from 0 below num)
+      // do work
+      // count ranges from 0 to the integer below num
+    end;
+
+    for (column from 1 to 3)
+      // do work
+      // count ranges from 1 to 3, inclusive.
+    end;
+
+    // Changing the stepping and going in reverse
+    for (index from stop - 1 to start by -1)
+      // index will start at 'stop - 1' and end at the
+      // value of 'start', decrementing by 1 with each
+      // iteration of the loop.
+    end;
+
+Iterating over a table
+----------------------
+
+The easiest way to iterate over a table is to use an extension to
+the standard :drm:`for` loop that Open Dylan supports:
+
+.. code-block:: dylan
+
+    for (value keyed-by key in table)
+      // do work
+    end;
+
+If you want to directly access the keys of the table, you can use
+:drm:`key-sequence`:
+
+.. code-block:: dylan
+
+    for (key in table.key-sequence)
+      // do work
+    end;
+
+Breaking out of a loop
+======================
+
+Breaking out of a loop is just like any other non-local exit in Dylan.
+Combine any loop with a :drm:`block` expression:
+
+.. code-block:: dylan
+
+   let result = block (exit-block)
+                  while (~done())
+                    if (got-error?())
+                      exit-block(1);
+                    end;
+                  end;
+                  2
+                end;
+
+In the example, if the loop ends naturally because ``done()`` returns true,
+then the result is ``2`` because the :drm:`while` exits naturally and ``2``
+is the last expression in the block. If ``got-error?`` returns true, the
+result is ``1`` because that was the value passed to ``exit-block``.
+
+Collection Functions
+====================
+
+When working with a collection, some additional operations are available
+that remove the need for explicit iteration over the collection.
+
+In all of these, the function passed in can be any of:
+
+* An existing function.
+* An escaped operator name (``\+`` for example).
+* A locally defined method.
+* The result of a method that returns a function such as :drm:`curry`
+  :drm:`rcurry` or other `functional operations <https://opendylan.org/books/drm/Functional_Operations>`_.
+
+``do``
+------
+
+:drm:`do` iterates over one or more collections, performing side effects:
+
+.. code-block:: dylan
+
+    do(method (x)
+         format-out("%s\n", x)
+       end,
+       #[1, 2, 3])
+
+``map``, ``map-as``, ``map-into``
+---------------------------------
+
+:drm:`map` iterates over one or more collections, applying a function and
+returns the results in a new collection.  :drm:`map-as` and :drm:`map-into`
+allow control over the way that the results are returned.
+
+.. code-block:: dylan
+
+    let type-bindings = map(generate-type-binding, all-var-specs);
+
+.. code-block:: dylan
+
+    let strings = map(curry(as, <string>), names);
+
+.. code-block:: dylan
+
+    let c-direct-superclasses = map-as(<list>, convert, direct-superclasses(c));
+
+Read more in the DRM: :drm:`map`, :drm:`map-as`, :drm:`map-into`.
+
+``reduce``, ``reduce1``
+-----------------------
+
+:drm:`reduce` combines the elements of a collection and a seed value into
+a single value by repeatedly applying a binary function.
+
+:drm:`reduce1` is similar to :drm:`reduce`, except that the first value of
+the collection is used as the seed value.
+
+.. code-block:: dylan
+
+    reduce(\*, 1, dimensions(x))
+
+.. code-block:: dylan
+
+    reduce1(\+, #(1, 2, 3, 4, 5))
+
+``reduce`` is often combined with ``map`` operations:
+
+.. code-block:: dylan
+
+    reduce(\+, 0, map(size, qqs))
+
+Iteration with Tail Recursion
+=============================
+
+The ``iterate`` macro in the ``common-dylan`` library is another powerful way to do
+iteration. It relies on the fact that Dylan implementations are required to optimize
+tail recursion.
+
+.. code-block:: dylan
+
+   let x = 7;
+   let factorial = iterate loop (n = x, total = 1)
+                     if (n < 2)
+                       total
+                     else
+                       loop(n - 1, n * total)   // tail call = iteration
+                     end
+                   end;
+
+Here ``iterate`` creates a local method, ``loop``, with two parameters ``n`` and
+``total`` which calls itself recursively until ``n < 2`` is true and then it returns the
+value of ``total``. It then calls the method with the parameter default values, ``x`` and
+``1``.
+
+You could of course do the same thing with a local method yourself but the ``iterate``
+macro makes it more concise.
diff --git a/documentation/website/source/documentation/cheatsheets/scheme.rst b/documentation/website/source/documentation/cheatsheets/scheme.rst
new file mode 100644
index 0000000000..d4b2b471d8
--- /dev/null
+++ b/documentation/website/source/documentation/cheatsheets/scheme.rst
@@ -0,0 +1,604 @@
+A Dylan Primer for Scheme Programmers
+=====================================
+
+This document was originally authored by Jonathan Sobel.
+
+Almost everything you already do in Scheme has a direct counterpart in Dylan.
+
+.. note:: If one column contains N/A, then that language has no corresponding
+          direct way to express what is in the other column.
+
+Literals
+--------
+
++------------------------+-----------------------+
+| Scheme                 | Dylan                 |
++========================+=======================+
+| .. code-block:: scheme | .. code-block:: dylan |
+|                        |                       |
+|    #t                  |    #t                 |
++------------------------+-----------------------+
+| .. code-block:: scheme | .. code-block:: dylan |
+|                        |                       |
+|    #f                  |    #f                 |
++------------------------+-----------------------+
+| .. code-block:: scheme | .. code-block:: dylan |
+|                        |                       |
+|    23                  |    23                 |
++------------------------+-----------------------+
+| .. code-block:: scheme | .. code-block:: dylan |
+|                        |                       |
+|    #b1011              |    #b1011             |
++------------------------+-----------------------+
+| .. code-block:: scheme | .. code-block:: dylan |
+|                        |                       |
+|    #o644               |    #o644              |
++------------------------+-----------------------+
+| .. code-block:: scheme | .. code-block:: dylan |
+|                        |                       |
+|    #x2A5F              |    #x2A5F             |
++------------------------+-----------------------+
+| .. code-block:: scheme | N/A                   |
+|                        |                       |
+|    -4/5                |                       |
++------------------------+-----------------------+
+| .. code-block:: scheme | .. code-block:: dylan |
+|                        |                       |
+|    6.02E23             |    6.02E23            |
++------------------------+-----------------------+
+| .. code-block:: scheme | .. code-block:: dylan |
+|                        |                       |
+|    #\a                 |    'a'                |
++------------------------+-----------------------+
+| .. code-block:: scheme | .. code-block:: dylan |
+|                        |                       |
+|    #\newline           |    '\n'               |
++------------------------+-----------------------+
+| .. code-block:: scheme | .. code-block:: dylan |
+|                        |                       |
+|    "Hello"             |    "Hello"            |
++------------------------+-----------------------+
+| .. code-block:: scheme | .. code-block:: dylan |
+|                        |                       |
+|    "Hello\n"           |    "Hello\n"          |
++------------------------+-----------------------+
+| .. code-block:: scheme | .. code-block:: dylan |
+|                        |                       |
+|    'apple              |    #"apple"           |
+|                        |    apple:             |
++------------------------+-----------------------+
+| .. code-block:: scheme | .. code-block:: dylan |
+|                        |                       |
+|    '|two words|        |    #"two words"       |
++------------------------+-----------------------+
+| .. code-block:: scheme | .. code-block:: dylan |
+|                        |                       |
+|    '(1 #\a dog)        |    #(1, 'a', #"dog")  |
++------------------------+-----------------------+
+| .. code-block:: scheme | .. code-block:: dylan |
+|                        |                       |
+|    #(5 10 15)          |   #[5, 10, 15]        |
++------------------------+-----------------------+
+| .. code-block:: scheme | N/A                   |
+|                        |                       |
+|    `(1 2 ,x ,@y)       |                       |
++------------------------+-----------------------+
+
+Syntax
+------
+
+Note that, in Dylan, any words after an ``end`` (e.g.
+``end method``) are optional.
+
++----------------------------------+---------------------------------------+
+| Scheme                           | Dylan                                 |
++==================================+=======================================+
+| .. code-block:: scheme           | .. code-block:: dylan                 |
+|                                  |                                       |
+|    (define var exp)              |    define variable var = exp          |
+|                                  |    define constant var = exp          |
++----------------------------------+---------------------------------------+
+| .. code-block:: scheme           | .. code-block:: dylan                 |
+|                                  |                                       |
+|    (f x y z)                     |    f(x, y, z)                         |
++----------------------------------+---------------------------------------+
+| .. code-block:: scheme           | .. code-block:: dylan                 |
+|                                  |                                       |
+|    (begin 1 2 3)                 |    begin 1; 2; 3; end                 |
+|                                  |    begin 1; 2; 3 end                  |
++----------------------------------+---------------------------------------+
+| .. code-block:: scheme           | N/A                                   |
+|                                  |                                       |
+|    (quote datum)                 |                                       |
++----------------------------------+---------------------------------------+
+| .. code-block:: scheme           | .. code-block:: dylan                 |
+|                                  |                                       |
+|    (lambda (x y . z)             |    method (x, y, #rest z)             |
+|      (say "hello")               |      say("hello");                    |
+|      (f x y z))                  |      f(x, y, z);                      |
+|                                  |    end method                         |
++----------------------------------+---------------------------------------+
+| .. code-block:: scheme           | .. code-block:: dylan                 |
+|                                  |                                       |
+|    (begin                        |    begin                              |
+|      (define x 5)                |      let x = 5;                       |
+|      body)                       |      body                             |
+|                                  |    end                                |
++----------------------------------+---------------------------------------+
+| .. code-block:: scheme           | .. code-block:: dylan                 |
+|                                  |                                       |
+|    (define-values (x y) exp)     |    let (x, y) = exp;                  |
++----------------------------------+---------------------------------------+
+| .. code-block:: scheme           | .. code-block:: dylan                 |
+|                                  |                                       |
+|    (let-values (((x y)           |    let (x, y) = values(5, 6);         |
+|                  (values 5 6)))  |    f(x, y)                            |
+|      (f x y))                    |                                       |
++----------------------------------+---------------------------------------+
+| .. code-block:: scheme           | .. code-block:: dylan                 |
+|                                  |                                       |
+|    (letrec ((f (lambda (x)       |    local method f (x)                 |
+|            f-body)               |      f-body                           |
+|       )                          |    end method f,                      |
+|       (g (lambda (y z)           |    method g (y, z)                    |
+|            g-body)               |      g-body                           |
+|       ))                         |    end method g;                      |
+|      body)                       |    body                               |
++----------------------------------+---------------------------------------+
+| .. code-block:: scheme           | .. code-block:: dylan                 |
+|                                  |                                       |
+|    (if test                      |    if (test)                          |
+|        (begin then1              |      then1;                           |
+|         then2)                   |      then2;                           |
+|        (begin else1              |    else                               |
+|         else2)                   |      else1;                           |
+|    )                             |      else2;                           |
+|                                  |    end if                             |
++----------------------------------+---------------------------------------+
+| .. code-block:: scheme           | .. code-block:: dylan                 |
+|                                  |                                       |
+|    (set! var value)              |    var := value                       |
++----------------------------------+---------------------------------------+
+| .. code-block:: scheme           | .. code-block:: dylan                 |
+|                                  |                                       |
+|    (and a b c)                   |    a & b & c                          |
++----------------------------------+---------------------------------------+
+| .. code-block:: scheme           | .. code-block:: dylan                 |
+|                                  |                                       |
+|    (or a b c)                    |    a | b | c                          |
++----------------------------------+---------------------------------------+
+| .. code-block:: scheme           | .. code-block:: dylan                 |
+|                                  |                                       |
+|    (cond                         |    case                               |
+|     (test1 result1)              |      test1 => result1;                |
+|     (test2 result2)              |      test2 => result2;                |
+|     (else result)                |      otherwise => result;             |
+|    )                             |    end case                           |
++----------------------------------+---------------------------------------+
+| .. code-block:: scheme           | .. code-block:: dylan                 |
+|                                  |                                       |
+|    (case exp                     |    select (exp)                       |
+|     ((a 2) result1)              |      #"a", 2 => result1;              |
+|     (('a' 'b') result2)          |      'a', 'b' => result2;             |
+|     (else result)                |      otherwise => result;             |
+|    )                             |    end select                         |
++----------------------------------+---------------------------------------+
+| N/A                              | .. code-block:: dylan                 |
+|                                  |                                       |
+|                                  |    select (exp by comparison-func)    |
+|                                  |      f(x) => result1;                 |
+|                                  |      g(y), h(z) => result2;           |
+|                                  |      otherwise => result;             |
+|                                  |    end select                         |
++----------------------------------+---------------------------------------+
+| .. code-block:: scheme           | .. code-block:: dylan                 |
+|                                  |                                       |
+|    (do ((var1 init1 step1)       |    for (var1 = init1 then step1,      |
+|         (var2 init2 step2))      |         var2 = init2 then step2,      |
+|        (test result)             |         until: test)                  |
+|      body                        |      body                             |
+|    )                             |    finally result                     |
+|                                  |    end for                            |
++----------------------------------+---------------------------------------+
+
+Predefined functions
+--------------------
+
+These are organized based on the "Standard Procedures" section of R4RS.
+
++--------------------------------+-----------------------------------------------+
+| **Boolean functions**                                                          |
++--------------------------------+-----------------------------------------------+
+| .. code-block:: scheme         | .. code-block:: dylan                         |
+|                                |                                               |
+|    (not obj)                   |    ~ obj                                      |
+|                                |    ~obj                                       |
++--------------------------------+-----------------------------------------------+
+| .. code-block:: scheme         | .. code-block:: dylan                         |
+|                                |                                               |
+|    (boolean? obj)              |    instance?(obj, <boolean>)                  |
++--------------------------------+-----------------------------------------------+
+| **Equivalence predicates**                                                     |
++--------------------------------+-----------------------------------------------+
+| .. code-block:: scheme         | .. code-block:: dylan                         |
+|                                |                                               |
+|    (eqv? x y)                  |    x == y                                     |
++--------------------------------+-----------------------------------------------+
+| .. code-block:: scheme         | N/A                                           |
+|                                |                                               |
+|    (eq? x y)                   |                                               |
++--------------------------------+-----------------------------------------------+
+| .. code-block:: scheme         | .. code-block:: dylan                         |
+|                                |                                               |
+|    (equal? x y)                |    x = y                                      |
++--------------------------------+-----------------------------------------------+
+| **Pairs and Lists**                                                            |
++--------------------------------+-----------------------------------------------+
+| .. code-block:: scheme         | .. code-block:: dylan                         |
+|                                |                                               |
+|    (pair? obj)                 |    instance?(obj, <pair>)                     |
++--------------------------------+-----------------------------------------------+
+| .. code-block:: scheme         | .. code-block:: dylan                         |
+|                                |                                               |
+|    (cons x y)                  |    pair(x, y)                                 |
++--------------------------------+-----------------------------------------------+
+| .. code-block:: scheme         | .. code-block:: dylan                         |
+|                                |                                               |
+|    (car ls)                    |    head(ls)                                   |
++--------------------------------+-----------------------------------------------+
+| .. code-block:: scheme         | .. code-block:: dylan                         |
+|                                |                                               |
+|    (cdr ls)                    |    tail(ls)                                   |
++--------------------------------+-----------------------------------------------+
+| .. code-block:: scheme         | .. code-block:: dylan                         |
+|                                |                                               |
+|    (set-car! ls val)           |    head-setter(val, ls)                       |
+|                                |    head(ls) := val                            |
++--------------------------------+-----------------------------------------------+
+| .. code-block:: scheme         | .. code-block:: dylan                         |
+|                                |                                               |
+|    (set-cdr! ls val)           |    tail-setter(val, ls)                       |
+|                                |    tail(ls) := val                            |
++--------------------------------+-----------------------------------------------+
+| .. code-block:: scheme         | .. code-block:: dylan                         |
+|                                |                                               |
+|    (cadadr ls)                 |    N/A                                        |
++--------------------------------+-----------------------------------------------+
+| .. code-block:: scheme         | .. code-block:: dylan                         |
+|                                |                                               |
+|    (null? obj)                 |    instance?(obj, <empty-list>)               |
+|                                |    obj = #()                                  |
+|                                |    empty?(ls) // most common                  |
++--------------------------------+-----------------------------------------------+
+| .. code-block:: scheme         | .. code-block:: dylan                         |
+|                                |                                               |
+|    (list? obj)                 |    instance?(obj, <list>)                     |
++--------------------------------+-----------------------------------------------+
+| .. code-block:: scheme         | .. code-block:: dylan                         |
+|                                |                                               |
+|    (list x y z)                |    list(x, y, z)                              |
++--------------------------------+-----------------------------------------------+
+| .. code-block:: scheme         | .. code-block:: dylan                         |
+|                                |                                               |
+|    (length ls)                 |    size(ls)                                   |
++--------------------------------+-----------------------------------------------+
+| .. code-block:: scheme         | .. code-block:: dylan                         |
+|                                |                                               |
+|    (append ls1 ls2 ls3)        |    concatenate(ls1, ls2, ls3)                 |
++--------------------------------+-----------------------------------------------+
+| .. code-block:: scheme         | .. code-block:: dylan                         |
+|                                |                                               |
+|    (reverse ls)                |    reverse(ls)                                |
++--------------------------------+-----------------------------------------------+
+| .. code-block:: scheme         | .. code-block:: dylan                         |
+|                                |                                               |
+|    (list-ref ls n)             |    element(ls, n)                             |
++--------------------------------+-----------------------------------------------+
+| .. code-block:: scheme         | .. code-block:: dylan                         |
+|                                |                                               |
+|    (member obj ls)             |    member?(obj, ls)                           |
++--------------------------------+-----------------------------------------------+
+| .. code-block:: scheme         | .. code-block:: dylan                         |
+|                                |                                               |
+|    (memv obj ls)               |    member?(obj, ls, test: \==)                |
++--------------------------------+-----------------------------------------------+
+| **Symbols**                                                                    |
++--------------------------------+-----------------------------------------------+
+| .. code-block:: scheme         | .. code-block:: dylan                         |
+|                                |                                               |
+|    (symbol? obj)               |    instance?(obj, <symbol>)                   |
++--------------------------------+-----------------------------------------------+
+| .. code-block:: scheme         | .. code-block:: dylan                         |
+|                                |                                               |
+|    (symbol->string sym)        |    as(<string>, sym)                          |
++--------------------------------+-----------------------------------------------+
+| .. code-block:: scheme         | .. code-block:: dylan                         |
+|                                |                                               |
+|    (string->symbol str)        |    as(<symbol>, str)                          |
++--------------------------------+-----------------------------------------------+
+| **Numerical operations**                                                       |
++--------------------------------+-----------------------------------------------+
+| .. code-block:: scheme         | .. code-block:: dylan                         |
+|                                |                                               |
+|    (number? obj)               |    instance?(obj, <number>)                   |
++--------------------------------+-----------------------------------------------+
+| .. code-block:: scheme         | .. code-block:: dylan                         |
+|                                |                                               |
+|    (complex? obj)              |    instance?(obj, <complex>)                  |
++--------------------------------+-----------------------------------------------+
+| .. code-block:: scheme         | .. code-block:: dylan                         |
+|                                |                                               |
+|    (real? obj)                 |    instance?(obj, <real>)                     |
++--------------------------------+-----------------------------------------------+
+| .. code-block:: scheme         | .. code-block:: dylan                         |
+|                                |                                               |
+|    (rational? obj)             |    instance?(obj, <rational>)                 |
++--------------------------------+-----------------------------------------------+
+| .. code-block:: scheme         | .. code-block:: dylan                         |
+|                                |                                               |
+|    (integer? obj)              |    instance?(obj, <integer>)                  |
+|                                |    integral?(num)                             |
++--------------------------------+-----------------------------------------------+
+| .. code-block:: scheme         | .. code-block:: dylan                         |
+|                                |                                               |
+|    (= n1 n2)                   |    n1 = n2                                    |
+|                                |    n1 == n2                                   |
++--------------------------------+-----------------------------------------------+
+| .. code-block:: scheme         | .. code-block:: dylan                         |
+|                                |                                               |
+|    (< n1 n2)                   |    n1 < n2                                    |
++--------------------------------+-----------------------------------------------+
+| .. code-block:: scheme         | .. code-block:: dylan                         |
+|                                |                                               |
+|    (> n1 n2)                   |    n1 > n2                                    |
++--------------------------------+-----------------------------------------------+
+| .. code-block:: scheme         | .. code-block:: dylan                         |
+|                                |                                               |
+|    (<= n1 n2)                  |    n1 <= n2                                   |
++--------------------------------+-----------------------------------------------+
+| .. code-block:: scheme         | .. code-block:: dylan                         |
+|                                |                                               |
+|    (>= n1 n2)                  |    n1 >= n2                                   |
++--------------------------------+-----------------------------------------------+
+| .. code-block:: scheme         | .. code-block:: dylan                         |
+|                                |                                               |
+|    (zero? n)                   |    zero?(n)                                   |
++--------------------------------+-----------------------------------------------+
+| .. code-block:: scheme         | .. code-block:: dylan                         |
+|                                |                                               |
+|    (positive? n)               |    positive?(n)                               |
++--------------------------------+-----------------------------------------------+
+| .. code-block:: scheme         | .. code-block:: dylan                         |
+|                                |                                               |
+|    (negative? n)               |    negative?(n)                               |
++--------------------------------+-----------------------------------------------+
+| .. code-block:: scheme         | .. code-block:: dylan                         |
+|                                |                                               |
+|    (odd? i)                    |    odd?(i)                                    |
++--------------------------------+-----------------------------------------------+
+| .. code-block:: scheme         | .. code-block:: dylan                         |
+|                                |                                               |
+|    (even? i)                   |    even?(i)                                   |
++--------------------------------+-----------------------------------------------+
+| .. code-block:: scheme         | .. code-block:: dylan                         |
+|                                |                                               |
+|    (+ 1 2 3)                   |    1 + 2 + 3                                  |
++--------------------------------+-----------------------------------------------+
+| .. code-block:: scheme         | .. code-block:: dylan                         |
+|                                |                                               |
+|    (* 1 2 3)                   |    1 * 2 * 3                                  |
++--------------------------------+-----------------------------------------------+
+| .. code-block:: scheme         | .. code-block:: dylan                         |
+|                                |                                               |
+|    (- 5 3)                     |    5 - 3                                      |
++--------------------------------+-----------------------------------------------+
+| .. code-block:: scheme         | .. code-block:: dylan                         |
+|                                |                                               |
+|    (/ 2.3 1.7)                 |    2.3 / 1.7                                  |
++--------------------------------+-----------------------------------------------+
+| .. code-block:: scheme         | .. code-block:: dylan                         |
+|                                |                                               |
+|    (- x)                       |    - x                                        |
+|                                |    -x                                         |
++--------------------------------+-----------------------------------------------+
+| .. code-block:: scheme         | .. code-block:: dylan                         |
+|                                |                                               |
+|    (expt 2 16)                 |    2 ^ 16                                     |
++--------------------------------+-----------------------------------------------+
+| *[Most of the standard Scheme numeric functions (e.g.  max, remainder) are     |
+| defined similarly in Dylan.  No need  to list them all here.]*                 |
++--------------------------------+-----------------------------------------------+
+| **Characters**                                                                 |
++--------------------------------+-----------------------------------------------+
+| .. code-block:: scheme         | .. code-block:: dylan                         |
+|                                |                                               |
+|    (char? obj)                 |    instance?(obj, <character>)                |
++--------------------------------+-----------------------------------------------+
+| .. code-block:: scheme         | .. code-block:: dylan                         |
+|                                |                                               |
+|    (char=? char1 char2)        |    char1 = char2                              |
+|                                |    char1 == char2                             |
++--------------------------------+-----------------------------------------------+
+| .. code-block:: scheme         | .. code-block:: dylan                         |
+|                                |                                               |
+|    (char<? char1 char2)        |    char1 < char2                              |
++--------------------------------+-----------------------------------------------+
+| .. code-block:: scheme         | .. code-block:: dylan                         |
+|                                |                                               |
+|    (char>? char1 char2)        |    char1 > char2                              |
++--------------------------------+-----------------------------------------------+
+| .. code-block:: scheme         | .. code-block:: dylan                         |
+|                                |                                               |
+|    (char<=? char1 char2)       |    char1 <= char2                             |
++--------------------------------+-----------------------------------------------+
+| .. code-block:: scheme         | .. code-block:: dylan                         |
+|                                |                                               |
+|    (char>=? char1 char2)       |    char1 >= char2                             |
++--------------------------------+-----------------------------------------------+
+| .. code-block:: scheme         | .. code-block:: dylan                         |
+|                                |                                               |
+|    (char->integer char)        |    as(<integer>, char)                        |
++--------------------------------+-----------------------------------------------+
+| .. code-block:: scheme         | .. code-block:: dylan                         |
+|                                |                                               |
+|    (integer->char n)           |    as(<character>, n)                         |
++--------------------------------+-----------------------------------------------+
+| .. code-block:: scheme         | .. code-block:: dylan                         |
+|                                |                                               |
+|    (char-upcase char)          |    as-uppercase(char)                         |
++--------------------------------+-----------------------------------------------+
+| .. code-block:: scheme         | .. code-block:: dylan                         |
+|                                |                                               |
+|    (char-downcase char)        |    as-lowercase(char)                         |
++--------------------------------+-----------------------------------------------+
+| **Strings**                                                                    |
++--------------------------------+-----------------------------------------------+
+| .. code-block:: scheme         | .. code-block:: dylan                         |
+|                                |                                               |
+|    (string? obj)               |    instance?(obj, <string>)                   |
++--------------------------------+-----------------------------------------------+
+| .. code-block:: scheme         | .. code-block:: dylan                         |
+|                                |                                               |
+|    (make-string k char)        |    make(<string>, size: k, fill: char)        |
++--------------------------------+-----------------------------------------------+
+| .. code-block:: scheme         | N/A                                           |
+|                                |                                               |
+|    (string char ...)           |                                               |
++--------------------------------+-----------------------------------------------+
+| .. code-block:: scheme         | .. code-block:: dylan                         |
+|                                |                                               |
+|    (string-length str)         |    size(str)                                  |
++--------------------------------+-----------------------------------------------+
+| .. code-block:: scheme         | .. code-block:: dylan                         |
+|                                |                                               |
+|    (string-ref str k)          |    element(str, k)                            |
+|                                |    str[k]                                     |
++--------------------------------+-----------------------------------------------+
+| .. code-block:: scheme         | .. code-block:: dylan                         |
+|                                |                                               |
+|    (string-set! str k char)    |    element-setter(char, str, k)               |
+|                                |    str[k] := char                             |
++--------------------------------+-----------------------------------------------+
+| .. code-block:: scheme         | .. code-block:: dylan                         |
+|                                |                                               |
+|    (string=? str1 str2)        |    str1 = str2                                |
++--------------------------------+-----------------------------------------------+
+| .. code-block:: scheme         | .. code-block:: dylan                         |
+|                                |                                               |
+|    (string<? str1 str2)        |    str1 < str2                                |
++--------------------------------+-----------------------------------------------+
+| .. code-block:: scheme         | .. code-block:: dylan                         |
+|                                |                                               |
+|    (substring str start end)   |    copy-sequence(str, start: start, end: end) |
++--------------------------------+-----------------------------------------------+
+| .. code-block:: scheme         | .. code-block:: dylan                         |
+|                                |                                               |
+|    (string-append str1 str2)   |    concatenate(str1, str2)                    |
++--------------------------------+-----------------------------------------------+
+| .. code-block:: scheme         | .. code-block:: dylan                         |
+|                                |                                               |
+|    (string->list str)          |    as(<list>, str)                            |
++--------------------------------+-----------------------------------------------+
+| .. code-block:: scheme         | .. code-block:: dylan                         |
+|                                |                                               |
+|    (list->string chars)        |    as(<string>, chars)                        |
++--------------------------------+-----------------------------------------------+
+| .. code-block:: scheme         | .. code-block:: dylan                         |
+|                                |                                               |
+|    (string-copy str)           |    shallow-copy(str)                          |
+|                                |    copy-sequence(str)                         |
++--------------------------------+-----------------------------------------------+
+| .. code-block:: scheme         | .. code-block:: dylan                         |
+|                                |                                               |
+|    (string-fill! str char)     |    fill!(str, char)                           |
++--------------------------------+-----------------------------------------------+
+| **Vectors**                                                                    |
++--------------------------------+-----------------------------------------------+
+| .. code-block:: scheme         | .. code-block:: dylan                         |
+|                                |                                               |
+|    (vector? obj)               |    instance?(obj, <vector>)                   |
++--------------------------------+-----------------------------------------------+
+| .. code-block:: scheme         | .. code-block:: dylan                         |
+|                                |                                               |
+|    (make-vector k fill)        |    make(<vector>, size: k, fill: fill)        |
++--------------------------------+-----------------------------------------------+
+| .. code-block:: scheme         | .. code-block:: dylan                         |
+|                                |                                               |
+|    (vector obj ...)            |    vector(obj, ...);                          |
++--------------------------------+-----------------------------------------------+
+| .. code-block:: scheme         | .. code-block:: dylan                         |
+|                                |                                               |
+|    (vector-length vec)         |    size(vec)                                  |
++--------------------------------+-----------------------------------------------+
+| .. code-block:: scheme         | .. code-block:: dylan                         |
+|                                |                                               |
+|    (vector-ref vec k)          |    element(vec, k)                            |
+|                                |    vec[k]                                     |
++--------------------------------+-----------------------------------------------+
+| .. code-block:: scheme         | .. code-block:: dylan                         |
+|                                |                                               |
+|    (vector-set! vec k obj)     |    element-setter(obj, vec, k)                |
+|                                |    vec[k] := obj                              |
++--------------------------------+-----------------------------------------------+
+| .. code-block:: scheme         | .. code-block:: dylan                         |
+|                                |                                               |
+|    (vector->list vec)          |    as(<list>, vec)                            |
++--------------------------------+-----------------------------------------------+
+| .. code-block:: scheme         | .. code-block:: dylan                         |
+|                                |                                               |
+|    (list->vector list)         |    as(<vector>, list)                         |
++--------------------------------+-----------------------------------------------+
+| .. code-block:: scheme         | .. code-block:: dylan                         |
+|                                |                                               |
+|    (vector-fill! vec obj)      |    fill!(vec, obj)                            |
++--------------------------------+-----------------------------------------------+
+| **Control Features**                                                           |
++--------------------------------+-----------------------------------------------+
+| .. code-block:: scheme         | .. code-block:: dylan                         |
+|                                |                                               |
+|    (procedure? obj)            |    instance?(obj, <function>)                 |
++--------------------------------+-----------------------------------------------+
+| .. code-block:: scheme         | .. code-block:: dylan                         |
+|                                |                                               |
+|    (apply proc arg1 arg2 args) |    apply(proc, arg1, arg2, args)              |
++--------------------------------+-----------------------------------------------+
+| .. code-block:: scheme         | .. code-block:: dylan                         |
+|                                |                                               |
+|    (map proc list1 list2 ...)  |    map(proc, list1, list2, ...)               |
++--------------------------------+-----------------------------------------------+
+| .. code-block:: scheme         | .. code-block:: dylan                         |
+|                                |                                               |
+|    (vector-map proc            |    map(proc, vec1, vec2, ...)                 |
+|                vec1 vec2 ...)  |                                               |
++--------------------------------+-----------------------------------------------+
+| .. code-block:: scheme         | .. code-block:: dylan                         |
+|                                |                                               |
+|    (string-map                 |    map(proc, string1, string2)                |
+|       string1 string2 ...)     |                                               |
++--------------------------------+-----------------------------------------------+
+| .. code-block:: scheme         | .. code-block:: dylan                         |
+|                                |                                               |
+|    (for-each proc list1 list2) |    do(proc, list1, list2)                     |
++--------------------------------+-----------------------------------------------+
+| **Continuations**                                                              |
+|                                                                                |
+| Continuations have indefinite extent in Scheme but have dynamic extent in      |
+| Dylan. Also, whereas ``call/cc`` is a function, Dylan uses special syntax      |
+| to grab a continuation.                                                        |
++--------------------------------+-----------------------------------------------+
+| .. code-block:: scheme         | .. code-block:: dylan                         |
+|                                |                                               |
+|    (call/cc                    |    block (k)                                  |
+|      (lambda (k)               |      body                                     |
+|        body))                  |    end block                                  |
++--------------------------------+-----------------------------------------------+
+| .. code-block:: scheme         | .. code-block:: dylan                         |
+|                                |                                               |
+|    (call/cc                    |    block (k)                                  |
+|      (lambda (k)               |      body                                     |
+|        (dynamic-wind           |    cleanup                                    |
+|          (lambda () #f)        |      cleanup-stuff                            |
+|          (lambda () body)      |    end block                                  |
+|          (lambda ()            |                                               |
+|             cleanup-stuff))))  |                                               |
++--------------------------------+-----------------------------------------------+
diff --git a/documentation/website/source/documentation/cheatsheets/syntax.rst b/documentation/website/source/documentation/cheatsheets/syntax.rst
new file mode 100644
index 0000000000..a4d9b6140c
--- /dev/null
+++ b/documentation/website/source/documentation/cheatsheets/syntax.rst
@@ -0,0 +1,205 @@
+******************
+Syntax Cheat Sheet
+******************
+
+.. TODO: add a note about `end` words
+
+Literals
+========
+
++----------------+----------------------------------------+---------------------------+
+| Type           | Dylan Syntax                           | Learn More...             |
++================+========================================+===========================+
+| Booleans       | .. code-block:: dylan                  | * :drm:`<boolean>`        |
+|                |                                        |                           |
+|                |  #t // true                            |                           |
+|                |  #f // false                           |                           |
++----------------+----------------------------------------+---------------------------+
+| Numbers        | .. code-block:: dylan                  | * :drm:`Numbers` (syntax) |
+|                |                                        | * :drm:`<number>`         |
+|                |  42       // A decimal integer         |                           |
+|                |  #b101010 // A binary integer          |                           |
+|                |  #o52     // An octal integer          |                           |
+|                |  #x2A     // A hexadecimal integer     |                           |
+|                |  -42.5    // A floating point number   |                           |
+|                |  6.02E23  // A floating point number   |                           |
++----------------+----------------------------------------+---------------------------+
+| Strings        | .. code-block:: dylan                  |                           |
+|                |                                        | * :drm:`<string>`         |
+|                |  'a'       // A character              | * :drm:`<character>`      |
+|                |  "Hello"   // A simple string          |                           |
+|                |  "Hello\n" // An escape sequence       |                           |
++----------------+----------------------------------------+---------------------------+
+| Symbols        | .. code-block:: dylan                  | * :drm:`<symbol>`         |
+|                |                                        |                           |
+|                |  #"hello"  // A symbol                 |                           |
+|                |  #"HELLO"  // The same symbol          |                           |
+|                |  hello:    // Again, in keyword syntax |                           |
++----------------+----------------------------------------+---------------------------+
+| Collections    | .. code-block:: dylan                  | * :drm:`<pair>`           |
+|                |                                        | * :drm:`<list>`           |
+|                |  #(1 . "one") // A literal <pair>      | * :drm:`<vector>`         |
+|                |  #(1, 2, 3)   // A literal <list>      |                           |
+|                |  #[1, 2, 3]   // A literal <vector>    |                           |
++----------------+----------------------------------------+---------------------------+
+
+Naming Conventions
+==================
+
+These are *conventions* only; they have no semantic value to the compiler.
+
++-------------+-------------------------+--------------------------+
+| Classes     | Class names begin / end | .. code-block:: dylan    |
+|             | with angle brackets     |                          |
+|             | (``<`` and ``>``).      |  <float>                 |
+|             |                         |  <stretchy-vector>       |
++-------------+-------------------------+--------------------------+
+| Constants   | Constants begin with    | .. code-block:: dylan    |
+|             | ``$``.                  |                          |
+|             |                         |  $word-size              |
+|             |                         |  $tag-bits               |
++-------------+-------------------------+--------------------------+
+| Module      | Module variable names   | .. code-block:: dylan    |
+| Variables   | begin / end with ``*``. |                          |
+|             |                         |  *news*                  |
+|             | This does not apply to  |  *command-dispatcher*    |
+|             | local variables that    |                          |
+|             | have been declared with |                          |
+|             | ``let``.                |                          |
++-------------+-------------------------+--------------------------+
+| Predicate   | Predicate functions     | .. code-block:: dylan    |
+| Functions   | return #t or #f.  They  |                          |
+|             | end in ``?``.           |  even?                   |
+|             |                         |  instance?               |
++-------------+-------------------------+--------------------------+
+| Getters &   | Getters read a value    | .. code-block:: dylan    |
+| Setters     | while setters write a   |                          |
+|             | value.  Setter functions|  window.size := 3        |
+|             | end in ``-setter``.     |  size-setter(3, window)  |
+|             | The compiler uses this  |                          |
+|             | convention to find the  |                          |
+|             | function to call for    |                          |
+|             | ``:=``.                 |                          |
++-------------+-------------------------+--------------------------+
+
+Operators
+=========
+
++--------------------+---------------------------------------+--------------------------+
+| Class              | Dylan Syntax                          | Learn More...            |
++====================+=======================================+==========================+
+| Equality &         | .. code-block:: dylan                 | * :drm:`<`               |
+| Comparison         |                                       | * :drm:`>`               |
+|                    |   a < b    // a less than b?          | * :drm:`=`               |
+|                    |   a > b    // a greater than b?       | * :drm:`~=`              |
+|                    |   a = b    // a equal to b?           | * :drm:`==`              |
+|                    |   a ~= b   // a not equal b           | * :drm:`~==`             |
+|                    |   a == b   // a identical to b        |                          |
+|                    |   a ~== b  // a not identical to b    |                          |
+|                    |  ~a        // logical negation        |                          |
++--------------------+---------------------------------------+--------------------------+
+| Arithmetic         | .. code-block:: dylan                 | * :drm:`+`               |
+|                    |                                       | * :drm:`*`               |
+|                    |  a + b        // add a and b          | * :drm:`-`               |
+|                    |  a * b        // mulitply a and b     | * :drm:`/`               |
+|                    |  a - b        // subtract b from a    | * :drm:`modulo`          |
+|                    |  a / b        // divide a by b        | * :drm:`negative`        |
+|                    |  modulo(a, b) // modulus of a by b    |                          |
+|                    |  negative(a)  // negative of a        |                          |
++--------------------+---------------------------------------+--------------------------+
+| :drm:`Collections` | .. code-block:: dylan                 | * :drm:`<collection>`    |
+|                    |                                       |                          |
+|                    |  c[k]       // elem. k of col. c      | * :drm:`element`         |
+|                    |  c[k] := x  // set elem. k of col. c  | * :drm:`element-setter`  |
+|                    |  c.empty?   // is c empty?            | * :drm:`empty?`          |
+|                    |  c.size     // how big is c?          | * :drm:`size`            |
++--------------------+---------------------------------------+--------------------------+
+| Sequence           | .. code-block:: dylan                 | * :drm:`<sequence>`      |
+|                    |                                       |                          |
+|                    |  add(c, x)    // add x to copy of c   | * :drm:`add`             |
+|                    |  remove(c, x) // rem x from copy of c | * :drm:`remove`          |
+|                    |  sort(c)      // copy of c, sorted    | * :drm:`sort`            |
+|                    |  reverse(c)   // copy of c, reversed  | * :drm:`reverse`         |
++--------------------+---------------------------------------+--------------------------+
+| Bitwise &          | .. code-block:: dylan                 |                          |
+| Logical            |                                       |                          |
+|                    |  a | b        // Boolean OR           |                          |
+|                    |  a & b        // Boolean AND          |                          |
+|                    |  logior(a, b) // Bitwise inclusive OR |                          |
+|                    |  logxor(a, b) // Bitwise exclusive OR |                          |
+|                    |  logand(a, b) // Bitwise AND          |                          |
+|                    |  lognot(a, b) // Bitwise NOT          |                          |
+|                    |  ash(a, b)    // Shift left: a << b   |                          |
+|                    |  ash(a, -b)   // Shift right: a >> b  |                          |
++--------------------+---------------------------------------+--------------------------+
+
+
+String Formatting
+=================
+
+Example: ``format(stream, "%s:%d", host, port)``
+
++-------------+------------------+-----------------------+
+| Directive   | Argument Type    | Description           |
++=============+==================+=======================+
+| %d          | <integer>        | decimal number        |
++-------------+------------------+-----------------------+
+| %b          | <integer>        | binary number         |
++-------------+------------------+-----------------------+
+| %o          | <integer>        | octal number          |
++-------------+------------------+-----------------------+
+| %x          | <integer>        | hexadecimal number    |
++-------------+------------------+-----------------------+
+| %c          | <character>      | character, no quotes  |
++-------------+------------------+-----------------------+
+| %s          | <object>         | "pretty" format       |
++-------------+------------------+-----------------------+
+| %=          | <object>         | "unique" format       |
++-------------+------------------+-----------------------+
+| %%          | None             | literal %             |
++-------------+------------------+-----------------------+
+
+
+Parameter Lists
+===============
+
+This table shows what is required/allowed in method parameter lists,
+depending on what is specified in the generic function's parameter
+list.
+
++-----------------------------------+-------------------------------------------------------+
+| Generic function's parameter list | Methods' parameter lists                              |
+|                                   +-----------+---------------+---------------+-----------+
+|                                   | ``#key``  | ``#key a, b`` | ``#all-keys`` | ``#rest`` |
++===================================+===========+===============+===============+===========+
+| ``(x)``                           | Forbidden | Forbidden     | Forbidden     | Forbidden |
++-----------------------------------+-----------+---------------+---------------+-----------+
+| ``(x, #key)``                     | Required  | Allowed       | Allowed       | Allowed   |
++-----------------------------------+-----------+---------------+---------------+-----------+
+| ``(x, #key a, b)``                | Required  | Required      | Allowed       | Allowed   |
++-----------------------------------+-----------+---------------+---------------+-----------+
+| ``(x, #key, #all-keys)``          | Required  | Allowed       | Automatic     | Allowed   |
++-----------------------------------+-----------+---------------+---------------+-----------+
+| ``(x, #key a, b, #all-keys)``     | Required  | Required      | Automatic     | Allowed   |
++-----------------------------------+-----------+---------------+---------------+-----------+
+| ``(x, #rest r)``                  | Forbidden | Forbidden     | Forbidden     | Required  |
++-----------------------------------+-----------+---------------+---------------+-----------+
+
+This table shows the different kinds of parameter lists that a method can have,
+what the ``r`` variable contains for each, and which keywords are permitted by
+each.
+
+======================================  =================  =========================  ======================
+Method's parameter list                 Contents of ``r``  Permits ``a:`` and ``b:``  Permits other keywords
+======================================  =================  =========================  ======================
+``(x)``                                 —                  No                         No            
+``(x, #key)``                           —                  If next method permits     If next method permits
+``(x, #key a, b)``                      —                  Yes                        If next method permits
+``(x, #key, #all-keys)``                —                  Yes                        Yes           
+``(x, #key a, b, #all-keys)``           —                  Yes                        Yes           
+``(x, #rest r)``                        Extra arguments    No                         No            
+``(x, #rest r, #key)``                  Keywords/values    If next method permits     If next method permits
+``(x, #rest r, #key a, b)``             Keywords/values    Yes                        If next method permits
+``(x, #rest r, #key, #all-keys)``       Keywords/values    Yes                        Yes           
+``(x, #rest r, #key a, b, #all-keys)``  Keywords/values    Yes                        Yes           
+======================================  =================  =========================  ======================
diff --git a/documentation/website/source/documentation/index.rst b/documentation/website/source/documentation/index.rst
new file mode 100644
index 0000000000..fcc7c89b72
--- /dev/null
+++ b/documentation/website/source/documentation/index.rst
@@ -0,0 +1,170 @@
+*************
+Documentation
+*************
+
+Learn Dylan
+===========
+
+:doc:`../about/index`
+    A quick overview of the language with examples of major features.
+
+:doc:`../intro-dylan/source/index`
+    This tutorial is written primarily for those with solid programming
+    experience in C++ or another object-oriented, static language. It
+    provides a gentler introduction to Dylan than does the `Dylan Reference
+    Manual`_ (DRM).
+
+`Dylan Programming Guide`_ [`pdf <https://opendylan.org/books/dpg/DylanProgramming.pdf>`__] [`epub <https://opendylan.org/books/dpg/DylanProgramming.epub>`__]
+    A book length Dylan tutorial.
+
+:doc:`../getting-started-cli/source/index`
+    Describes development using the Open Dylan command line tools
+    and editor integration (like emacs). This is mainly for
+    Linux, FreeBSD, and macOS users.
+
+:doc:`../getting-started-ide/source/index`
+    Describes Open Dylan's integrated development environment (Windows only).
+
+:doc:`../building-with-duim/source/index`
+    Describes how to use DUIM (Dylan User Interface Manager),
+    the portable window programming toolkit. (Windows only.)
+
+References
+==========
+
+`Dylan Reference Manual`_ (`Errata`_)
+    The official definition of the Dylan language and standard library.
+
+:doc:`../library-reference/source/index`
+    Reference docs for core libraries packaged with Open Dylan.
+
+:doc:`../duim-reference/source/index`
+    Describes the libraries forming DUIM (Dylan User Interface Manager),
+    the portable window programming toolkit. It complements
+    Building Applications Using DUIM. (Currently Windows only.)
+
+:doc:`../corba-guide/source/index`
+    A tutorial and reference for CORBA interoperability using the Open
+    Dylan ORB.
+
+Articles
+========
+
+:doc:`../articles/macro-system` by Dustin Voss.
+    This article holds hard-won knowledge about how the Dylan macro system works
+    and how to work around some of the gotchas that may catch a macro writer.
+
+:doc:`../articles/procedural-dylan/index` by Paul Haahr.
+    This essay explores Dylan from the perspective of a programmer used to
+    traditional procedural languages, such as Pascal or C.
+
+:doc:`../package/http/server/quickstart/index`
+    A quick introduction to web development in Dylan.
+
+:doc:`../news/2011/12/12/dswank` by Hannes Mehnert.
+    An exciting look at using DIME and emacs for Dylan development.
+    DIME is for Dylan what `SLIME <https://common-lisp.net/project/slime/>`_
+    is for Common Lisp.
+
+:doc:`../articles/beyond-java`
+    A discussion of some of the advantages Dylan provides over Java, based on
+    Jason Trenouth's experience writing a CORBA IDL compiler in both Java and
+    Dylan.  (Written around 2001 and Java now has better handling of numeric
+    boxing/unboxing and, arguably, some other improvements.)
+
+Publications
+============
+
+See the `publications page <publications.html>`_ for a full list. Below are a
+few highlighted publications.
+
+**LLVM Code Generation for Open Dylan** (by Peter Housel at ELS 2020 `pdf <https://zenodo.org/record/3742567/files/els2020-opendylan.pdf?download=1>`__ `bib <../_static/documentation/housel_peter_s_2020_3742567.bib>`__ `slides <https://european-lisp-symposium.org/static/2020/housel-slides.pdf>`__ `video <https://www.youtube.com/watch?v=6dcrXBzw4H4>`__)
+  The Open Dylan compiler, DFMC, was originally designed in the 1990s
+  to compile Dylan language code targeting the 32-bit Intel x86
+  platform, or other platforms via portable C. As platforms have
+  evolved since, this approach has been unable to provide efficient
+  code generation for a broader range of target platforms, or to
+  adequately support tools such as debuggers, profilers, and code
+  coverage analyzers.
+
+  Developing a code generator for Open Dylan that uses the LLVM
+  compiler infrastructure is enabling us to support these goals and
+  modernize our implementation. This work describes the design
+  decisions and engineering trade-offs that have influenced the
+  implementation of the LLVM back-end and its associated run-time
+  support.
+
+  https://doi.org/10.5281/zenodo.3742567
+
+**Extending Dylan's type system for better type inference and error detection** (by Hannes Mehnert at ILC 2010 `pdf <http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.627.5175&rep=rep1&type=pdf>`__ `bib <../_static/documentation/mehnert2010.bib>`__)
+    Whereas dynamic typing enables rapid prototyping and easy
+    experimentation, static typing provides early error detection and
+    better compile time optimization. Gradual typing provides the best
+    of both worlds. This paper shows how to define and implement
+    gradual typing in Dylan, traditionally a dynamically typed
+    language. Dylan poses several special challenges for gradual
+    typing, such as multiple return values, variable-arity methods and
+    generic functions (multiple dispatch).
+
+    In this paper Dylan is extended with function types and parametric
+    polymorphism. We implemented the type system and a
+    unification-based type inference algorithm in the mainstream Dylan
+    compiler. As case study we use the Dylan standard library (roughly
+    32000 lines of code), which witnesses that the implementation
+    generates faster code with fewer errors. Some previously
+    undiscovered errors in the Dylan library were revealed.
+
+    https://dl.acm.org/doi/10.1145/1869643.1869645
+
+**D-Expressions: Lisp Power, Dylan Style** [`pdf <http://people.csail.mit.edu/jrb/Projects/dexprs.pdf>`__] [`bib <../_static/documentation/bachrach1999.bib>`__]
+    This paper aims to demonstrate that it is possible for a language
+    with a rich, conventional syntax to provide Lisp-style macro power
+    and simplicity. We describe a macro system and syntax manipulation
+    toolkit designed for the Dylan programming language that meets,
+    and in some areas exceeds, this standard. The debt to Lisp is
+    great, however, since although Dylan has a conventional algebraic
+    syntax, the approach taken to describe and represent that syntax
+    is distinctly Lisp-like in philosophy.
+
+For Open Dylan Developers
+=========================
+
+.. note:: Notes and materials useful to those working on Open Dylan itself or
+          those who have an interest in the low level details.
+
+:doc:`../hacker-guide/source/index`
+    A work in progress to help out people who are hacking on Open Dylan itself.
+
+:doc:`../style-guide/source/index`
+    Notes and thoughts on how to format your Dylan code. This is the style
+    guide that we aspire to adhere to in the Open Dylan sources.
+
+:doc:`../proposals/index`
+    A series of proposals for improvements to the Open Dylan
+    implementation and related libraries.
+
+:doc:`../release-notes/source/index`
+    Notes on new features and bug fixes in each release of Open Dylan.
+
+
+.. TODO: some of the below links should be relative so they work in a test installation
+   of the website.
+
+.. _Dylan Programming Guide: https://opendylan.org/books/dpg/
+.. _Dylan Reference Manual: https://opendylan.org/books/drm/
+.. _Errata: https://opendylan.org/books/drm/Errata
+
+.. toctree::
+   :hidden:
+
+   News <../news/index>
+   Cheat Sheets <cheatsheets/index>
+   Publications <publications>
+   Intro to Dylan <../intro-dylan/source/index>
+   CORBA Guide <../corba-guide/source/index>
+   DUIM Guide <../building-with-duim/source/index>
+   DUIM Reference <../duim-reference/source/index>
+   Getting Started / IDE <../getting-started-ide/source/index>
+   Release Notes <../release-notes/source/index>
+   Sphinx Extensions <../../sphinx-extensions/documentation/source/index>
+   Style Guide <../style-guide/source/index>
diff --git a/documentation/website/source/documentation/publications.rst b/documentation/website/source/documentation/publications.rst
new file mode 100644
index 0000000000..a3c9724f53
--- /dev/null
+++ b/documentation/website/source/documentation/publications.rst
@@ -0,0 +1,158 @@
+************************
+Publications about Dylan
+************************
+
+**LLVM Code Generation for Open Dylan** (by Peter Housel at ELS 2020 `pdf <https://zenodo.org/record/3742567/files/els2020-opendylan.pdf?download=1>`__ `bib <../_static/documentation/housel_peter_s_2020_3742567.bib>`__ `slides <https://european-lisp-symposium.org/static/2020/housel-slides.pdf>`__ `video <https://www.youtube.com/watch?v=6dcrXBzw4H4>`__)
+  The Open Dylan compiler, DFMC, was originally designed in the 1990s
+  to compile Dylan language code targeting the 32-bit Intel x86
+  platform, or other platforms via portable C. As platforms have
+  evolved since, this approach has been unable to provide efficient
+  code generation for a broader range of target platforms, or to
+  adequately support tools such as debuggers, profilers, and code
+  coverage analyzers.
+
+  Developing a code generator for Open Dylan that uses the LLVM
+  compiler infrastructure is enabling us to support these goals and
+  modernize our implementation. This work describes the design
+  decisions and engineering trade-offs that have influenced the
+  implementation of the LLVM back-end and its associated run-time
+  support.
+
+  https://doi.org/10.5281/zenodo.3742567
+
+**Extending Dylan's type system for better type inference and error detection** (by Hannes Mehnert at ILC 2010 `pdf <http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.627.5175&rep=rep1&type=pdf>`__ `bib <../_static/documentation/mehnert2010.bib>`__)
+    Whereas dynamic typing enables rapid prototyping and easy
+    experimentation, static typing provides early error detection and
+    better compile time optimization. Gradual typing provides the best
+    of both worlds. This paper shows how to define and implement
+    gradual typing in Dylan, traditionally a dynamically typed
+    language. Dylan poses several special challenges for gradual
+    typing, such as multiple return values, variable-arity methods and
+    generic functions (multiple dispatch).
+
+    In this paper Dylan is extended with function types and parametric
+    polymorphism. We implemented the type system and a
+    unification-based type inference algorithm in the mainstream Dylan
+    compiler. As case study we use the Dylan standard library (roughly
+    32000 lines of code), which witnesses that the implementation
+    generates faster code with fewer errors. Some previously
+    undiscovered errors in the Dylan library were revealed.
+
+    https://doi.org/10.1145/1869643.1869645
+
+**Automatically generated type-safe GTK+ binding for Dylan** (by Hannes Mehnert at ILC 2009 `pdf <https://www.researchgate.net/profile/Hannes_Mehnert/publication/255630976_Automatically_generated_type-safe_GTK_binding_for_Dylan/links/558fd23308ae15962d8b5e66/Automatically-generated-type-safe-GTK-binding-for-Dylan.pdf>`__ `bib <../_static/documentation/mehnert2009.bib>`__)
+    We present an automated way to get language bindings for GTK+ for
+    Dylan, an object-oriented functional programming language related
+    to Lisp. Dylan supports multiple inheritance, polymorphism,
+    multiple dispatch, keyword arguments, pattern-based syntax
+    extension macros, and many other features. The generated binding
+    is type-safe, no up- and downcasts are needed.
+
+
+**A domain-specific language for manipulation of binary data in Dylan** (by Hannes Mehnert and Andreas Bogk at ILC 2007 `pdf <https://www.researchgate.net/profile/Hannes_Mehnert/publication/242091072_A_domain-specific_language_for_manipulation_of_binary_data_in_Dylan/links/558fd23308ae15962d8b5e68/A-domain-specific-language-for-manipulation-of-binary-data-in-Dylan.pdf>`__ `bib <../_static/documentation/mehnert2007.bib>`__)
+    We present a domain specific language for manipulation of binary
+    data, or structured byte sequences, as they appear in everyday
+    applications such as networking or graphics file manipulation. Our
+    DSL is implemented as an extension of the Dylan language, making
+    use of the macro facility. Dylan macros, unlike Common Lisp
+    macros, are implemented as pattern matches and substitutions on
+    the parse tree, and we will show the strengths and limits of this
+    approach for the given problem.
+
+    https://doi.org/10.1145/1622123.1622148
+
+**Secure Networking** (by Andreas Bogk and Hannes Mehnert at 23rd Chaos Communication Congress `pdf <https://www.researchgate.net/profile/Hannes_Mehnert/publication/228910362_Secure_networking/links/558fefe308aed6ec4bf64b82/Secure-networking.pdf>`__)
+    We noticed a lack of a decent secure framework for handling
+    network packets, we have designed and implemented major parts of a
+    TCP/IP stack in the high level programming language “Dylan”,
+    focusing on security, performance and code reuse. This paper
+    describes the `binary-data
+    <https://github.com/dylan-lang/binary-data>`__ library, as well as
+    `network night vision
+    <https://github.com/dylan-hackers/network-night-vision>`__.
+
+**Efficient Compression of Generic Function Dispatch Tables** (by Eric Kidd  - Technical Report Dartmouth College 2001 `pdf <https://digitalcommons.dartmouth.edu/cgi/viewcontent.cgi?article=1018&context=senior_theses>`__ `bib <../_static/documentation/kidd2001.bib>`__)
+    A generic function is similar to an overloaded operator, but
+    provides a way to select an appropriate behavior at run-time
+    instead of compile-time. Dujardin and colleagues have proposed an
+    algorithm for building and compressing generic function dispatch
+    tables.
+
+    We present several modifications to their algorithm, including an
+    improvement to Pseudo-Closest-Poles and two new algorithms for
+    compressing pole tables. The two new compression algorithms are
+    simple and fast, and one produces smaller output than the
+    original.
+
+    https://dl.acm.org/doi/book/10.5555/867862
+
+**Partial Dispatch: Optimizing Dynamically-Dispatched Multimethod Calls with Compile-Time Types and Runtime Feedback** (by Jonathan Bachrach and Glenn Burke - Technical Report 2000 `pdf <http://people.csail.mit.edu/jrb/Projects/pd.pdf>`__ `bib <../_static/documentation/bachrach2000.bib>`__)
+    We presented an approach to gaining back complete class hierarchy
+    information by delaying the construction of dispatch caches until
+    the whole class hierarchy is available at run- time. Run-time
+    call-site caches can then be constructed as specialized decision
+    trees built from disjointness and concrete- subtype operations on
+    actual arguments combined with compile-time inferred types
+    injected into the run-time. Unnecessary decision steps can be
+    avoided and often run-time dispatch can be completely
+    eliminated. We consider this to be a nice half-way house between
+    full static compilation and dynamic compilation which mitigates
+    the runtime expense of separately compiled components while
+    satisfying our implementation constraints of code shareable
+    components, multi-threaded runtime, incremental development, “pay
+    as you go philosophy”, and interoperability with standard tools.
+
+**D-Expressions: Lisp Power, Dylan Style** (by Jonathan Bachrach and Keith Playford - Technical Report 1999 `pdf <http://people.csail.mit.edu/jrb/Projects/dexprs.pdf>`__ `bib <../_static/documentation/bachrach1999.bib>`__)
+    This paper aims to demonstrate that it is possible for a language
+    with a rich, conventional syntax to provide Lisp-style macro power
+    and simplicity. We describe a macro system and syntax manipulation
+    toolkit designed for the Dylan programming language that meets,
+    and in some areas exceeds, this standard. The debt to Lisp is
+    great, however, since although Dylan has a conventional algebraic
+    syntax, the approach taken to describe and represent that syntax
+    is distinctly Lisp-like in philosophy.
+
+**Modern languages and Microsoft's component object model** (by David N. Gray, John Hotchkiss, Seth Laforge, Andrew Shalit and Toby Weinberg - Communications of the ACM May 1998 `bib <../_static/documentation/gray1998.bib>`__)
+    As the computer industry's reliance on component software increases,
+    it becomes increasingly difficult to integrate complex component
+    systems. Modern development environments take a variety of approaches
+    to simplifying this programming problem. This article describes how
+    three programming language implementations provide access to Microsoft's
+    Component Object Model (COM), and how they attempt to reduce the
+    complexity of writing and using COM objects.
+
+    https://doi.org/10.1145/274946.274957
+
+**A Monotonic Superclass Linearization for Dylan** (by Kim Barrett and Bob Cassels and Paul Haahr and David A. Moon and Keith Playford and P. Tucker Withington at OOPSLA 1996 `PDF <../_static/c3-linearization.pdf>`__ `bib <../_static/documentation/barrett1996.bib>`__)
+    Object-oriented languages with multiple inheritance and automatic
+    conflict resolution typically use a linearization of superclasses
+    to determine which version of a property to inherit when several
+    superclasses provide definitions. Recent work has defined several
+    desirable characteristics for linearizations, the most important
+    being monotonicity, which prohibits inherited properties from
+    skipping over direct superclasses. Combined with Dylan's sealing
+    mechanism, a monotonic linearization enables some compile-time
+    method selection that would otherwise be impossible in the absence
+    of a closed-world assumption.The Dylan linearization is monotonic,
+    easily described, strictly observes local precedence order, and
+    produces the same ordering as CLOS when that is monotonic. We
+    present an implementation based on merging and a survey of class
+    heterarchies from several large programs, analyzing where commonly
+    used linearizations differ.
+
+    https://doi.org/10.1145/236337.236343
+
+**Discovering the way programmers think about new programming environments** (by Joseph Dumas and Paige Parsons - Communications of the ACM June 1995 `bib <../_static/documentation/dumas1995.bib>`__)
+    An interesting usability study of a prototype development
+    environment for the Dylan programming language is presented
+    here. This study's purpose is to determine just how close the
+    prototype is to developers. New approaches to source code
+    organization and to the relationship between the environment and
+    the application being developed are introduced. An asessment of
+    how effectively the prototype conveys these innovations to Dylan
+    developers is also given, followed by some proposed improvements.
+
+    https://doi.org/10.1145/203241.203253
+
+`Bibliography in bibtex format <../_static/documentation/publications.bib>`_
+
diff --git a/documentation/website/source/download/index.rst b/documentation/website/source/download/index.rst
new file mode 100644
index 0000000000..0de9190943
--- /dev/null
+++ b/documentation/website/source/download/index.rst
@@ -0,0 +1,82 @@
+******************
+Install Open Dylan
+******************
+
+The current version is **Open Dylan 2023.1**.
+
+Unix Platforms
+==============
+
+➟ `Download binaries from GitHub <https://github.com/dylan-lang/opendylan/releases/tag/v2023.1.0>`_
+
+Note that Unix versions only have a command-line compiler and not the full IDE that is
+available on Windows, although there is some integration with VS Code and Emacs.
+
+All required dependencies (llvm, libgc, libunwind) are included; just unpack
+the tarball and add the ``bin`` directory to your ``PATH``::
+
+  $ export PATH=/path/to/opendylan/bin:$PATH
+
+You may wish to ``sudo apt install lldb-15``, for debugging.
+
+
+Windows
+=======
+
+Open Dylan for Windows is currently a 32-bit application that runs under the WOW64 x86
+emulator on Windows 10 64-bit machines.
+
+➟ `Download binaries from GitHub <https://github.com/dylan-lang/opendylan/releases/tag/v2023.1.0>`_
+
+For installation, double-click on the installer, and follow instructions.  You
+need to have either the PellesC linker or the linker of VC++ 6.0, 7.0 or the
+current .NET platform SDK installed. `PellesC 8.00
+<https://web.archive.org/web/20191224014825/https://www.pellesc.de/index.php?page=download&lang=en&version=8.00>`_ is the
+best option.  (Note that PellesC 9.00 does not work.)
+
+Your environment variables must be set such that the external build system
+(linker, resource compiler, etc.) can be found.  For example, for Pelles C set
+these environment variables in the System control panel (assuming installation
+in ``C:\Program Files\PellesC``)::
+
+  INCLUDE=C:\Program Files\PellesC\include;C:\Program Files\PellesC\include\win
+  LIB=C:\Program Files\PellesC\lib;C:\Program Files\PellesC\lib\win
+  PATH=C:\Program Files\PellesC\bin;...more...
+
+You may instead start a Pelles C interactive shell and run
+``C:\Program Files\Open Dylan\bin\win32-environment.exe``, but this
+won't help if you want to run Open Dylan via the Start menu.
+
+
+Installing Older Versions
+=========================
+
+Older builds can be found `on GitHub
+<https://github.com/dylan-lang/opendylan/releases>`_ or in the `download
+directories <../downloads/opendylan/>`_.
+
+For the 2020.1 or newer releases just untar the downloaded file and add the
+``bin`` directory to your :envvar:`PATH`.  Optionally, ``sudo apt install
+lldb`` for debugging.
+
+For 2019.1 and earlier releases:
+
+* All Unix platforms must have the Boehm GC and ``libunwind`` installed.
+  For example, ``apt-get install libgc-dev libunwind-dev`` on Ubuntu.
+
+* The README file inside the tarball describes installation and basic
+  usage. The easiest way is extracting the tarball in /opt.
+
+* The Linux and FreeBSD platforms should have gcc installed, in order to allow
+  linking.
+
+* On Arch Linux you may use the following recipe instead::
+
+    git clone https://aur.archlinux.org/opendylan.git
+    cd opendylan
+    makepkg -si
+
+* On macOS you may use this recipe instead::
+
+    brew tap dylan-lang/dylan
+    brew install opendylan       # or brew upgrade opendylan
diff --git a/documentation/website/source/duim-reference b/documentation/website/source/duim-reference
new file mode 120000
index 0000000000..e5305f82c1
--- /dev/null
+++ b/documentation/website/source/duim-reference
@@ -0,0 +1 @@
+../_packages/opendylan/current/src/documentation/duim-reference
\ No newline at end of file
diff --git a/documentation/website/source/getting-started-cli b/documentation/website/source/getting-started-cli
new file mode 120000
index 0000000000..3e7fb07838
--- /dev/null
+++ b/documentation/website/source/getting-started-cli
@@ -0,0 +1 @@
+../_packages/opendylan/current/src/documentation/getting-started-cli
\ No newline at end of file
diff --git a/documentation/website/source/getting-started-ide b/documentation/website/source/getting-started-ide
new file mode 120000
index 0000000000..9432bc55de
--- /dev/null
+++ b/documentation/website/source/getting-started-ide
@@ -0,0 +1 @@
+../_packages/opendylan/current/src/documentation/getting-started-ide
\ No newline at end of file
diff --git a/documentation/website/source/hacker-guide b/documentation/website/source/hacker-guide
new file mode 120000
index 0000000000..4c7de66e9e
--- /dev/null
+++ b/documentation/website/source/hacker-guide
@@ -0,0 +1 @@
+../_packages/opendylan/current/src/documentation/hacker-guide
\ No newline at end of file
diff --git a/documentation/website/source/history/apple-dylan/apple-cambridge.rst b/documentation/website/source/history/apple-dylan/apple-cambridge.rst
new file mode 100644
index 0000000000..e70bd50d41
--- /dev/null
+++ b/documentation/website/source/history/apple-dylan/apple-cambridge.rst
@@ -0,0 +1,17 @@
+***************
+Apple Cambridge
+***************
+
+In the 1990's Apple Computer acquired Coral Software. Coral originally
+developed a capable Lisp environment for the Apple Macintosh that
+eclipsed the half-hearted competitors such as ExperLisp. Soon it
+achieved Common Lisp compliance, and was later renamed Macintosh Common
+Lisp (MCL). MCL became the foundation for some exciting technology that
+came out of ATG, such as `SK8 <https://en.wikipedia.org/wiki/SK8>`_ and
+:doc:`index`.
+
+Under the direction of Ike Nassi, Apple Cambridge developed Apple Dylan,
+initially for the Newton PDA, and subsequently for the Apple Macintosh.
+
+Apple Cambridge was disbanded in 1995. Several members of group went on
+to work on Harlequin Dylan, and later at Functional Objects.
diff --git a/documentation/website/source/history/apple-dylan/eulogy.rst b/documentation/website/source/history/apple-dylan/eulogy.rst
new file mode 100644
index 0000000000..72ee9ecdf5
--- /dev/null
+++ b/documentation/website/source/history/apple-dylan/eulogy.rst
@@ -0,0 +1,146 @@
+******************
+Apple Dylan Eulogy
+******************
+
+Paul R Potts writes:
+
+In 1994 I was a beta user of the Dylan Technology Release put out by
+:doc:`apple-cambridge` R&D.
+
+:doc:`index` was an amazing development environment: the most
+sophisticated and highly leveraging environment that I've ever seen,
+before or since, with the second place position belonging to Apple's
+NewtonScript. (I'm told a Lisp Machine might be comparable, but I've
+never seen one).
+
+Unfortunately, it was ahead of its time: it required what was then a
+considerable amount of memory (20 megabytes or more), was fairly
+crash-prone and somewhat incomplete, and was unfortunately quite slow.
+(On a 68040-based Quadra 800, or a 68030-based PowerBook Duo, more than
+"quite" slow -- it was agonizing, and I consider myself to be a very
+patient guy).
+
+The IDE did very ambitious things, and did them well enough to prove the
+concept, but using it for real work was very difficult. It is not quite
+clear to me why it was so slow. I'm told that MCL is not slow, but
+perhaps the demands that the Dylan TR placed on it were a little much
+for it; I sometimes found myself staring at the "GC" cursor for many
+minutes at a time.
+
+I contributed what testing I could (within the limits of my patience)
+and also submitted a small program to draw fractals based on
+string-rewriting L-systems. Even with my poor knowledge of Lisp and poor
+choice of algorithms, it performed decently, indicating to me that Dylan
+could be compiled to reasonably efficient code, if not extremely
+efficient.
+
+Dylan was, in part, an attempt to build a bridge between static language
+users and the dynamic language community. The Cambridge team wisely
+understood that C programmers would be generally unwilling to convert to
+a parenthesized, prefix syntax: for this reason, Dylan was given a
+Pascal-like syntax. Programmers who have used Lisp generally come to
+feel comfortable with it; I've used Scheme enough now to feel be
+somewhat accustomed to the style, but I will probably always prefer a
+non-Lispy syntax. Computer science types can say "that's just syntax; it
+is irrelevant," but in fact many barriers to language adoption are
+cultural and practical, not technical.
+
+There have been, and continue to be, a lot of unspoken assumptions that
+make it hard for the two communities to cross over. For example, I had
+never used Scheme or Lisp lists, and did not realize that Dylan lists
+were built using the Lisp "pair" idiom, and thus that in normal
+operation, inserting items into a Dylan <list> would result in the items
+appearing in reverse order.
+
+This was not made clear in the documentation, because to those with a
+Scheme or Lisp background it was obvious. But in C code, building a
+linked list is generally done by walking to the end and hooking nodes to
+the tail. Currying and closures were completely mysterious to me. But,
+slowly, I've come to understand these things that are very basic in the
+Lisp community and now use closures and currying in my Dylan code.
+
+It seems to be possible, to this day, to graduate from a computer
+science program having learned _either_ the idioms and scenery of the
+Lisp/Scheme world, _or_ the rules and scenery or the C/C++/Java/C#
+world, but not both. We just generally aren't willing to venture into
+each other's alien landscape. The static language community continues to
+make marginal improvements to its languages, not realizing the
+improvements they are discovering are they are discovering are twenty or
+more years old. But that is the subject for some ranting another day.
+
+I have collected some screen shots to illustrate the amazing user
+interface of the Apple Dylan technology release. These were captured on
+my PowerBook G4/400. The Dylan TR will still run under MacOS 9.2.2, but
+will not run at all in the "classic" emulation environment.
+
+Since some of the images are already quite large, I have reduced the
+color depth to an 8-bit web-safe palette. This has made some of the
+icons look a little less attractive than they did in their original
+color scheme, but the difference is not very noticeable.
+
+- :doc:`screenshots/index`
+
+Enjoy.
+
+--------
+
+RainerJoswig adds:
+
+MCL as the implementation environment for Apple Dylan
+=====================================================
+
+MCL itself has an advanced GC implementation. It has one limitation
+though, it uses a fixed amount of memory that can't be expanded at
+runtime. So, to run the Dylan IDE without seeing too much GCs you might
+need to give the MCL application, the Dylan IDE in this case, a lot of
+memory (use the Info dialog in the Finder to set the memory size) - to
+as much as you like - say, 50 MByte. A full GC of a 50MB MCL takes under
+a second on a current Mac. Make sure that the memory is RAM and not
+virtual memory on disk, which would slow things down. Another thing for
+MCL experts is to turn on the EGC (Ephemeral Garbage Collection) by
+calling (egc t) in an MCL listener. The EGC looks for garbage on memory
+pages that have been changed recently - with support from the MMU. The
+effect is that the EGC runs frequently and unnoticeably - so full GCs
+will not happen that often.
+
+Sk8
+===
+
+There are several cool IDEs implemented on top of MCL. Another one done
+by Apple is SK8. SK8 has an even cooler environment than Apple Dylan and
+has been used in dozens of projects many years ago. The programming
+language of SK8 is a kind of object-oriented AppleScript (written in
+MCL). Here is a `picture of Sk8 running on a PowerMac
+<../../_static/images/sk8.jpg>`_. Sk8 has been released by Apple as source code.
+
+Apple Dylan influences
+======================
+
+Apple Dylan's IDE is also a bit influenced by Smalltalk 80. In Smalltalk
+you also develop code in a kind of database. Mac-based real cool
+Interface Builders were done first in LeLisp (later ported to Objective
+C at NeXT). Interesting stuff done with Apple Dylan were also a first
+shot of the Newton OS, a study of the Finder in Dylan and a Dylan
+version of MacApp (Apple's early framework for object-oriented
+application development).
+
+More radical dynamic development environments
+=============================================
+
+In this category I would think fall things like the Symbolics Genera
+environment, Intellicorp's KEE, some Smalltalks and Xerox's InterLisp D.
+
+New in the Apple Dylan IDE
+==========================
+
+What I think was relatively new are the remote debugging capabilities of
+running Dylan applications from within the Apple Dylan IDE. The
+NewtonScript environment does allow that only primitively. Also new was
+the use of an Interface Builder from within a running Apple Dylan
+application, without having the IDE inside the application.
+
+New version of Apple Dylan?
+===========================
+
+Currently Digitool has rights to Apple Dylan. Maybe they would port it
+to MCL 5.0 and MacOS X - if you throw tons of money at them, that is.
diff --git a/documentation/website/source/history/apple-dylan/index.rst b/documentation/website/source/history/apple-dylan/index.rst
new file mode 100644
index 0000000000..c97dfb1937
--- /dev/null
+++ b/documentation/website/source/history/apple-dylan/index.rst
@@ -0,0 +1,41 @@
+***********
+Apple Dylan
+***********
+
+*Apple Dylan* was a first run of `Apple Computer, Inc.
+<https://www.apple.com/>`_ at an integrated development environment for
+the Dylan language. It appeared as a technology release in 1995 for the
+MC68k platform. It had numerous flaws, mainly that it was built on the
+top of the MCL (Macintosh Common Lisp from `Digitool
+<https://web.archive.org/web/20120204173211/http://www.digitool.com/>`_) development environment. Although this
+made it a wonderful environment, it was a severe restriction on further
+progress. Because Apple got into serious financial trouble that time,
+they had to stop Dylan development and dissolved the
+:doc:`apple-cambridge` team. In a final act Digitool was funded to do a
+port to the PowerPC platform. The result of this (with some patches)
+still runs on MacOS 9.2 (but not in the "Classic" compatibility box
+under Mac OS X).
+
+Apple Dylan TR does not implement all of Dylan; macro support especially
+is rudimentary. Otherwise it is an awesome IDE, probably the best
+around, despite the fact that it is 8 years old.
+
+----------
+
+Paul R Potts was an Apple Dylan beta tester, and has written several
+pages detailing his experiences and impressions:
+
+- :doc:`eulogy` - a few words on Apple Dylan
+- :doc:`technology-release` - about the prototype
+- :doc:`today` - can I still run it?
+- :doc:`screenshots/index` - the configurable browser
+- :doc:`screenshots/browsers`- the special browsers
+- :doc:`screenshots/dynamic` - the dynamic environment
+- :doc:`screenshots/misc` - the interface builder, and Lisp leftovers
+
+.. toctree::
+   :hidden:
+   :glob:
+
+   *
+   screenshots/*
diff --git a/documentation/website/source/history/apple-dylan/screenshots/browsers.rst b/documentation/website/source/history/apple-dylan/screenshots/browsers.rst
new file mode 100644
index 0000000000..ae0fd5a8bf
--- /dev/null
+++ b/documentation/website/source/history/apple-dylan/screenshots/browsers.rst
@@ -0,0 +1,63 @@
+**********************************
+Apple Dylan Screenshots - Browsers
+**********************************
+
+Paul R Potts writes:
+
+Here is a simple example: a single-pane browser that shows a call graph.
+One function is displayed, called turtle-forward! (note: the exclamation
+point is part of the name, and by convention, generic functions that end
+in an exclamation point change the state of the objects they are
+passed). The functions called by turtle-forward are shown. These include
+getters, since even simple slot access is done through getter functions,
+whether it ultimately results in a real function call at run-time or
+not.
+
+Note that the functions include things that would generally be
+considered intrinsic to the language, if one comes from a static
+language background, like the ``+`` operator, which is shown to actually
+be a generic function with a whole hierarchy of specialized methods for
+handling "plus."
+
+.. figure:: images/appledylan-call-grapher.png
+   :align: center
+
+   A hierarchy of specialized methods for handling "plus" operations.
+
+Now, here's another browser, called "function family." It really shows
+generic functions. This is the generic function "+". Note that
+hard-coded intrinsic functions are still displayed, but no source is
+available.
+
+.. figure:: images/appledylan-function-family.png
+   :align: center
+
+   A function family browser.
+
+This browser shows direct methods, and is designed to be used with a
+class. In other words, it shows all functions that operate on the
+"turtle" class, but not its ancestors.
+
+.. figure:: images/appledylan-direct-methods.png
+   :align: center
+
+   Browsing all methods of a specific class.
+
+Here's a useful one: it displays all direct methods and slots of a class
+together.
+
+.. figure:: images/appledylan-slots-and-methods.png
+   :align: center
+
+   All direct methods and slots of a class.
+
+There were several other specialized browsers available for displaying
+all references from an entity, all references to an entity, but I think
+you are beginning to get the idea. Whatever aspect of your code you
+might want to focus on, :doc:`../index` was designed to provide you a
+way to see it clearly. The dynamic nature of the language gave you much
+more confidence that what you were saw in the IDE would correspond more
+closely to what would happen at run-time.
+
+Next in :doc:`dynamic`: a little bit about the dynamo (application nub),
+the listener, and the debugging tools available.
diff --git a/documentation/website/source/history/apple-dylan/screenshots/dynamic.rst b/documentation/website/source/history/apple-dylan/screenshots/dynamic.rst
new file mode 100644
index 0000000000..a8b90f1006
--- /dev/null
+++ b/documentation/website/source/history/apple-dylan/screenshots/dynamic.rst
@@ -0,0 +1,57 @@
+*********************************
+Apple Dylan Screenshots - Dynamic
+*********************************
+
+Paul R Potts writes:
+
+Dynamic Programming
+===================
+
+If you wanted to build and debug an application, your work would revolve
+around the application nub. This was a small application shell, complete
+with source code, that could be fleshed out with your objects and
+debugged interactively, even on another machine across a network. Your
+live objects would be downloaded to the application nub for debugging.
+It was even possible to stop the application nub's event loop, stream
+out objects, replace methods and objects, changing the behavior of your
+code, and keep going, only rebuilding what you needed. All this is not
+only possible but common in a truly dynamic environment.
+
+.. figure:: images/appledylan-app-nub-info.png
+   :align: center
+
+   The application nub for debugging in Apple Dylan.
+
+After PowerPC support was added, it was possible to build 68K, PowerPC,
+or "fat" binaries with no additional effort.
+
+.. figure:: images/appledylan-project-type.png
+   :align: center
+
+   Different project types in Apple Dylan.
+
+I'm not going to to into extreme detail about all the tools available to
+you for debugging an application, but let me quickly present a grab bag
+of these tools. A developer could
+
+- inspect the run-time heaps (top left)
+- see the compiled code associated with any function
+- recursively explore every detail of the representation down to the bit
+  level
+
+.. figure:: images/appledylan-debugging-grab-bag.png
+   :align: center
+
+   A grab bag of the debugging tooks available in Apple Dylan.
+
+This next image shows inspection of heap objects within a module:
+
+.. figure:: images/appledylan-dynamic-runtime.png
+   :align: center
+
+   Inspection of heap objects within a module.
+
+Next: Apple Dylan was a little bit strange in that it still showed its
+MCL (Macintosh Common Lisp) innards. Also, Apple had ambitions for a
+full-blown GUI-building tool, allowing you to lay out and tweak GUIs
+without even writing code. See :doc:`misc`.
diff --git a/documentation/website/source/history/apple-dylan/screenshots/images/appledylan-app-nub-info.png b/documentation/website/source/history/apple-dylan/screenshots/images/appledylan-app-nub-info.png
new file mode 100644
index 0000000000..6b05fadb34
Binary files /dev/null and b/documentation/website/source/history/apple-dylan/screenshots/images/appledylan-app-nub-info.png differ
diff --git a/documentation/website/source/history/apple-dylan/screenshots/images/appledylan-call-grapher.png b/documentation/website/source/history/apple-dylan/screenshots/images/appledylan-call-grapher.png
new file mode 100644
index 0000000000..fbbe4cf869
Binary files /dev/null and b/documentation/website/source/history/apple-dylan/screenshots/images/appledylan-call-grapher.png differ
diff --git a/documentation/website/source/history/apple-dylan/screenshots/images/appledylan-debugging-grab-bag.png b/documentation/website/source/history/apple-dylan/screenshots/images/appledylan-debugging-grab-bag.png
new file mode 100644
index 0000000000..ad32094259
Binary files /dev/null and b/documentation/website/source/history/apple-dylan/screenshots/images/appledylan-debugging-grab-bag.png differ
diff --git a/documentation/website/source/history/apple-dylan/screenshots/images/appledylan-direct-methods.png b/documentation/website/source/history/apple-dylan/screenshots/images/appledylan-direct-methods.png
new file mode 100644
index 0000000000..c297d2e65c
Binary files /dev/null and b/documentation/website/source/history/apple-dylan/screenshots/images/appledylan-direct-methods.png differ
diff --git a/documentation/website/source/history/apple-dylan/screenshots/images/appledylan-dynamic-runtime.png b/documentation/website/source/history/apple-dylan/screenshots/images/appledylan-dynamic-runtime.png
new file mode 100644
index 0000000000..963e8e257f
Binary files /dev/null and b/documentation/website/source/history/apple-dylan/screenshots/images/appledylan-dynamic-runtime.png differ
diff --git a/documentation/website/source/history/apple-dylan/screenshots/images/appledylan-function-family.png b/documentation/website/source/history/apple-dylan/screenshots/images/appledylan-function-family.png
new file mode 100644
index 0000000000..c7e928acc6
Binary files /dev/null and b/documentation/website/source/history/apple-dylan/screenshots/images/appledylan-function-family.png differ
diff --git a/documentation/website/source/history/apple-dylan/screenshots/images/appledylan-gui-builder-palettes.png b/documentation/website/source/history/apple-dylan/screenshots/images/appledylan-gui-builder-palettes.png
new file mode 100644
index 0000000000..ef95c5cfe3
Binary files /dev/null and b/documentation/website/source/history/apple-dylan/screenshots/images/appledylan-gui-builder-palettes.png differ
diff --git a/documentation/website/source/history/apple-dylan/screenshots/images/appledylan-gui-builder.png b/documentation/website/source/history/apple-dylan/screenshots/images/appledylan-gui-builder.png
new file mode 100644
index 0000000000..f32c3abf8b
Binary files /dev/null and b/documentation/website/source/history/apple-dylan/screenshots/images/appledylan-gui-builder.png differ
diff --git a/documentation/website/source/history/apple-dylan/screenshots/images/appledylan-hierarchy.png b/documentation/website/source/history/apple-dylan/screenshots/images/appledylan-hierarchy.png
new file mode 100644
index 0000000000..c5dae10afa
Binary files /dev/null and b/documentation/website/source/history/apple-dylan/screenshots/images/appledylan-hierarchy.png differ
diff --git a/documentation/website/source/history/apple-dylan/screenshots/images/appledylan-implementor-menu.png b/documentation/website/source/history/apple-dylan/screenshots/images/appledylan-implementor-menu.png
new file mode 100644
index 0000000000..42e4e4c1ba
Binary files /dev/null and b/documentation/website/source/history/apple-dylan/screenshots/images/appledylan-implementor-menu.png differ
diff --git a/documentation/website/source/history/apple-dylan/screenshots/images/appledylan-linked-browser-pages-2.png b/documentation/website/source/history/apple-dylan/screenshots/images/appledylan-linked-browser-pages-2.png
new file mode 100644
index 0000000000..3fa788c0ed
Binary files /dev/null and b/documentation/website/source/history/apple-dylan/screenshots/images/appledylan-linked-browser-pages-2.png differ
diff --git a/documentation/website/source/history/apple-dylan/screenshots/images/appledylan-linked-browser-panes.png b/documentation/website/source/history/apple-dylan/screenshots/images/appledylan-linked-browser-panes.png
new file mode 100644
index 0000000000..76e12ba2ec
Binary files /dev/null and b/documentation/website/source/history/apple-dylan/screenshots/images/appledylan-linked-browser-panes.png differ
diff --git a/documentation/website/source/history/apple-dylan/screenshots/images/appledylan-macros.png b/documentation/website/source/history/apple-dylan/screenshots/images/appledylan-macros.png
new file mode 100644
index 0000000000..7fcefc0f9f
Binary files /dev/null and b/documentation/website/source/history/apple-dylan/screenshots/images/appledylan-macros.png differ
diff --git a/documentation/website/source/history/apple-dylan/screenshots/images/appledylan-project-type.png b/documentation/website/source/history/apple-dylan/screenshots/images/appledylan-project-type.png
new file mode 100644
index 0000000000..e421f33570
Binary files /dev/null and b/documentation/website/source/history/apple-dylan/screenshots/images/appledylan-project-type.png differ
diff --git a/documentation/website/source/history/apple-dylan/screenshots/images/appledylan-slots-and-methods.png b/documentation/website/source/history/apple-dylan/screenshots/images/appledylan-slots-and-methods.png
new file mode 100644
index 0000000000..338afda533
Binary files /dev/null and b/documentation/website/source/history/apple-dylan/screenshots/images/appledylan-slots-and-methods.png differ
diff --git a/documentation/website/source/history/apple-dylan/screenshots/images/appledylan-status-indicators.png b/documentation/website/source/history/apple-dylan/screenshots/images/appledylan-status-indicators.png
new file mode 100644
index 0000000000..1575f81d9e
Binary files /dev/null and b/documentation/website/source/history/apple-dylan/screenshots/images/appledylan-status-indicators.png differ
diff --git a/documentation/website/source/history/apple-dylan/screenshots/images/appledylan-warnings.png b/documentation/website/source/history/apple-dylan/screenshots/images/appledylan-warnings.png
new file mode 100644
index 0000000000..d2d099903e
Binary files /dev/null and b/documentation/website/source/history/apple-dylan/screenshots/images/appledylan-warnings.png differ
diff --git a/documentation/website/source/history/apple-dylan/screenshots/index.rst b/documentation/website/source/history/apple-dylan/screenshots/index.rst
new file mode 100644
index 0000000000..ae4c8b671a
--- /dev/null
+++ b/documentation/website/source/history/apple-dylan/screenshots/index.rst
@@ -0,0 +1,93 @@
+***********************
+Apple Dylan Screenshots
+***********************
+
+Paul R Potts writes:
+
+The Configurable Browser
+
+At the heart of the :doc:`../index` TR was the extremely configurable
+multi-pane browser window. Panes could be arranged and split
+arbitrarily, and the "output" of any pane could be dragged and dropped
+onto the input of another. This meant that the selected object in the
+source pane would be displayed in a detailed view in the destination
+pane. In this example note how four browser panes are linked together to
+"drill down" to the function level. The little icons unobtrusively
+indicate the type of each entity in the browser: a class definition,
+function, slot, etc. Little colored squares in the margin indicate
+unsaved objects, warnings, and other properties of the source code
+records.
+
+This also illustrates a key feature of the Apple Dylan TR: every part of
+your source code was not just text in a text file, it was a separate
+object in an object database. This gave the IDE incredible power,
+because meta-data about each object could be maintained to facilitate
+browsing via a variety of relationships and views, but less-than-optimal
+implementation may have been responsible for some of the performance
+problems of the Technology Release.
+
+Certain other IDEs have also used this technique: for example, IBM's
+`VisualAge <https://en.wikipedia.org/wiki/IBM_VisualAge>`_ tools use a
+repository, and even included a complete source-code version tracking
+system. This greatly facilitates activities like code refactoring.
+
+Keeping your source code in a fully version-tracked, object-oriented
+database with full metadata is an idea whose time has long since
+arrived, yet most of us still spend our time editing text files. Apple
+Dylan could export and import code from text files, but once you've used
+an IDE that takes advantage of fine-grained object storage of your
+source, you'll never want to go back.
+
+.. figure:: images/appledylan-linked-browser-panes.png
+   :align: center
+
+   Browser panes of Apple Dylan Environment.
+
+Here is a differently-configured browser showing how to "drill down" to
+display a class definition.
+
+.. figure:: images/appledylan-linked-browser-pages-2.png
+   :align: center
+
+   The Apple Dylan browser drilling down to a class definition.
+
+It was also possible to view an entire nested hierarchy in a single
+pane, using the little "disclosure triangles" to collapse and expand
+parts of the hierarchy. Here is an example. Note that there were
+sometimes cosmetic drawing problems in the browsers; keep in mind that
+the Dylan TR was not a finished product, and Apple was quite open about
+the fact that it had some rough edges.
+
+.. figure:: images/appledylan-hierarchy.png
+   :align: center
+
+   Hierarchy of Apple Dylan.
+
+Rather than display warnings and errors in a separate log window, a
+legacy of separate text-file based compilers, Apple Dylan could use
+configurable colored dots to indicate the source entities that contained
+problems. It was possible to leave some problems to fix later, as long
+as they were not critical errors and as long as the source entity
+containing the problem was not needed to satisfy a dependency in the
+code.
+
+.. figure:: images/appledylan-status-indicators.png
+   :align: center
+
+   Status indicator of Apple Dylan.
+
+Here is a browser window showing how warnings could be displayed inline
+with the code. Note that the status indicators propagate up even to the
+top of the browser, to indicate that somewhere in this browser are
+warnings. Apple Dylan's UI was designed from the ground up to allow
+developers to work in multiple views of the code at once.
+
+.. figure:: images/appledylan-warnings.png
+   :align: center
+
+   Warnings of Apple Dylan.
+
+In addition to letting you configure your own browser, the Dylan TR
+provided a number of pre-defined browsers with special behaviors that
+could give a particular view of the entities hooked into them. On the
+next page, :doc:`browsers`, you can see some of these browsers.
diff --git a/documentation/website/source/history/apple-dylan/screenshots/misc.rst b/documentation/website/source/history/apple-dylan/screenshots/misc.rst
new file mode 100644
index 0000000000..8673f85f53
--- /dev/null
+++ b/documentation/website/source/history/apple-dylan/screenshots/misc.rst
@@ -0,0 +1,70 @@
+******************************
+Apple Dylan Screenshots - Misc
+******************************
+
+Interface Builder
+=================
+
+:doc:`../index` came with a very preliminary interface builder, to
+accompany its MacOS-specific GUI framework. It was not nearly complete,
+but both the framework and the interface builder showed amazing promise.
+Here is a shot of the interface builder:
+
+.. figure:: images/appledylan-gui-builder.png
+   :align: center
+
+   The interface builder of Apple Dylan.
+
+Tools were included for generating menus, windows, dialogs, buttons,
+checkboxes, images, and all the usual GUI components. Notice the
+property inspector examining the non-standard default button with a red
+border! This is a control manager button drawn by code from the
+framework, but its behavior could be altered by specifying "determiners"
+and "adorners" that would change the object's run-time behavior. These
+corresponded directly to code entities available in the framework. User
+interfaces could be tested out "live" by dynamically assembling
+interface objects.
+
+.. figure:: images/appledylan-gui-builder-palettes.png
+   :align: center
+
+   A control manager button in Apple Dylan.
+
+Macros
+======
+
+Now we come to a few of the more obscure details of Apple Dylan. The
+macro system was not yet complete, but worked well enough to allow
+inclusion of some simple macros such as "with-locked-handle" shown
+below. This corresponds roughly to using a simple stack-based handle
+locker class in C++, but instead it is done by performing a macro
+rewrite of the source. Note that other Dylan implementation have gone
+much farther towards implementing the whole Dylan macro system.
+
+.. figure:: images/appledylan-macros.png
+   :align: center
+
+   The uncompleted macro system of Apple Dylan.
+
+Lisp Leftovers
+==============
+
+There were some dark corners and secrets in Apple Dylan. Here we see
+that the Macintosh Common Lisp "implementor" menus are available. Take a
+look at the tantalizing option allowing you to switch between prefix and
+infix Dylan. Nope, this did not mean that Apple Dylan would let you
+transform one syntax to the other on the fly. But it did mean that many
+of the internals, some of which come as source with the Dylan Technology
+Release, were written in prefix (Lisp-style) Dylan, and at least
+internally, both the original and newer syntax were supported. Prefix
+Dylan was officially deemed a dead end, but one can imagine a future IDE
+that would truly allow both to be intermixed freely, attempting to give
+users the best of both. This is yet another aspect of what certainly
+could have been the most remarkable development environment of its time,
+and a rich source of ideas for the future.
+
+.. figure:: images/appledylan-implementor-menu.png
+   :align: center
+
+   The Macintosh Common Lisp "implementor" menus was available in Apple
+   Dylan.
diff --git a/documentation/website/source/history/apple-dylan/technology-release.rst b/documentation/website/source/history/apple-dylan/technology-release.rst
new file mode 100644
index 0000000000..f4b55f6ed6
--- /dev/null
+++ b/documentation/website/source/history/apple-dylan/technology-release.rst
@@ -0,0 +1,37 @@
+******************************
+Apple Dylan Technology Release
+******************************
+
+Paul R Potts writes:
+
+:doc:`apple-cambridge` ran a preview program circa 1994 inviting
+interested developers to work with pre-release versions of :doc:`index`.
+This tool was the product of Apple Cambridge, a lab that had hired some
+of the best and brightest minds from the Lisp community.
+
+Apple Dylan was best thought of as a proof-of-concept, prototyping
+several important complementary developments:
+
+- A highly dynamic and configurable IDE
+- A development tool that kept all source code entities in an
+  object-oriented database
+- The Dylan language
+- An early version of the macro system
+- A runtime and debugging environment allowing remote debugging,
+  compilation and remote execution
+
+It was agonizingly slow, buggy, and not ready to use for serious work,
+but also very intriguing, inviting developers to believe that one day
+they could live in a development world that offered more than a
+nightmare of memory management, environments that don't understand
+anything about the code you write with them, and compilers that throw
+away almost all of the knowledge they had about your code.
+
+Apple Dylan was eventually made available for sale by Apple as the
+*Apple Dylan Technology Release*. The Apple Cambridge lab was closed and
+all employees let go. Digitool did some retrofitting to make the
+Technology Release work on the PowerPC platform, but that was it. All
+that remains are the t-shirts and the dream.
+
+It is still possible to run Apple Dylan on MacOS 9.2.2. See :doc:`today`
+for more information.
diff --git a/documentation/website/source/history/apple-dylan/today.rst b/documentation/website/source/history/apple-dylan/today.rst
new file mode 100644
index 0000000000..55cbf306d4
--- /dev/null
+++ b/documentation/website/source/history/apple-dylan/today.rst
@@ -0,0 +1,73 @@
+*****************
+Apple Dylan Today
+*****************
+
+Paul R Potts writes:
+
+I frequently hear from people who are interested in trying out the
+:doc:`technology-release` (TR) today, even knowing full well that it is
+an old prototype with no support from Apple, running on an operating
+system (MacOS 9.2.2) which has been declared dead.
+
+The outlook is grim for the Technology Release. Apple Dylan was patched
+to run on the PowerPC architecture, but that was many years ago. There
+were many unfixed bugs, and they have remained unfixed. As system
+updates have been released, the stability of the Apple Dylan TR has been
+further degraded. (And, remember, it was not that solid to begin with,
+even when used on a 68040-based system such as a Quadra 800).
+
+There was a problem with the icon. I think the creator type "dyln" was
+later re-used by the OS for generic shared libraries. Using ResEdit, I
+changed the creator type to "diln" and removed some apparently
+extraneous icons, and the TR has its icon back.
+
+Right now, I am using the Apple Dylan TR on a G4 PowerBook (400 MHz)
+with 512 megabytes of RAM. To get it to work properly, I had to make
+sure that the PPC Exception Enabler extension was NOT in the extensions
+folder, and turn off virtual memory.
+
+The TR still runs with painful slowness, despite the ridiculous speed
+difference between the G4 and 68040 processor family. It does not seem
+to make much of a difference. You'll have to wait long minutes to build
+and launch a project.
+
+I gave the Dylan application a 125-megabyte partition. I was having
+trouble launching even the simplest project, "Hello World," but
+rebuilding the project with all sub-projects (which still takes a long,
+long time) fixed the problem.
+
+My applications will run and interactive debugging is possible. So, I
+decided to try it out with some new Dylan code that I wanted to use on
+three platforms: Functional Objects, Gwydion, and Apple Dylan. I was
+hoping to use the browsers to better visualize my code. And there is the
+LID interchange file format: this is supposed to make exchanging Dylan
+with text-based tools easier.
+
+After a few hours, several complete from-scratch rebuilds of the
+project, many strange error messages, and one hard lock-up, I've decided
+that the cool IDE just isn't worth it: I can't get any real work done.
+
+- Importing source failed miserably, so I had to copy and paste from
+  a text editor record-by-record.
+- There are some language compatibility issues: Apple Dylan does not
+  seem to provide "format-out" or "define function" or "type-union" or
+  "limited." I no longer have the big set of paper documentation that
+  came with the Technology Release, and it does not come with online
+  versions of these books. So, hack workarounds were immediately needed
+  to share source with Gwydion and Fun-o. So much for common source.
+- Then, the weird problems began. Errors about being unable to compile
+  a method, but the method in question was not indicated. Warnings that
+  would not show up in the source records. Incomprehensible IDE errors
+  popped up.
+- After tossing out the project completely, rebooting, and starting over
+  twice, my patience had reached its end. Interactive debugging is a
+  wonderful thing, but only when it is my code that I'm debugging.
+
+All this is quite a shame. All software goes to software heaven (or
+hell) one day, but :doc:`index` never even reached adulthood. If you
+have the chance, try it out. It is still inspiring to witness the
+elegance and potential of this environment.
+
+Meanwhile, please take a look at my :doc:`screenshots/index`. It's a bit
+hard to capture such a dynamic environment in action this way, but maybe
+something remains to inspire you.
diff --git a/documentation/website/source/history/index.rst b/documentation/website/source/history/index.rst
new file mode 100644
index 0000000000..020113fe61
--- /dev/null
+++ b/documentation/website/source/history/index.rst
@@ -0,0 +1,243 @@
+*******
+History
+*******
+
+Dylan has a long history. It was originally created in the early 1990s as a project
+within Apple Computer, but was expanded to a partnership between Apple, Harlequin and
+Carnegie Mellon University (CMU).
+
+See also, the Wikipedia `history of the Dylan programming language
+<https://en.wikipedia.org/wiki/History_of_the_Dylan_programming_language>`_ page, which
+may have additional information.
+
+The original Dylan is now referred to as "Prefix Dylan" and used a Lisp-style syntax::
+
+   (define-method sum ((numbers <sequence>))
+     (reduce1 + numbers))
+   (define-method square ((x <number>)) (* x x))
+   (define-method square-all ((coords <sequence>))
+     (map square coords)
+   (define distance (compose sqrt sum square-all))
+
+Apple Dylan
+===========
+
+The first implementation was `Apple Dylan`_.  While Dylan was originally intended for use
+on the Apple Newton platform, that didn't work out and their focus shifted to Dylan on
+the desktop on classic Mac OS.
+
+Some years ago, Paul R Potts wrote about his experiences with `Apple Dylan`_, including
+some screenshots. Apple distributed a `brochure at WWDC in 1994
+<../_static/dylanwwdc94brochure.pdf>`_ (PDF) that described Dylan and the features that
+it was going to bring to the developer experience.
+
+.. _Apple Dylan: apple-dylan/
+
+Change in Syntax
+================
+
+In late 1993 or 1994, CMU and Apple decided to change the Dylan syntax to
+what we currently have now, the infix syntax. The value of this change was
+a subject of much debate, both at the time and in the subsequent
+years. At the time, it was thought that the world wasn't ready for a
+mainstream language with a Lisp syntax, so a more familiar syntax
+might be better. There were also discussions at the time of supporting
+both the prefix and the infix syntax within the same compiler, something
+which never came to fruition.
+
+Harlequin Dylan
+===============
+
+Sometime in 1993, Harlequin started a project to produce a Dylan
+development environment, DylanWorks. Harlequin, at the time, was known
+for their LispWorks product. Keith Playford was their first hire to
+work specifically on the Dylan project. Keith had previously
+been involved with `EuLisp <https://en.wikipedia.org/wiki/EuLisp>`_.
+
+Harlequin's Dylan was originally implemented using the prefix syntax
+and later converted to the current infix syntax. The first implementation
+was a Dylan emulator running on top of LispWorks as described in this
+`Hacker News comment <https://news.ycombinator.com/item?id=8853095>`_:
+
+   When Harlequin started out with Dylan, to bootstrap we first quickly
+   morphed LispWorks into a high-functioning Dylan IDE. This was done
+   through a combination of macro, reader macro and CLOS MetaObject
+   Protocol abuse, allowing us to achieve a faithful rendition of
+   Dylan's syntax and object system semantics respectively.
+
+   When Dylan went from prefix to infix syntax the reader macro
+   indirection got all the more elaborate: what started out as a
+   trivial reader macro that treated colons differently started
+   delegating to a full-blown lex & yacc style parser instead.
+
+   All the better, most of this was achieved modularly: Lisp editor
+   buffers and Lisp listeners would run happily alongside Dylan
+   editor buffers and Dylan listeners, Lisp code could still compile
+   load and run alongside Dylan code, and Lisp classes could
+   interoperate cleanly with Dylan classes.
+
+This `emulator <https://github.com/dylan-lang/opendylan/tree/5f9225d246d771cfaa2fa4f255a4447bff6991b8/old/Sources/emulator>`_
+can be found in an old revision of Open Dylan's git repository.
+
+While DylanWorks ran on multiple platforms, the commercial goal
+was to ship a full development environment on Windows. Unfortunately,
+at the time, LispWorks did not yet run on Windows and there were
+goals that were difficult to achieve with LispWorks (like producing
+native shared libraries and executables). Work began to replace
+the original emulator with a full-blown compiler and code-generator
+written in Dylan.
+
+HARP
+----
+
+HARP is the Harlequin Abstract RISC Processor and was designed and
+developed at Harlequin in the late 1980s. It was used in Harlequin's
+LispWorks and later translated to Dylan for use in Harlequin's
+DylanWorks (which is now Open Dylan).
+
+Clive Tong, an engineer at Harlequin in 1989, `briefly described
+<https://clivetong.wordpress.com/2012/12/21/so-many-architectures-so-little-time/>`_
+it as:
+
+   The compiler targeted an instruction set known as HARP (Harlequin
+   Abstract RISC Processor), and then HARP instructions were translated
+   into machine instructions using a template matching scheme. HARP had
+   an infinite set of registers, and the register colouring happened as
+   part of this templating processing.
+
+Some additional details about the early design of HARP are available in
+`Techniques for Dynamic Software Migration <http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.47.2525>`_
+from 1988. Other early sources of information about it, written by Hunter
+and Knightbridge, appear to be lost to the sands of time.
+
+DFMC
+----
+
+DFMC (Dylan Flow Machine Compiler) was the Dylan compiler that resulted
+from the work at Harlequin on DylanWorks. (There were other earlier
+compilers.) This is the compiler that is still in use today in Open Dylan.
+
+DUIM
+----
+
+Scott McKay, formerly of `Symbolics <https://en.wikipedia.org/wiki/Symbolics>`_,
+produced a cross-platform GUI toolkit for DylanWorks called DUIM, or the
+Dylan User Interface Manager. This was based on his previous work on
+`CLIM <https://en.wikipedia.org/wiki/Common_Lisp_Interface_Manager>`_,
+which in turn was based on Dynamic Windows from Symbolics. While CLIM was
+the result of collaboration between multiple Lisp companies, DUIM was the
+work of Harlequin and drew heavily upon the CLIM design.
+
+DUIM is the basis for the Open Dylan IDE. Unfortunately, only the Windows
+backend for DUIM remains functional.
+
+DUIM documentation can be found amongst the `Open Dylan documentation
+<../documentation/>`_.
+
+Deuce
+-----
+
+Scott McKay also worked on the Deuce editor that was used in the DylanWorks
+IDE. He wrote about it briefly in a `newsgroup posting
+<https://groups.google.com/forum/#!msg/comp.lang.dylan/3uuUb3Z9pAc/6NbE9gYpeAIJ>`_.
+Bruce Mitchener also wrote briefly about the architecture of Deuce on the
+`Atom editor discussion forums <http://web.archive.org/web/20210407151341/https://discuss.atom.io/t/the-deuce-editor-architecture/2218>`_.
+
+Memory Pool System
+------------------
+
+The `Memory Pool System <https://www.ravenbrook.com/project/mps>`_ garbage
+collector was originally written for DylanWorks and subsequently re-used
+in other projects. It lives on today as a separate product (and is still
+used by Open Dylan).
+
+Harlequin's Demise
+------------------
+
+Unfortunately, for a variety of reasons, Harlequin fell upon hard times.
+A group of Harlequin employees started a company **Functional Objects**
+and re-named **Harlequin DylanWorks** to **Functional Developer** and
+attempted to continue the development.
+
+Open Sourcing
+-------------
+
+In 2004, **Functional Objects** decided to open source the **Functional
+Developer** code. It was adopted by an open source community and renamed
+**Open Dylan**. Open Dylan development continues today.
+
+Gwydion Dylan
+=============
+
+In 1993, Carnegie Mellon University kicked off a project to create a
+new Dylan implementation, the Gwydion Project. The team at CMU had
+previously done extensive work in the Lisp field including work on
+`Spice Lisp <https://en.wikipedia.org/wiki/Spice_Lisp>`_ which evolved
+into `CMUCL <https://en.wikipedia.org/wiki/CMU_Common_Lisp>`_.  This
+team was led by `Scott Fahlman <https://en.wikipedia.org/wiki/Scott_Fahlman>`_.
+
+Mindy
+-----
+
+The Gwydion team first produced a Dylan environment known as **Mindy**
+or **Mindy Is Not Dylan Yet**. This compiler was used to bootstrap
+the subsequent d2c compiler and supported a subset of the full
+Dylan language. Notably, it did not support macros.
+
+d2c
+---
+
+The Gwydion team's main Dylan implementation work was focused on
+**d2c**, an optimizing Dylan compiler that generated C code which
+could then be compiled to native code.
+
+Gwydion's Demise
+----------------
+
+The Gwydion team ceased their work on Dylan due to lack of funding
+and other concerns.
+
+Scott Fahlman announced that Dylan was in the hands of Harlequin
+in a `September 1998 newsgroup post <https://groups.google.com/forum/embed/#!topic/comp.lang.dylan/h1Hs6Jm-rb4>`_.
+
+The Gywdion Dylan implementation at that point had already been
+picked up by an open source community, led by Eric Kidd and
+Andreas Bogk.
+
+Open Source
+===========
+
+In the late 1990s, a group of programmers took over the maintenance
+and development of the Gwydion Dylan implementation. They continued
+this development for almost 15 years until the Gwydion Dylan compiler
+was retired in favor of a focus on the Open Dylan compiler.
+
+The Open Dylan compiler was the result of the open sourcing of the
+Functional Developer (previously Harlequin DylanWorks) compiler in
+2004. Development on Open Dylan continued in parallel with Gwydion
+Dylan until 2012, when it became the focus of the Dylan hackers.
+
+Other Implementations
+=====================
+
+Over the years, there have been a variety of other Dylan implementations.
+
+* In 1992, Digital Equipment Corporation (DEC) had an implementation,
+  Thomas, of the original prefix Dylan, written in Scheme, running
+  on top of Gambit Scheme.
+  One of the authors wrote about his `experiences with creating Thomas
+  <https://groups.csail.mit.edu/mac/ftpdir/scheme-mail/HTML/rrrs-1992/msg00197.html>`_.
+* In 1994, Jonathan Bachrach had an implementation written on top of
+  CMUCL using a set of macros. This implementation has been lost.
+* The `Marlais <http://marlais.sourceforge.net/>`_ implementation was
+  abandoned in 2001.
+* Dominique Boucher wrote `IDyl <https://github.com/schemeway/idyl>`_,
+  a Dylan interpreter in Scheme in the mid-1990s.
+* RScheme is Scheme-like language perhaps inspired by Dylan. There was
+  some interest in Dylan from UTexas and Paul R. Wilson, but it isn't
+  clear from the remaining historical data what exactly happened.
+
+.. toctree::
+   :hidden:
+
+   apple-dylan/index
diff --git a/documentation/website/source/index.rst b/documentation/website/source/index.rst
new file mode 100644
index 0000000000..c5ba028b2d
--- /dev/null
+++ b/documentation/website/source/index.rst
@@ -0,0 +1,110 @@
+:hide-toc:
+
+**********
+Open Dylan
+**********
+
+..
+   TODO: either reference
+   https://blog.codecentric.de/en/2015/08/essence-of-object-functional-programming-practical-potential-of-scala/
+   or better, write up our own description of object functional.
+
+.. raw:: html
+
+   <div style="font-style: italic; margin-left: 50px; margin-right: 50px">
+
+Dylan is an :doc:`object-functional <about/examples/generic_functions>`
+language originally :doc:`created by Apple <history/index>` for the
+Newton. Dylan is a direct descendant of Scheme and CLOS (without the Lisp
+syntax) with a programming model designed to support efficient machine code
+generation, including fine-grained control over dynamic and static behaviors.
+
+.. raw:: html
+
+   </div>
+
+New to Dylan?  We recommend starting with the :doc:`Tour of Dylan
+<about/index>`, a quick (30 minute) overview of the language, and/or stop by
+and ask questions on `Matrix`_.
+
+If you want to play around without having to install anything, try out the
+`Playground`_. It has a fixed set of imports so you don't have to worry about
+how to define libraries and modules right away.
+
+Then move on to one of these in-depth guides:
+
+* :doc:`intro-dylan/source/index` provides a high-level overview of language
+  features.
+* `Dylan Programming Guide`_ is a book length Dylan tutorial.
+
+The `Dylan Reference Manual`_, besides being the official language definition,
+has an excellent, very brief `introduction
+<books/drm/Introduction>`_ describing the language
+background and goals.
+
+Or explore :doc:`all the docs <documentation/index>`, including cheat sheets,
+articles, and all the library docs.
+
+.. raw:: html
+
+   <style>
+   .button,a.button {
+       background-color: #EA8D2F;
+       /* border-radius: 5px; */
+       border: none;
+       cursor: pointer;
+       display: inline-block;
+       font-size: 18px;
+       font-style: bold;
+       color: white;
+       margin: 20px 2px;
+       padding: 10px 32px;
+       text-align: center;
+       text-decoration: none;
+   }
+   </style>
+   <center>
+     <a href="download/" class="button">Install Dylan...</a>
+     &nbsp;&nbsp;&nbsp;&nbsp;
+     <a href="https://play.opendylan.org" class="button">Try Dylan in your browser</a>
+   </center>
+
+*Happy hacking!*
+
+.. _Dylan Programming Guide: https://opendylan.org/books/dpg/
+.. _Dylan Reference Manual: https://opendylan.org/books/drm/
+.. _Dylan: books/drm/Title
+.. _Matrix: https://app.element.io/#/room/#dylan-language:matrix.org
+.. _Playground: https://play.opendylan.org
+
+.. toctree::
+   :caption: Community
+   :hidden:
+
+   Get Involved <community/index>
+   Download <download/index>
+   Hacker Guide <hacker-guide/source/index>
+   Enhancement Proposals <proposals/index>
+
+.. toctree::
+   :caption: Learning
+   :hidden:
+
+   Tour of Dylan <about/index>
+   Getting Started Guide <getting-started-cli/source/index>
+   Dylan Programming Guide <https://opendylan.org/books/dpg/>
+   Dylan Playground <https://play.opendylan.org>
+
+.. Note that the package/index reference below is not part of this
+   repository; it's generated by the gendoc library, which (obviously)
+   must be run before `make html`.
+
+.. toctree::
+   :caption: Reference
+   :hidden:
+
+   Dylan Reference Manual <https://opendylan.org/books/drm/>
+   Package Docs <package/index>
+   Open Dylan Libraries <library-reference/source/index>
+   All Documentation <documentation/index>
+   Full Index <genindex>
diff --git a/documentation/website/source/intro-dylan b/documentation/website/source/intro-dylan
new file mode 120000
index 0000000000..4f0deb3c07
--- /dev/null
+++ b/documentation/website/source/intro-dylan
@@ -0,0 +1 @@
+../_packages/opendylan/current/src/documentation/intro-dylan
\ No newline at end of file
diff --git a/documentation/website/source/library-reference b/documentation/website/source/library-reference
new file mode 120000
index 0000000000..4dc98c401e
--- /dev/null
+++ b/documentation/website/source/library-reference
@@ -0,0 +1 @@
+../_packages/opendylan/current/src/documentation/library-reference
\ No newline at end of file
diff --git a/documentation/website/source/man-pages b/documentation/website/source/man-pages
new file mode 120000
index 0000000000..5660795678
--- /dev/null
+++ b/documentation/website/source/man-pages
@@ -0,0 +1 @@
+../_packages/opendylan/current/src/documentation/man-pages
\ No newline at end of file
diff --git a/documentation/website/source/news/2011/11/22/new_documentation.rst b/documentation/website/source/news/2011/11/22/new_documentation.rst
new file mode 100644
index 0000000000..5cd138b54b
--- /dev/null
+++ b/documentation/website/source/news/2011/11/22/new_documentation.rst
@@ -0,0 +1,35 @@
+:orphan:
+
+:Author: Bruce Mitchener
+:Date: 2011-11-22 12:00:00
+
+New Documentation
+=================
+
+For a long time, our documentation has been in poor condition. Much of it
+was originally in Framemaker in the 1990s and then automatically converted
+to HTML.  This had left it in a form that was very difficult to maintain
+and we haven't been able to provide our documentation in all of the formats
+that we'd like (HTML Help on Windows, ePub, PDF, etc).
+
+After some research, we're in the process of moving our documentation to
+`Sphinx`_.  Sphinx is used very widely in the Python world and uses
+ReStructured Text as the input format.  This has proven pretty easy to
+work with and should greatly reduce the barrier to contributing.
+
+As part of this, the documentation has moved back within the Open Dylan
+repository in the `documentation`_ directory where it can be built
+right along side the compiler and runtime.
+
+We're also writing some new extensions to Sphinx to handle Dylan specific
+constructs, make it easier to document Dylan code and link to the DRM. These
+extensions can be found in the `sphinx-extensions`_ repo on GitHub.
+
+There will still be a fair bit of work to update and improve the
+documentation, but this should prove much easier now that we have
+it in a modern format that we all can work with!
+
+.. _Sphinx: https://www.sphinx-doc.org/en/master/
+.. _documentation: https://github.com/dylan-lang/opendylan/tree/master/documentation
+.. _sphinx-extensions: https://github.com/dylan-lang/sphinx-extensions
+
diff --git a/documentation/website/source/news/2011/11/22/welcome.rst b/documentation/website/source/news/2011/11/22/welcome.rst
new file mode 100644
index 0000000000..0b06ef4321
--- /dev/null
+++ b/documentation/website/source/news/2011/11/22/welcome.rst
@@ -0,0 +1,11 @@
+:orphan:
+
+:Author: Bruce Mitchener
+:Date: 2011-11-22 00:00:00
+
+Welcome to the new website!
+===========================
+
+As part of recharging Open Dylan development, we’ve re-done the website and cleaned up a lot of the old, out-dated material here.
+
+If you’re looking for some of the old material, it can be found over at `http://old.opendylan.org/ <http://web.archive.org/web/20170313134206/http://old.opendylan.org/>`_.
diff --git a/documentation/website/source/news/2011/12/10/new_release.rst b/documentation/website/source/news/2011/12/10/new_release.rst
new file mode 100644
index 0000000000..83d601debb
--- /dev/null
+++ b/documentation/website/source/news/2011/12/10/new_release.rst
@@ -0,0 +1,189 @@
+:orphan:
+:Author: Hannes Mehnert
+:Date: 2011-12-10 02:00:00
+
+Open Dylan 2011.1 released
+==========================
+
+Dear Dylan Hacker,
+
+It is a pleasure for us to finally announce a release of Open Dylan.
+
+The last release with an announcement was beta4, in April 2007. Since
+then we have decided to use another versioning scheme: $year.$count;
+this release version is 2011.1.  We will be doing more regular
+releases and are already hard at work on 2012.1 for next month!
+
+One of the most important changes from the last four years is that the
+remaining rights holders of Functional Objects (the original
+developers of what became Open Dylan) agreed to re-license all of
+their code for the compiler and runtime libraries under the MIT
+license.
+
+We have also moved to GitHub:
+
+    https://github.com/dylan-lang/
+
+Another big effort was made to decrease the size of the code base in
+order to improve its maintainability. In this release, compared to
+(the unannounced) beta5, we removed about 1/3 of the code base, from
+1,200,000 lines of code down to 850,000 (according to
+https://www.openhub.net/p/open-dylan).
+
+This is the first joint release on all major platforms:
+
+- Windows (32-bit only, this is the only platform with the IDE right now, native back-end)
+- Mac OS X (32-bit, Intel (10.6+) and PPC (10.5) using the C back-end)
+- Linux (32-bit (with the native back-end) and 64-bit (with the C back-end))
+- FreeBSD (32-bit only, native back-end)
+
+The C back-end currently does not support multi-threaded programs.
+
+We also developed a SLIME (https://common-lisp.net/project/slime/)
+back-end, so you can develop in Emacs and get cross references, M-.
+and arguments.
+
+The library functional-dylan has been phased out. It was mainly
+importing and exporting dylan and common-dylan. Use dylan or
+common-dylan as appropriate.
+
+The release also includes several bug fixes and improves error
+reporting.  However, many bugs and issues with error reporting
+remain. Please report problems that you have in our issue tracker:
+
+    https://github.com/dylan-lang/opendylan/issues
+
+You can get it from our website, https://opendylan.org/download/ .
+On Windows there is an installer, on UNIX systems unpack into /opt.
+
+
+Now follows a more detailed list of changes:
+
+Notable compiler changes
+========================
+
+The command-line compiler is now called dylan-compiler instead of
+minimal-console-compiler (or opendylan).
+
+The 'remove build products' command has been renamed to 'clean', which
+is more common and intuitive.
+
+We fixed the error reporting in several ways: cleanup handlers are
+called correctly now (no "Attempting to build during another build!"
+anymore). Also, when an error is caused, the reporting does not error.
+Additionally warnings and errors from subprojects are now reported
+(rather than only put into the log file).
+
+We support output of internal debug messages via a dylan-compiler
+argument (internal-debug, set to a list of debug-targets, like
+project-manager, linker,...). Additionally Harp, DFM and assembler
+output of the compiler can be written to the build directory (via
+harp, dfm, assembler command-line flags).
+
+The dylan-compiler supports -version and -shortversion flags.
+
+In Deuce, a buffer which is modified is now marked with an asterisk.
+
+On application shutdown, a list of closures is called, which can be
+registered via register-application-exit-function. Also the GC is
+properly shut down.
+
+The build system both on UNIX and Windows has lots of improvements and
+is even less code. There is no longer support to checkout code via
+CVS, though.
+
+The runtime lives in dylan-support.o, which is linked into libdylan,
+rather than a _glue.o which was emitted for every application. The
+system library contains offsets into C structures (like stat) for all
+major platforms, including 64-bit versions.
+
+The function closure-size no longer lives in dfmc-execution, but in
+dfmc-flow-graph. The library dfmc-execution was removed.
+
+
+Library Improvements
+====================
+
+We consolidated file and standard-io under the same buffered
+file-accessor. We also improved the run-application function, which
+now can spawn asynchronous processes, redirect standard-input,
+standard-output and standard-error, set the working directory and
+environment variables.
+
+If write is interrupted (by EINTR), we call write again until it has
+written all bytes.
+
+The function join now works on an empty sequence.
+
+The function position takes start and end keyword parameters, and its
+performance was improved.
+
+A new function, integer-length, is now in common-dylan.
+
+The function directory-contents now returns the contents of the
+directory.
+
+We now support a with-input-from-string macro in the streams module.
+
+A new library, ssl-network, wraps openssl and integrates into the
+already existing network library.
+
+The element-setter for the forward-iteration-protocol of
+<ordered-key-collection> has been fixed.
+
+Shift operations on machine words are inlined now.
+
+The <smtp-error> class contains a slot with the error-code.
+
+Testworks has been vastly improved, and improved test suites are
+provided for the Dylan library, common-dylan and jam.
+
+
+Mac OS X
+========
+
+The support on Mac OS X improved immensely; the code which retrieves
+the path to the running application now uses _NSGetExecutablePath.
+Also, setting environment variables is now supported on Mac OS X.  The
+system library is renamed on Mac OS X to odsystem to prevent
+interfering with the built-in System library.
+
+
+Back-ends
+=========
+
+In the native back-end we pass integer and floating point exceptions
+to the Dylan runtime on Linux and FreeBSD platforms.
+
+In the C back-end we emit volatile for all the variables inside of a
+bind-exit block which need to be volatile.
+
+We defer the back-end selection to the end of the compilation of the
+compiler to reduce the compilation time for compiler hackers.
+
+
+Removed code
+============
+
+The majority of the removed code was not used, on the one hand code
+for the LispWorks emulator, on the other hand (half-finished) support
+for outdated platforms: namely a native PPC backend, a half-finished
+Java backend; Mac OS (Classic), IRIX, SunOS, Solaris and OSF3 platform
+support.
+
+It also included the separation in three disjoint releases, basic,
+enhanced and enterprise - which was useful back when the compiler was
+developed commercially, but is no longer.
+
+The amount of applications for the command-line compiler has been
+decreased from eight to four, namely dylan-compiler, dylan-environment
+(including execution and debugging) and dylan-\*-with-tools, which
+includes the tools interface (remote debugging, scepter, OLE).
+
+Also, the old pentium-dw (DylanWorks) application was removed since it
+is no longer used and is unnecesary..
+
+We unified the dfmc-shell/command-shell and
+environment-commands/commands libraries, which are the interactive
+shell. (Previously the otherwise obsolete dfmc-shell was used in the
+interactor).
diff --git a/documentation/website/source/news/2011/12/12/dswank-screenshot.png b/documentation/website/source/news/2011/12/12/dswank-screenshot.png
new file mode 100644
index 0000000000..1ae91258cf
Binary files /dev/null and b/documentation/website/source/news/2011/12/12/dswank-screenshot.png differ
diff --git a/documentation/website/source/news/2011/12/12/dswank.rst b/documentation/website/source/news/2011/12/12/dswank.rst
new file mode 100644
index 0000000000..3c073f7269
--- /dev/null
+++ b/documentation/website/source/news/2011/12/12/dswank.rst
@@ -0,0 +1,65 @@
+:orphan:
+:Author: Hannes Mehnert
+:Date: 2011-12-12 23:30:00
+
+Development inside of Emacs using DIME
+======================================
+
+We have implemented a Dylan backend for DIME using the Open Dylan
+environment-protocols API to ease development of Dylan code on UNIX.
+At present, cross references, locating definitions, retrieving
+argument lists, compiling, warning reports and a class browser are
+implemented.
+
+.. figure:: dswank-screenshot.png
+   :align: center
+
+.. raw:: html
+
+   <center><iframe width="480" height="360" src="http://www.youtube.com/embed/SIBlnDg0USQ?rel=0" frameborder="0" allowfullscreen></iframe></center>
+
+When successfully installed, just run ``M-x dime`` to get a shell.
+This is the same as the dylan-compiler shell, you can also use the
+same commands.
+
+When you program and hit ``(`` or ``,`` or ``(space)``, you get the
+argument list of the method you are calling.
+
+``M-x dime-dylan-browse-superclasses`` will show the superclass hierarchy
+of the current class. ``M-x dime-dylan-browse-subclasses`` displays the
+subclass hierarchy.
+
++-------------------+------------------------------------------+
+| Keyboard shortcut | Effect                                   |
++===================+==========================================+
+|M-x dime           |start dime                                |
++-------------------+------------------------------------------+
+| , change-project  | select project (in the repl buffer)      |
++-------------------+------------------------------------------+
+| M-.               | jump to definition                       |
++-------------------+------------------------------------------+
+| M-,               | jump backwards                           |
++-------------------+------------------------------------------+
+| C-c C-k           | compile project                          |
++-------------------+------------------------------------------+
+| C-c C-w C-a       | who specializes?                         |
++-------------------+------------------------------------------+
+| C-c C-w C-r       | who references?                          |
++-------------------+------------------------------------------+
+| C-c C-w C-b       | who binds?                               |
++-------------------+------------------------------------------+
+| C-c C-w C-c       | who calls?                               |
++-------------------+------------------------------------------+
+
+Dswank uses the Open Dylan project registry, so make sure
+``OPEN_DYLAN_USER_REGISTRIES`` is set properly before starting Emacs.
+
+DIME is a fork of SLIME.
+
+Installation
+============
+
+You need the following pieces:
+
+   * `dylan-mode <https://github.com/dylan-lang/dylan-mode>`_, and extend your ``~/.emacs`` as documented in the README
+   * dswank itself is shipped with the 2011.1 release
diff --git a/documentation/website/source/news/2012/01/25/c3.rst b/documentation/website/source/news/2012/01/25/c3.rst
new file mode 100644
index 0000000000..5cfe7b79d2
--- /dev/null
+++ b/documentation/website/source/news/2012/01/25/c3.rst
@@ -0,0 +1,19 @@
+:orphan:
+:Author: Hannes Mehnert
+:Date: 2012-01-25 00:00:00
+
+C3 linearization
+================
+
+We implemented the C3 superclass linearization algorithm in the Open
+Dylan compiler. This is more intuitive in some corner cases, and
+allows further performance improvements, especially compression of
+dispatch tables. It has been merged into the `opendylan GitHub
+repository <https://github.com/dylan-lang/opendylan/>`_ and will be
+the default in the next release (2012.1). A serious warning will be
+issued if the new C3 linearization is different from the old
+`linearization specified in the DRM
+<https://opendylan.org/books/drm/Classes#HEADING-41-25>`_.
+
+Further information is available in `the accepted Dylan enhancement
+proposal </proposals/dep-0003-c3-linearization.html>`_.
diff --git a/documentation/website/source/news/2012/05/18/strings.rst b/documentation/website/source/news/2012/05/18/strings.rst
new file mode 100644
index 0000000000..24c30aab5b
--- /dev/null
+++ b/documentation/website/source/news/2012/05/18/strings.rst
@@ -0,0 +1,14 @@
+:orphan:
+:Author: Carl Gay
+:Date: 2012-05-18 00:00:00
+
+New Strings Library
+===================
+
+A new library of basic string operations is now available as a
+standard library.  The new `strings library
+<https://github.com/dylan-lang/strings>`_ replaces most of the code in
+the old ``string-extensions`` library and provides a simpler and more
+consistent API.  ``string-extensions`` will eventually be retired when
+the remainder of the code there is moved to the
+``regular-expressions`` library, which is its only client.
diff --git a/documentation/website/source/news/2012/10/15/command-line-parser.rst b/documentation/website/source/news/2012/10/15/command-line-parser.rst
new file mode 100644
index 0000000000..c4bed13ece
--- /dev/null
+++ b/documentation/website/source/news/2012/10/15/command-line-parser.rst
@@ -0,0 +1,18 @@
+:orphan:
+:Author: Carl Gay
+:Date: 2012-10-15 00:00:00
+
+New command-line-parser Library
+===============================
+
+The `command-line-parser
+<https://github.com/dylan-lang/command-line-parser>`_ library has been
+completely rewritten to
+
+  * be far less verbose
+  * have simplified usage
+  * have automatic support for --help
+  * be `documented </library-reference/command-line-parser/index.html>`_
+
+Testworks and the HTTP server are using the new library.  More
+enhancements coming soon.
diff --git a/documentation/website/source/news/2012/10/18/dylan-vim.png b/documentation/website/source/news/2012/10/18/dylan-vim.png
new file mode 100644
index 0000000000..212acee1b5
Binary files /dev/null and b/documentation/website/source/news/2012/10/18/dylan-vim.png differ
diff --git a/documentation/website/source/news/2012/10/18/editor-support.rst b/documentation/website/source/news/2012/10/18/editor-support.rst
new file mode 100644
index 0000000000..813aa8dd03
--- /dev/null
+++ b/documentation/website/source/news/2012/10/18/editor-support.rst
@@ -0,0 +1,53 @@
+:orphan:
+:Author: Bruce Mitchener
+:Date: 2012-10-18 00:00:00
+
+Improving Editor Support
+========================
+
+We have recently fixed some bugs in the syntax highlighting
+support for Textmate and Sublime Text as well as for vim.
+
+Sublime Text and Textmate
+-------------------------
+
+.. figure:: sublime-text.png
+   :align: right
+
+   Syntax highligting in Sublime Text
+
+Textmate and Sublime Text used the same plugin which can
+be found on GitHub at https://github.com/dylan-lang/dylan.tmbundle.
+
+* Using Open Dylan specific modifiers (``dynamic``, ``sideways``, etc)
+  won't break the highlighting.
+* ``locked`` and ``thread`` variable definitions are highlighted
+  correctly now.
+* Keyword / header highlighting at the start of a file is improved.
+
+Also, we've submitted a request for this plugin to be made
+available via Package Control for Sublime Text and hope
+that this is ready in the near future.
+
+Vim
+---
+
+.. figure:: dylan-vim.png
+   :align: right
+
+   Syntax highlighting in vim
+
+We extended the Dylan support of vim:
+
+* Improved comment handling such that all comments should
+  be highlighted correctly now.
+* Improved operator highlighting.
+* Enabled spell checking for strings, comments and headers.
+  To see this, you can toggle ``:set spell`` in vim.
+* Enabled highlighting for the built-in functions as defined
+  in the DRM.
+
+The files for vim can be found in https://github.com/dylan-lang/dylan-vim.
+
+Patches and further improvements are welcome!
+
diff --git a/documentation/website/source/news/2012/10/18/sublime-text.png b/documentation/website/source/news/2012/10/18/sublime-text.png
new file mode 100644
index 0000000000..3c29a683bd
Binary files /dev/null and b/documentation/website/source/news/2012/10/18/sublime-text.png differ
diff --git a/documentation/website/source/news/2012/12/20/new-release.rst b/documentation/website/source/news/2012/12/20/new-release.rst
new file mode 100644
index 0000000000..051393f1b4
--- /dev/null
+++ b/documentation/website/source/news/2012/12/20/new-release.rst
@@ -0,0 +1,48 @@
+:orphan:
+:Author: Bruce Mitchener, Jr.
+:Date: 2012-12-20 00:00:00
+
+Open Dylan 2012.1 released
+==========================
+
+Dear Dylan Hacker,
+
+It is a pleasure for us to finally announce a release of Open Dylan.
+
+The last release with an announcement was 2011.1, in December, 2011.
+For a variety of reasons, we didn't get to carry out our plan for
+more frequent releases in 2012, but hope to have more frequent releases
+in 2013.
+
+While we have extensive `release notes </release-notes/2012.1.html>`_,
+there are some important changes that we feel are worth calling out
+separately:
+
+* We now use the C3 superclass linearization. See `DEP-0003
+  </proposals/dep-0003-c3-linearization.html>`_ for more details.
+* Multithreading now works in the C backend.
+* Binaries and libraries built by ``dylan-compiler`` no longer have
+  their directory location hard-coded within the executables.
+* ``dylan-compiler`` places output into a local ``_build`` directory
+  and can read from a local registry rather than relying on global
+  directories.
+* Many bugs have been fixed, especially involving the usage of floats.
+* Linux and FreeBSD 32 bit builds have been updated to a new version
+  of the Memory Pool System GC which is much faster and stable.
+* A new ``strings`` library has been provided which replaces the old
+  ``strings`` and ``string-extensions`` libraries with a more consistent
+  and straightforward API. ``string-extensions`` has been removed.
+* The ``command-line-parser`` library has been cleaned up and integrated
+  with the Open Dylan distribution.
+* We no longer provide PowerPC builds of Open Dylan on Mac OS X. Also,
+  our Intel builds are for Mac OS X Lion and later. If you desire Snow
+  Leopard support, please get in touch with us.
+
+Please report problems that you have in our `issue tracker <https://github.com/dylan-lang/opendylan/issues>`_.
+
+You can get it from our website, `https://opendylan.org/download/ <https://opendylan.org/download/>`_.
+On Windows there is an installer, on UNIX systems unpack into ``/opt``.
+On 64 bit Linux, you will need to have the Boehm GC installed for our
+executables to run. (Ubuntu: ``apt-get install libgc``)
+
+Good luck and happy Dylan hacking!
diff --git a/documentation/website/source/news/2013/01/21/dylan-programming-guide.rst b/documentation/website/source/news/2013/01/21/dylan-programming-guide.rst
new file mode 100644
index 0000000000..f9c7844693
--- /dev/null
+++ b/documentation/website/source/news/2013/01/21/dylan-programming-guide.rst
@@ -0,0 +1,39 @@
+:orphan:
+:Author: Bruce Mitchener, Jr.
+:Date: 2013-01-21 00:00:00
+
+Dylan Programming Guide
+=======================
+
+The `Dylan Programming Guide`_ has been updated to
+use our new documentation format.  As a result it is
+now available in `PDF`_ and `ePub`_ formats as well
+as much improved HTML.
+
+The Dylan Programming Guide is a great introduction
+to programming in Dylan and was written by Neil
+Feinberg, Sonya E. Keene, Robert O. Matthews, and
+P. Tucker Withington while they were employed by
+Harlequin in the 1990s.  The book covers everything
+from the basics up through advanced concepts such as
+Dylan macros and the condition system.
+
+This was exported from the 1996-era Framemaker files
+and largely reformatted by hand.  During this work,
+we also rewrote the lexer used in `Pygments`_ for
+processing and syntax highlighting Dylan source code.
+This new lexer will be available in the upcoming
+Pygments 1.6.
+
+In the future, we will add some errata to the book to
+address some of the changes that have happened since
+the book was originally published.
+
+We hope that this will be helpful in introducing a
+new generation of programmers to the Dylan programming
+language.
+
+.. _Dylan Programming Guide: https://opendylan.org/books/dpg/
+.. _PDF: https://opendylan.org/books/dpg/DylanProgramming.pdf
+.. _ePub: https://opendylan.org/books/dpg/DylanProgramming.epub
+.. _Pygments: https://pygments.org/
diff --git a/documentation/website/source/news/2013/06/30/dylan-hack-a-thon.rst b/documentation/website/source/news/2013/06/30/dylan-hack-a-thon.rst
new file mode 100644
index 0000000000..b5c4083e7f
--- /dev/null
+++ b/documentation/website/source/news/2013/06/30/dylan-hack-a-thon.rst
@@ -0,0 +1,31 @@
+:orphan:
+:Author: Bruce Mitchener, Jr.
+:Date: 2013-06-30 00:00:00
+
+Dylan Hack-a-thon: July 13-14, 2013
+===================================
+
+We are hosting our first online hack-a-thon in many
+years on July 13-14, 2013.
+
+No matter if you know Dylan or not, we can help you
+`learn Dylan`_ or put your other skills to use. We've
+got a good `list of tasks`_ that we're collecting
+and some people will bring their own Dylan-related
+projects. If you're a complete newcomer to Dylan,
+we're willing to help you get a build installed and
+get started.
+
+If you're interested and have some questions or would
+just like to let us know that you're coming, feel
+free to `contact us on IRC or via email`_.
+
+We are currently expecting attendees from North America,
+Europe, South East Asia and perhaps New Zealand.
+
+We look forward to seeing you there!
+
+
+.. _learn Dylan: https://opendylan.org/books/dpg/
+.. _list of tasks: https://github.com/dylan-lang/opendylan/wiki
+.. _contact us on IRC or via email: https://opendylan.org/community/index.html
diff --git a/documentation/website/source/news/2013/07/11/new-release.rst b/documentation/website/source/news/2013/07/11/new-release.rst
new file mode 100644
index 0000000000..73f051b7f4
--- /dev/null
+++ b/documentation/website/source/news/2013/07/11/new-release.rst
@@ -0,0 +1,35 @@
+:orphan:
+:Author: Bruce Mitchener, Jr.
+:Date: 2013-07-11 00:00:00
+
+Open Dylan 2013.1 released
+==========================
+
+Dear Dylan Hacker,
+
+It is a pleasure for us to announce a new release of Open Dylan.
+
+We have extensive `release notes </release-notes/2013.1.html>`_,
+but this release has been about iterative improvement rather than major changes.
+
+* A deadlock when using threads on x86-linux has been addressed.
+* A crash when using threads on x86-linux has also been addressed.
+* A crash from memory corruption on Mac OS X has been fixed.
+* Some errors in how the Windows Registry was used have been corrected.
+* There have been significant improvements to the documentation.
+* A licensing issue with an unacknowledged copyright has been corrected.
+
+Please report problems that you have in our `issue tracker <https://github.com/dylan-lang/opendylan/issues>`_.
+
+You can get it from our website, `https://opendylan.org/download/ <https://opendylan.org/download/>`_.
+On Windows there is an installer, on UNIX systems unpack into ``/opt``.
+On 64 bit Linux, you will need to have the Boehm GC installed for our
+executables to run. (Ubuntu: ``apt-get install libgc``)
+
+Also, remember that this weekend, July 13-14 is our `hack-a-thon`_ and we hope that you'll consider participating.
+You may also sign up for the hack-a-thon at our `Google Plus event page`_.
+
+Good luck and happy Dylan hacking!
+
+.. _hack-a-thon: https://opendylan.org/news/2013/06/30/dylan-hack-a-thon.html
+.. _Google Plus event page: https://accounts.google.com/ServiceLogin?passive=1209600&osid=1&continue=https://plus.google.com/&followup=https://plus.google.com/
diff --git a/documentation/website/source/news/2013/08/15/duim-gtk.png b/documentation/website/source/news/2013/08/15/duim-gtk.png
new file mode 100644
index 0000000000..95ca2629f7
Binary files /dev/null and b/documentation/website/source/news/2013/08/15/duim-gtk.png differ
diff --git a/documentation/website/source/news/2013/08/15/duim-gtk.rst b/documentation/website/source/news/2013/08/15/duim-gtk.rst
new file mode 100644
index 0000000000..53f52c3c43
--- /dev/null
+++ b/documentation/website/source/news/2013/08/15/duim-gtk.rst
@@ -0,0 +1,43 @@
+:orphan:
+:Author: Bruce Mitchener, Jr.
+:Date: 2013-08-15 00:00:00
+
+Bringing back DUIM/Gtk
+======================
+
+.. figure:: duim-gtk.png
+   :align: right
+
+Lately, we've been working on bringing back DUIM's GTK+ back-end.
+
+`DUIM`_ is Dylan's user interface framework. While it was
+originally cross-platform, the only back-end that works now
+is for Windows.  Bringing back the GTK+ back-end and completing
+it will enable us to support Linux, FreeBSD and perhaps Mac OS X.
+
+This is a great first step towards making the `IDE`_ more widely
+available. Apart from being able to use the IDE on additional
+platforms, which is great in and of itself, having the IDE available to
+more of us makes it easier to fix bugs and improve the functionality
+as most of us aren't working on the Windows platform.
+
+So far, we have a new set of GTK+ bindings for GTK+ 3.x available
+in `sources/gtk`_ and have begun the work to update the old
+`DUIM GTK+`_ back-end and make further improvements.
+
+At this point, we would welcome some assistance. There are
+further improvements to make to the GTK+ bindings and a lot of
+work to do on DUIM/Gtk. (We have started building a
+`list of bugs`_.) We've also started to collect some notes
+for the `hacker's guide`_, especially for working on Mac OS X.
+
+If you're interested in learning more or helping out, get
+in touch with us on `chat or the mailing list`_!
+
+.. _DUIM: /building-with-duim/index.html
+.. _IDE: /getting-started-ide/index.html
+.. _sources/gtk: https://github.com/dylan-lang/opendylan/tree/master/sources/gtk
+.. _DUIM GTK+: https://github.com/dylan-lang/opendylan/tree/master/sources/duim/gtk
+.. _list of bugs: https://github.com/dylan-lang/opendylan/labels/lib-DUIM%20%2F%20Gtk
+.. _hacker's guide: /hacker-guide/duim/index.html
+.. _chat or the mailing list: /community/
diff --git a/documentation/website/source/news/2013/12/23/new-release.rst b/documentation/website/source/news/2013/12/23/new-release.rst
new file mode 100644
index 0000000000..2dd46a0fa0
--- /dev/null
+++ b/documentation/website/source/news/2013/12/23/new-release.rst
@@ -0,0 +1,33 @@
+:orphan:
+:Author: Bruce Mitchener, Jr.
+:Date: 2013-12-23 00:00:00
+
+Open Dylan 2013.2 released
+==========================
+
+Dear Dylan Hacker,
+
+It is a pleasure for us to announce a new release of Open Dylan.
+
+Dylan is a multi-paradigm functional and object-oriented programming language. It is dynamic while providing a programming model designed to support efficient machine code generation, including fine-grained control over dynamic and static behaviors.
+
+For more information on Open Dylan, see our `website <https://opendylan.org/>`_ and our `documentation <https://opendylan.org/documentation/>`_.
+
+We have extensive `release notes <https://opendylan.org/documentation/release-notes/2013.2.html>`_,
+but this release has been about iterative improvement rather than major changes.
+
+* Testworks has seen substantial improvements.
+* Streams now default to being unlocked.
+* We've begun to work on improving cross-compilation.
+* Logging and hash-algorithms libraries have been added to the core release.
+* Common Dylan has improved timers (simple-timers) replacing the old compiler primitives.
+* Documentation has been improved.
+
+Please report problems that you have in our `issue tracker <https://github.com/dylan-lang/opendylan/issues>`_.
+
+You can get it from our website, `https://opendylan.org/download/ <https://opendylan.org/download/>`_.
+On Windows there is an installer, on UNIX systems unpack into ``/opt``.
+On 64 bit Linux, you will need to have the Boehm GC installed for our
+executables to run. (Ubuntu: ``apt-get install libgc``)
+
+Good luck and happy Dylan hacking!
diff --git a/documentation/website/source/news/2014/01/28/call-for-help.rst b/documentation/website/source/news/2014/01/28/call-for-help.rst
new file mode 100644
index 0000000000..4b759b3845
--- /dev/null
+++ b/documentation/website/source/news/2014/01/28/call-for-help.rst
@@ -0,0 +1,165 @@
+:orphan:
+:Author: Bruce Mitchener, Jr.
+:Date: 2014-01-28 00:00:00
+
+A Call For Help
+===============
+
+Dylan is a multi-paradigm functional and object-oriented programming
+language. It is dynamic while providing a programming model designed
+to support efficient machine code generation, including fine-grained
+control over dynamic and static behaviors.
+
+Dylan is (and was) a vision of a different world: one with the
+flexibility of Smalltalk, the power of Lisp, while still allowing
+for compilation to efficient code.
+
+During the 1990s, multiple teams of people at Apple, Carnegie Mellon
+University, and Harlequin (defunct makers of LispWorks, now a product
+of Xanalys) created and worked on Dylan for many years. Dylan fell by
+the wayside when its sponsoring organizations ran into financial
+troubles, and has been maintained by an open source project over the
+last decade as "Open Dylan".
+
+Open Dylan is the open source adaptation of the commercial Dylan
+tools that were developed at Harlequin. Open Dylan has a very sophisticated
+compiler, tools and IDE (although the IDE and some of the tools are
+currently Windows only). These tools were truly amazing for their
+time. Open Dylan is preserving, maintaining, and enhancing this
+powerful programming language.
+
+We believe that Dylan has value in terms of the history behind it,
+the philosophy of the language design, and the unique perspective
+it provides for solving modern-day software engineering problems.
+The Open Dylan project brings all of these capabilities together
+in a free, open-source project that anyone can use.
+
+Learn how to get started with Dylan by visiting
+https://opendylan.org/download/.
+
+----------
+
+We have a number of projects where we currently lack the knowledge,
+experience, or available people to begin or complete them. This
+isn't to say that we've been idle! We've been improving performance
+of our core libraries, optimizing our `HTTP`_ code, creating a
+stand-alone `binary-data`_ library and many other things.
+
+We're making a call to the community of interested people to say
+that we're more than willing to help people get started with
+Dylan and to help deal with problems that arise in the course of
+making progress on some of our open projects.
+
+We have a `partial list of open projects`_ in our wiki, but we'd like
+to call special attention to a subset of them.
+
+If you're interested in any of the below, please `get in touch`_ with
+us via our mailing list, IRC or ping us on `Twitter`_.  If none of
+the projects below sound interesting, feel free to check out the list
+on the wiki to see the others.
+
+Read on to see how you can help!
+
+Cocoa Bindings
+--------------
+
+We've recently made substantial progress on our Objective C / Dylan
+bridge and the development branch of our compiler will soon support
+sending Objective C messages. With this, we can begin to wrap the
+Mac OS X Objective C APIs, in particular those for creating GUI
+applications.
+
+Our current Objective C bridge lets us do things like:
+
+.. code-block:: dylan
+
+  let c = objc/get-class("NSObject");
+  let s = objc/register-selector("alloc");
+  let o
+    = primitive-wrap-machine-word
+        (%objc-msgsend (c.as-raw-class, s.as-raw-selector)
+           () => (obj :: <raw-machine-word>)
+           ()
+         end);
+
+We will make this simpler and provide bindings for core Cocoa
+libraries so that programming experience is more pleasurable
+and less verbose.
+
+DUIM
+----
+
+DUIM is the Dylan User Interface Manager. It is a cross-platform
+GUI library that inherits some of the design from Common Lisp's CLIM
+and descends from the Symbolics Open Genera Lisp Machine OS.
+
+Despite being built to be cross-platform, the only currently fully
+functional backend for DUIM is the Windows version.
+
+Improving DUIM and making it available on additional operating
+systems is key to the future of the Open Dylan IDE (which is
+currently only available on Windows).
+
+DUIM/Windows
+~~~~~~~~~~~~
+
+DUIM currently runs on Windows, but it is quite dated and doesn't
+fully respect modern interface standards. The port needs to be
+updated to properly use the theming mechanisms available.
+
+DUIM/Cocoa
+~~~~~~~~~~
+
+We would like to have a Cocoa backend to DUIM. This work has
+not yet been started and would need to progress in parallel with
+the creation of Cocoa bindings for Dylan.
+
+DUIM/Gtk
+~~~~~~~~
+
+We have a good start on a GTK+ backend to DUIM in the Open Dylan
+repository, but it needs a good bit of work, especially from
+someone that knows GTK+ well.
+
+Extensive work was done in this area during the summer of 2013,
+when we created a full set of bindings for GTK+-3.0 and related
+APIs.
+
+Code Mirror Editor Support
+--------------------------
+
+Code Mirror is a great editor that runs in the web browser. It is written
+in JavaScript and supports over 60 languages. It is also a key element
+of the `Light Table IDE`_.
+
+We'd like to have `Code Mirror`_ support for Dylan. This would initially
+involve correcting our existing syntax highlighting and then moving
+into further improvements like supporting auto-indentation and other
+Code Mirror features.
+
+This would involve writing JavaScript code.
+
+Networking Library
+------------------
+
+We need to add IPv6 support to our networking library.
+
+Packaging
+---------
+
+We need assistance with packaging on pretty much every operating
+system / distribution apart from FreeBSD, Gentoo Linux and ArchLinux.
+We would particularly appreciate support in producing Debian, Ubuntu,
+and Mac OS X Homebrew packages.
+
+Our Windows installer also needs some support, particularly in the
+bundling of the PellesC compiler to improve the first time experience
+for Windows users.
+
+.. _HTTP: https://github.com/dylan-lang/http
+.. _binary-data: https://github.com/dylan-lang/binary-data
+.. _partial list of open projects: https://github.com/dylan-lang/opendylan/wiki
+.. _get in touch: https://opendylan.org/community/
+.. _Twitter: https://twitter.com/DylanLanguage
+.. _Code Mirror: https://codemirror.net/
+.. _Light Table IDE: http://lighttable.com/
diff --git a/documentation/website/source/news/2014/05/28/nix-packages-available.rst b/documentation/website/source/news/2014/05/28/nix-packages-available.rst
new file mode 100644
index 0000000000..52d5441216
--- /dev/null
+++ b/documentation/website/source/news/2014/05/28/nix-packages-available.rst
@@ -0,0 +1,45 @@
+:orphan:
+:Author: Chris Double
+:Date: 2014-05-28 00:00:00
+
+Nix Packages Available
+======================
+
+Open Dylan builds have been added to the `Nix package manager`_.
+This makes Open Dylan installable from systems using Nix, or the
+`NixOS Linux distribution`_, using a command like::
+
+    nix-env -i opendylan
+
+This will download the Open Dylan binaries and use that to bootstrap a
+build from source.
+
+Nix is a purely functional package manager. Different versions of
+packages can be installed at the same time and packages can depend on
+different versions of other packages. The management of these versions
+is handled behind the scenes by the package manager using symbolic
+links. This enables doing things like installing multiple Open Dylan
+versions at the same time for testing. It's possible to set up custom
+Nix definitions for different Dylan versions and test bootstrapping
+with each version with some changes to the user Nix configuration
+files.
+
+Another nice feature of Nix is that it avoids polluting the user
+environment with packages that are used by Open Dylan but not required
+for the end user. For example, ``gcc``, ``mps`` and ``boehmgc`` are used by
+Open Dylan but they are not visible to the user after installing the
+Open Dylan package via Nix. The ``PATH`` for ``dylan-compiler`` has these
+available for internal usage but the ``PATH`` for the users profile does
+not.
+
+Chris Double's `pull request to add Open Dylan`_ was merged and
+should be available now in the ``unstable`` Nix channel. You will
+need to be on the ``unstable`` channel and update with ``nix-channel --update``
+to be able to install Open Dylan.
+
+Many thanks to Chris Double for his work on this!
+
+
+.. _Nix package manager: https://nixos.org/
+.. _NixOS Linux distribution: https://nixos.org/
+.. _pull request to add Open Dylan: https://github.com/NixOS/nixpkgs/pull/2770
diff --git a/documentation/website/source/news/2015/01/01/new-release.rst b/documentation/website/source/news/2015/01/01/new-release.rst
new file mode 100644
index 0000000000..74479c9521
--- /dev/null
+++ b/documentation/website/source/news/2015/01/01/new-release.rst
@@ -0,0 +1,36 @@
+:orphan:
+:Author: Bruce Mitchener, Jr.
+:Date: 2015-01-01 00:00:00
+
+Open Dylan 2014.1 released
+==========================
+
+Dear Dylan Hacker,
+
+It is a pleasure for us to announce a new release of Open Dylan.
+
+Dylan is a multi-paradigm functional and object-oriented programming language. It is dynamic while providing a programming model designed to support efficient machine code generation, including fine-grained control over dynamic and static behaviors.
+
+For more information on Open Dylan, see our `website <https://opendylan.org/>`_ and our `documentation <https://opendylan.org/documentation/>`_.
+
+We have extensive `release notes <https://opendylan.org/documentation/release-notes/2014.1.html>`_, but highlights include:
+
+* bash completion scripts are available.
+* The foundation of an Objective C / Dylan bridge has been integrated with the compiler.
+  This enables using the `objc-dylan <https://github.com/dylan-foundry/objc-dylan>`_ library.
+* Passing structs by value using C-FFI now works on both the C and HARP back-ends.
+* Performance improvements have been made to various libraries.
+* Laying the groundwork for LLVM compiler back-end support to arrive in 2015.
+* Laying the groundwork for improving our Unicode support.
+* Many other miscellaneous fixes and improvements.
+
+Please report problems that you have in our `issue tracker <https://github.com/dylan-lang/opendylan/issues>`_.
+
+You can get it from our website, `https://opendylan.org/download/ <https://opendylan.org/download/>`_.
+On Windows there is an installer, on UNIX systems unpack into ``/opt``.
+On 64 bit Linux, you will need to have the Boehm GC installed for our
+executables to run. (Ubuntu: ``apt-get install libgc``)
+
+Our plan is to have a first release of Open Dylan with an LLVM-backed compiler back-end within the next couple of months as our 2015.1 release. Here's hoping we can make that happen!
+
+Good luck and happy Dylan hacking!
diff --git a/documentation/website/source/news/2019/03/31/new-release.rst b/documentation/website/source/news/2019/03/31/new-release.rst
new file mode 100644
index 0000000000..084a87e0ac
--- /dev/null
+++ b/documentation/website/source/news/2019/03/31/new-release.rst
@@ -0,0 +1,39 @@
+:orphan:
+:Author: Carl Gay
+:Date: 2019-03-31 00:00:00
+
+Open Dylan 2019.1 Released
+==========================
+
+Posted on 31 March 2019
+
+Dear Dylan Hacker,
+
+It is a pleasure for us to announce a new release of Open Dylan.
+
+Dylan is a multi-paradigm functional and object-oriented programming
+language. It is dynamic while providing a programming model designed to support
+efficient machine code generation, including fine-grained control over dynamic
+and static behaviors.
+
+Although there are many changes in this release, the main highlight is that the
+**LLVM back-end**, which uses LLVM 7.x or later for code generation, is now
+full-featured and mature on i386 and x86_64 Linux, FreeBSD, and macOS
+platforms.  Other highlights include:
+
+* A backtrace is printed when the program exits due to an unhandled error.
+* Linking is faster, with a new ``-jobs`` option to use multiple processes.
+* Compiler warning improvements, including colorized output.
+* Optimizations to limited integer types.
+* Support for building C++ code as part of a Dylan project.
+* A new ``lldb`` wrapper script that preloads the Dylan integration scripts.
+* Run-time primitives to aid in profiling and event logging.
+
+For full details on changes in this release see the `release notes
+<https://opendylan.org/documentation/release-notes/2019.1.html>`_, or go
+directly to the `download page <https://opendylan.org/download/index.html>`_.
+
+For more information on Open Dylan, see our `website <https://opendylan.org/>`_
+and our `documentation <https://opendylan.org/documentation/>`_.
+
+Good luck and happy Dylan hacking!
diff --git a/documentation/website/source/news/2020/10/10/new-release.rst b/documentation/website/source/news/2020/10/10/new-release.rst
new file mode 100644
index 0000000000..ab60d5a5d5
--- /dev/null
+++ b/documentation/website/source/news/2020/10/10/new-release.rst
@@ -0,0 +1,47 @@
+:orphan:
+:Author: Carl Gay
+:Date: 2020-10-10 00:00:00
+
+Open Dylan 2020.1 Released
+==========================
+
+Posted on 10 October 2020
+
+Dear Dylan Hacker,
+
+It is a pleasure for us to announce a new release of Open Dylan.
+
+Some highlights in this release:
+
+* This is our first release with "batteries included". The binary distributions
+  contain all necessary dependent libraries, including clang, libunwind, and
+  libgc, making installation much easier.
+
+* The LLVM back-end is now the default back-end. Its performance is 30% to 40%
+  better than the C or HARP back-ends.
+
+* The LLVM back-end now tracks function inlining in generated debug
+  information, allowing breakpoints to be set in inlined code.
+
+* Platforms: The AArch64 (64-bit ARM) platform is now supported on Linux.
+
+* The compiler now displays a text mode progress bar during the compilation and
+  link phases. (The new progress-stream library also is available for users.)
+
+* Network: A deadlock that occurred when shutting down listening socket threads
+  has been fixed.
+
+* IO: A number of bugs in the locators library were fixed, ``resolve-locator``
+  was added, and various definitions in the print module were documented.
+
+* Testworks now generates reports in JSON format, along with other Testworks
+  improvements.
+
+For full details on changes in this release see the `release notes
+<https://opendylan.org/documentation/release-notes/2020.1.html>`_, or go
+directly to the `download page <https://opendylan.org/download/index.html>`_.
+
+For more information on Open Dylan, see our `website <https://opendylan.org/>`_
+and our `documentation <https://opendylan.org/documentation/>`_.
+
+Good luck and happy Dylan hacking!
diff --git a/documentation/website/source/news/2020/12/30/playground.rst b/documentation/website/source/news/2020/12/30/playground.rst
new file mode 100644
index 0000000000..a1a0a9034c
--- /dev/null
+++ b/documentation/website/source/news/2020/12/30/playground.rst
@@ -0,0 +1,12 @@
+:orphan:
+:Author: Carl Gay
+:Date: 2020-12-30 00:00:00
+
+Dylan Playground Launched
+=========================
+
+Posted on 30 December 2020
+
+The Dylan web playground is now available at `play.opendylan.org
+<https://play.opendylan.org>`_, making it easy to try out small examples and
+share them with others.  Enjoy!
diff --git a/documentation/website/source/news/2022/11/28/new-release.rst b/documentation/website/source/news/2022/11/28/new-release.rst
new file mode 100644
index 0000000000..824d3dd0ca
--- /dev/null
+++ b/documentation/website/source/news/2022/11/28/new-release.rst
@@ -0,0 +1,41 @@
+:orphan:
+:Author: Carl Gay
+:Date: 2022-11-28 00:00:00
+
+Open Dylan 2022.1 Released
+==========================
+
+Posted on 28 November 2022
+
+Dear Dylan Hacker,
+
+It is a pleasure for us to announce a new release of Open Dylan.
+
+Some highlights in this release:
+
+* This release comes with "batteries included". The binary distributions
+  contain all necessary dependent libraries, including clang, libunwind, and
+  libgc, making installation much easier.
+
+* Support has been added for linking executable Dylan libraries and all of
+  their dependencies into a single unified executable using the ``-unify``
+  build option.
+
+* A new `dylan <https://github.com/dylan-lang/dylan-tool>`_ tool manages Dylan
+  workspaces. It provides a centralized catalog of Dylan packages and a way to
+  manage dependencies without resorting to Git submodules or needing to
+  manually create registry files.
+
+* The 64-bit RISC-V architecture (rv64gc ISA) is now supported on Linux.
+
+* Updates to various libraries included with Open Dylan: collections, io,
+  system, ssl, testworks.
+
+For full details on changes in this release see the `release notes
+<https://opendylan.org/documentation/release-notes/2022.1.html>`_, or go
+directly to the `download page <https://opendylan.org/download/index.html>`_.
+
+For more information on Open Dylan, see our `website <https://opendylan.org/>`_
+and our `documentation <https://opendylan.org/documentation/>`_.
+
+Good luck and happy Dylan hacking!
diff --git a/documentation/website/source/news/index.rst b/documentation/website/source/news/index.rst
new file mode 100644
index 0000000000..786fe96202
--- /dev/null
+++ b/documentation/website/source/news/index.rst
@@ -0,0 +1,227 @@
+****
+News
+****
+
+Significant events in the Open Dylan space...
+
+
+Release 2023.1
+==============
+
+**2023-07-19** Release 2023.1 is now available! A few highlights...
+
+* Updated versions of LLVM and the BDW garbage collector.
+* New ``"""multi-line"""`` and ``#r"raw"`` string literals (`DEP 12
+  <../proposals/dep-0012-string-literals.rst>`_).
+* The :doc:`dylan <../package/dylan-tool/index>` tool continues to evolve with
+  a new, simplified workspace model.
+* Bug fixes for json, command-line-parser, system, and others.
+
+See the `release notes <../release-notes/2023.1.rst>`_ for more details.
+
+
+New website
+===========
+
+**2023-07-07** - The opendylan.org website has had a long overdue major
+overhaul. The goals of this revamp were:
+
+1. Better navigation. For example, when reading documentation in the Library
+   Reference it should be easy to navigate to the Hacker Guide or package
+   docs. Now everything is accessible from the left sidebar.
+
+#. Better accessibility. The old site had a very low contrast top navbar and
+   other low contrast elements. The new `Furo
+   <https://pradyunsg.me/furo/quickstart/>`_ theme has much better contrast
+   plus light and dark themes.
+
+#. Local table of contents in the right sidebar. Hooray `Furo
+   <https://pradyunsg.me/furo/quickstart/>`_!
+
+#. Integrated :doc:`package docs <../package/index>`.
+
+#. Simplicity! We're a small team so we want to avoid any extra maintenance
+   burden. To that end, we no longer use a Dylan-specific Sphinx theme or
+   templates. If it ain't in `Furo <https://pradyunsg.me/furo/quickstart/>`_,
+   we don't want it! :-)
+
+We'd love to hear feedback on the new site. You can `file a bug
+<https://github.com/dylan-lang/website/issues>`_ or `drop us a note on Matrix
+<https://app.element.io/#/room/#dylan-language:matrix.org>`_.
+
+
+Release 2022.1
+==============
+
+**2022-11-28** - :doc:`New release: 2022.1 </news/2022/11/28/new-release>`
+
+
+Dylan Playground
+================
+
+**2020-12-30** - :doc:`Dylan Playground Launched </news/2020/12/30/playground>`
+
+
+Release 2020.1
+==============
+
+**2020-10-10** - :doc:`New release: 2020.1 </news/2020/10/10/new-release>`
+
+
+Release 2019.1
+==============
+
+**2019-03-31** - :doc:`New release: 2019.1 </news/2019/03/31/new-release>`
+
+
+Release 2014.1
+==============
+
+**2015-01-01** - :doc:`New release: 2014.1 </news/2015/01/01/new-release>`
+
+
+Nix Packages
+============
+
+**2014-05-28** - :doc:`Nix Packages Available
+</news/2014/05/28/nix-packages-available>`
+
+Open Dylan builds have been added to the `Nix package manager`_.  This makes
+Open Dylan installable from systems using Nix, or the `NixOS Linux
+distribution`_.
+
+.. _Nix package manager: https://nixos.org/
+.. _NixOS Linux distribution: https://nixos.org/
+
+Release 2013.2
+==============
+
+**2013-12-23** - :doc:`New release: 2013.2 </news/2013/12/23/new-release>`
+
+
+DUIM/Gtx
+========
+
+**2013-08-15** - :doc:`Bringing Back DUIM/Gtk </news/2013/08/15/duim-gtk>`
+
+We're bringing back the GTK+ backend for DUIM, the Dylan UI framework.  See how
+you can help!
+
+
+Release 2013.1
+==============
+
+**2013-07-11** - :doc:`New release: 2013.1 </news/2013/07/11/new-release>`
+
+We just released Open Dylan 2013.1 in preparation for the hack-a-thon.
+
+
+Hack-a-thon
+===========
+
+**2013-06-30** - :doc:`Dylan Hack-a-thon: July 13-14, 2013
+</news/2013/06/30/dylan-hack-a-thon>`
+
+No matter if you know Dylan or not, we can help you `learn Dylan
+<https://opendylan.org/books/dpg/>`_ or put your other skills to use. We've got
+a good `list of tasks <https://github.com/dylan-lang/opendylan/wiki>`_ that
+we're collecting and some people will bring their own Dylan-related projects.
+
+
+Updated Dylan Programming Guide
+===============================
+
+**2013-01-21** - :doc:`Updated Dylan Programming Guide
+</news/2013/01/21/dylan-programming-guide>`
+
+The Dylan Programming Guide has been updated to our new documentation format
+and is now available in PDF and ePub formats.
+
+
+Release 2012.1
+==============
+
+**2012-12-20** - :doc:`New release: 2012.1 </news/2012/12/20/new-release>`
+
+We just released Open Dylan 2012.1. This release brings many bugfixes, improved
+platform support and new features.
+
+
+Improved editor support
+=======================
+
+**2012-10-18** - :doc:`Improved editor support </news/2012/10/18/editor-support>`
+
+Bugs in the syntax highlighting support for Textmate and Sublime Text as well
+as for vim have been fixed.
+
+
+command-line-parser
+===================
+
+**2012-10-15** - :doc:`command-line-parser library </news/2012/10/15/command-line-parser>`
+
+The `command-line-parser <https://github.com/dylan-lang/command-line-parser>`_
+library has been completely rewritten.
+
+
+New strings Library
+===================
+
+**2012-05-18** - :doc:`New strings library </news/2012/05/18/strings>`
+
+A new library of basic string operations is now available as a standard
+library.
+
+
+C3 Linearization
+================
+
+**2012-01-25** - :doc:`C3 superclass linearization </news/2012/01/25/c3>`
+
+Open Dylan now uses the C3 superclass linearization algorithm. It is enabled
+by default. This is more intuitive and will allow for further performance
+improvements.
+
+
+DSWANK
+======
+
+**2011-12-12** - :doc:`Dswank - emacs and DIME </news/2011/12/12/dswank>`
+
+We developed DIME, the Dylan interaction mode for emacs, based on SLIME. Now,
+you can browse the class hierarchy, get argument lists, locate definitions,
+compile, view warnings and more, all from within emacs!
+
+
+Release 2011.1
+==============
+
+**2011-12-10** - :doc:`New release: 2011.1 </news/2011/12/10/new_release>`
+
+We just released Open Dylan 2011.1. This release is our first since moving to
+GitHub and relicensing under a more liberal license. It brings many bugfixes,
+inmproved platform support and new features.
+
+
+New documentation
+=================
+
+**2011-11-22** - :doc:`New Documentation </news/2011/11/22/new_documentation>`
+
+We're revitalizing our documentation and moving to a new publishing
+system. We'll soon be able to provide our documentation in PDF and ePub as well
+as HTML, with it looking much better and being more maintainable than in the
+past.
+
+
+New website
+===========
+
+**2011-11-22** - :doc:`Welcome to the New Website! </news/2011/11/22/welcome>`
+
+As part of recharging Open Dylan development, we've re-done the website and
+cleaned up a lot of the old, out-dated material here.
+
+If you're looking for some of the old material, it can be found over at
+`<https://web.archive.org/web/20170313134206/http://old.opendylan.org/>`_.
diff --git a/documentation/website/source/news/recent.rst.inc b/documentation/website/source/news/recent.rst.inc
new file mode 100644
index 0000000000..60e6185fd3
--- /dev/null
+++ b/documentation/website/source/news/recent.rst.inc
@@ -0,0 +1,5 @@
+:doc:`New release: 2022.1 </news/2022/11/28/new-release>` *- 2022-11-28*
+  Open Dylan 2022.1 released.
+
+:doc:`Dylan Playground Launched </news/2020/12/30/playground>` *- 2020-12-30*
+  Try Dylan in your web browser.
diff --git a/documentation/website/source/proposals/dep-0001-dep-process.rst b/documentation/website/source/proposals/dep-0001-dep-process.rst
new file mode 100644
index 0000000000..18cb512b0c
--- /dev/null
+++ b/documentation/website/source/proposals/dep-0001-dep-process.rst
@@ -0,0 +1,508 @@
+**************************
+DEP Purpose and Guidelines
+**************************
+
+==============  =============================================
+DEP Number:     1
+Type:           Process
+Author:         Carl Gay
+Status:         Active
+Created:        07-Jan-2012
+Last-Modified:  16-Jan-2012
+Post-History:   16-Jan-2012, 10-Jan-2012
+==============  =============================================
+
+
+Preamble
+========
+
+This document is based heavily on Python `PEP 1
+<https://www.python.org/dev/peps/pep-0001/>`_, "PEP Purpose and
+Guidelines", by Barry Warsaw, Jeremy Hylton, and David Goodger.  The
+author would like to thank them for providing an excellent base for
+the Dylan team to work from.
+
+
+Terminology
+===========
+
+Dylan Reference Manual (DRM)
+    The manual written by Andrew Shalit, plus its errata.
+
+Dylan language specification
+    The DRM *plus* all **Accepted** DEPs that modify the Dylan
+    language specification.
+
+Open Dylan (OD)
+    The reference implementation of the Dylan language specification.
+
+Standard libraries
+    The set of libraries that are officially maintained alongside Open
+    Dylan.  They are officially maintained in the following sense:
+
+      * Commits are reviewed for bugs and style.
+      * They are tested prior to each OD release.
+      * They are packaged with each OD release.
+
+
+What is a DEP?
+==============
+
+DEP stands for Dylan Enhancement Proposal.  A DEP is a design document
+which
+
+  * provides information to the Dylan community, or
+  * describes a new feature for the Dylan language or its standard
+    libraries, or
+  * describes changes to the processes or environment surrounding
+    the Dylan language or Open Dylan.
+
+The DEP should provide a concise technical specification of, and
+rationale for, the feature or process.
+
+We intend DEPs to be the primary mechanism for proposing new
+features, for collecting community input on an issue, and for
+documenting the design decisions that have gone into Dylan.  The DEP
+author is responsible for building consensus within the community and
+documenting dissenting opinions.
+
+Because the DEPs are maintained as text files in a versioned
+repository, their revision history is the historical record of the
+feature proposal [1]_.
+
+
+DEP Types
+=========
+
+There are three kinds of DEP:
+
+1. A **Standards Track** DEP describes a new feature or implementation
+   for Dylan or its standard libraries.
+
+2. An **Informational** DEP describes a Dylan design issue, or
+   provides general guidelines or information to the Dylan community,
+   but does not propose a new feature.  Informational DEPs do not
+   necessarily represent a Dylan community consensus or
+   recommendation, so users and implementors are free to ignore
+   Informational DEPs or follow their advice.
+
+3. A **Process** DEP describes a process surrounding Dylan, or
+   proposes a change to (or an event in) a process.  Process DEPs are
+   like Standards Track DEPs but apply to areas other than the Dylan
+   language itself.  They may propose an implementation, but not to
+   Dylan's codebase; they often require community consensus; unlike
+   Informational DEPs, they are more than recommendations, and users
+   are typically not free to ignore them.  Examples include
+   procedures, guidelines, changes to the decision-making process, and
+   changes to the tools or environment used in Dylan development.
+   Any meta-DEP is also considered a Process DEP.
+
+
+DEP Work Flow
+=============
+
+**Have an idea** -- The DEP process begins with a new idea for Dylan.
+It is highly recommended that a single DEP contain a **single key
+proposal** or new idea. Small enhancements or patches often don't need
+a DEP and can be injected into the Dylan development work flow with a
+pull request to the issue tracker for the appropriate repository on
+GitHub. The more focused the DEP, the more successful it tends to be.
+If in doubt, split your DEP into several well-focused ones.
+
+**Have an author** -- Each DEP must have an author -- someone who
+writes the DEP using the style and format described below, shepherds
+the discussions in the appropriate forums, and attempts to build
+community consensus around the idea.  The DEP author should first
+attempt to ascertain whether the idea is DEP-able.  Posting to
+dylan-lang@googlegroups.com is the best way to go about this.
+
+**Vet the idea publicly** -- Vetting an idea publicly before going as
+far as writing a DEP is meant to save the potential author time.  Many
+ideas have been brought forward for changing Dylan that have been
+rejected for various reasons. Asking the Dylan community first if an
+idea is original helps prevent too much time being spent on something
+that is guaranteed to be rejected based on prior discussions
+(searching the internet does not always do the trick). It also helps
+to make sure the idea is applicable to the entire community and not
+just the author.  Just because an idea sounds good to the author does
+not mean it will work for most people in most areas where Dylan is
+used.
+
+**Present a draft** -- Once the author has asked the Dylan community
+whether an idea has any chance of acceptance, a properly formatted
+draft DEP should be presented to dylan-lang@googlegroups.com.  The
+initial DEP status should be **Draft**.  The DEP author should assign
+the next available DEP number to the DEP by looking at the :doc:`DEP
+directory <index>` to find the highest used number.  The DEP
+number is not assured until the DEP has been committed to the `origin
+Git repository
+<https://github.com/dylan-lang/website/tree/master/source/proposals>`_.
+As updates are necessary, the DEP author may commit new versions.
+
+Wait for at least ten days to receive feedback on each draft.
+
+**Reach consensus** -- We rely on reaching consensus on the
+dylan-lang@googlegroups.com mailing list.  Consensus *must* be
+reached for the DEP to be approved.  Exactly what "consensus" means
+here is left undefined, as we expect most cases to be obvious and we
+wish to keep the process informal for now.  At such time as this
+becomes a problem we may implement a more formal scheme (e.g.,
+voting).
+
+Standards Track DEPs consist of two parts, a design document and a
+reference implementation.  The DEP should be reviewed and accepted
+before a reference implementation is begun, unless a reference
+implementation will aid people in studying the DEP.  Standards Track
+DEPs must include an implementation -- in the form of a Git branch URL
+-- before it can be considered Final.
+
+DEP authors are responsible for collecting community feedback on a DEP
+before submitting it for review. However, wherever possible, long
+open-ended discussions on public mailing lists should be avoided.
+Strategies to keep the discussions efficient include: setting up a
+separate mailing list for the topic, having the DEP author accept
+private comments in the early design phases, setting up a wiki page,
+etc.  DEP authors should use their discretion here.
+
+For a DEP to be **Accepted** it must meet certain minimum criteria.  It
+must be a clear and complete description of the proposed enhancement.
+The enhancement must represent a net improvement.  The proposed
+implementation, if applicable, must be solid and must not unduly add
+complication.
+
+Once a DEP has been accepted, the reference implementation must be
+completed.  When the reference implementation is complete and accepted
+by the community, the status may be changed to **Final**.
+
+A DEP can also be assigned status **Deferred**.  The DEP author or
+editor can assign the DEP this status when no progress is being made
+on the DEP.  Once a DEP is deferred, the DEP editor can re-assign it
+to draft status.
+
+A DEP can also be **Rejected**.  Perhaps after all is said and done it
+was not a good idea.  It is still important to have a record of this
+fact.
+
+DEPs can also be **Superseded-By** a different DEP, rendering the original
+obsolete.  This is intended for Informational DEPs, where version 2 of
+an API can replace version 1.
+
+The possible paths of the status of DEPs are as follows:
+
+.. image:: ../_static/dep-0001-states.png
+
+Some Informational and Process DEPs may also have a status of
+**Active** if they are never meant to be completed.  E.g. DEP 1 (this
+DEP).
+
+
+What belongs in a successful DEP?
+=================================
+
+Each DEP should have the following parts:
+
+1. Title
+
+#. Preamble -- RFC 822 style headers containing meta-data about the
+   DEP, including the DEP number, a short descriptive title (limited
+   to a maximum of 44 characters), the names, and optionally the
+   contact info for each author, etc.
+
+#. Abstract -- a short (~200 word) description of the technical issue
+   being addressed.
+
+#. Copyright/public domain -- Each DEP must either be explicitly
+   labelled as placed in the public domain (see this DEP as an
+   example) or licensed under the `Open Publication License`_.
+
+#. Specification -- The technical specification should describe the
+   syntax and semantics of any new language or library feature.  The
+   specification should be detailed enough to allow competing,
+   interoperable Dylan implementations.  If the DEP proposes changes
+   to the language itself it *must* clearly indicate all such changes.
+
+#. Motivation -- The motivation is critical for DEPs that want to
+   change the Dylan language.  It should clearly explain why the
+   existing language specification is inadequate to address the
+   problem that the DEP solves.
+
+#. Rationale -- The rationale fleshes out the specification by
+   describing what motivated the design and why particular design
+   decisions were made.  It should describe alternate designs that
+   were considered and related work, e.g. how the feature is supported
+   in other languages.
+
+   The rationale should provide evidence of consensus within the
+   community and discuss important objections or concerns raised
+   during discussion.
+
+#. Backwards Compatibility -- All DEPs that introduce backwards
+   incompatibilities must include a section describing these
+   incompatibilities and their severity.  The DEP must explain how the
+   author proposes to deal with these incompatibilities.
+
+#. Reference Implementation -- The reference implementation must be
+   completed before any DEP is given status "Final", but it need not
+   be completed before the DEP is accepted.  It is better to finish
+   the specification and rationale first and reach consensus on it
+   before writing code.
+
+   The final implementation must include good test code and
+   documentation.
+
+
+DEP Format and Templates
+========================
+
+DEPs must be written in ReStructuredText_ format.  This allows for
+rich markup that is still quite easy to read, but results in much
+better-looking and more functional HTML.
+
+.. DEP 12 contains instructions and a template [4]_ for
+   reStructuredText DEPs.
+
+The DEP author must verify that the ReStructuredText_ parses correctly.
+For example::
+
+    git clone git@github.com:dylan-lang/website.git
+    cd website
+    cp your-dep.rst source/proposals/dep-1234.rst
+    make html
+
+Fix any errors that are displayed.
+
+
+DEP Header Preamble
+===================
+
+Each DEP must begin with a title, followed by an RFC 822 style header
+preamble in simple RST table format.  The headers must appear in the
+following order.  Headers marked with "*" are optional and are
+described below.  All other headers are required.  All dates must be
+in dd-mmm-yyyy format (e.g., 14-Jan-2012).  A list of values must use
+a comma as separator.  ::
+
+    DEP-Number: <DEP number>
+    Author: <list of authors' real names and optionally, email addresses>
+    Status: <Draft | Active | Accepted | Deferred | Rejected |
+             Withdrawn | Final | Superseded>
+    Type: <Standards Track | Informational | Process>
+    Affects-DRM: <Yes | No>
+    Created: <date created>
+    Last-Modified: <date last modified>
+    Post-History: <date(s) of postings to hackers list>
+  * Resolution: <url>
+  * Target-Version: <OD version number>
+  * Requires: <DEP number(s)>
+  * Replaces: <DEP number(s)>
+  * Superseded-By: <DEP number>
+
+DEP Number
+~~~~~~~~~~
+
+Authors may assign DEP numbers themselves by looking at the last
+number in the `numerical list of DEPs
+<https://opendylan.org/proposals/index.html>`_ and incrementing it by
+one.  To prevent collisions, the author should set the ``DEP-Number``
+header to "Unassigned" until just before the DEP is committed to git.
+
+Author
+~~~~~~
+
+The Author header lists the names, and optionally the email addresses
+of all the authors/owners of the DEP.  The format of the Author header
+value must be
+
+    Random J. User <address@dom.ain>
+
+if the email address is included, and just
+
+    Random J. User
+
+if the address is not given.
+
+If there are multiple authors, each should be on a separate line
+following RFC 2822 continuation line conventions.
+
+.. Not yet: Note that personal email addresses in DEPs will be
+   obscured as a defense against spam harvesters.
+
+Status
+~~~~~~
+
+See `DEP Work Flow`_ for a description of this field.
+
+Type
+~~~~
+
+The Type header specifies the type of DEP: Standards Track,
+Informational, or Process.
+
+Affects-DRM
+~~~~~~~~~~~
+
+This field is only required for Standards Track DEPs.  The value
+should be **Yes** if the DEP proposes a change to the Dylan language
+definition, and otherwise **No**.  The language definition is composed
+of the Dylan Reference Manual plus any **Accepted** DEPs for which
+this field is **Yes**.  If this field is set to **Yes** then the DEP
+*must* clearly list exactly how it affects the language definition.
+
+Created
+~~~~~~~
+
+The Created header records the date that the DEP was assigned a
+number.
+
+Last-Modified
+~~~~~~~~~~~~~
+
+The Last-Modified header is included because it may be useful to those
+reading DEPs without access to git.  It should be updated when
+substantive changes are made to the DEP.  It need not be updated when
+fixing typos, changed URLs, etc.
+
+Post-History
+~~~~~~~~~~~~
+
+This field should list the dates when DEP drafts were posted to the
+hackers mailing list.  List the dates from newest to oldest.
+
+Resolution
+~~~~~~~~~~
+
+The Resolution header is required for Standards Track DEPs only.  It
+contains a URL that should point to an email message or other web
+resource where the pronouncement about the DEP is made.
+
+Target-Version
+~~~~~~~~~~~~~~
+
+Standards Track DEPs must have a Target-Version header which indicates
+the version of Open Dylan in which the feature will be released.
+Informational and Process DEPs do not need a Target-Version header.
+
+Requires
+~~~~~~~~
+
+DEPs may have a Requires header, indicating the DEP numbers that this
+DEP depends on.
+
+Superseded-By and Replaces
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+DEPs may also have a Superseded-By header indicating that they have
+been rendered obsolete by a later document; the value is the number of
+the DEP that replaces the current document.  The newer DEP must have a
+Replaces header containing the number of the DEP that it rendered
+obsolete.
+
+
+Auxiliary Files
+===============
+
+DEPs may include auxiliary files such as diagrams.  Such files must be
+named ``dep-XXXX-aaaa.ext``, where "XXXX" is the DEP number (padded
+with leading zeros), "aaaa" is arbitrary text to indicate the file
+content (e.g., "state-diagram"), and "ext" is replaced by the actual
+file extension (e.g. "png").
+
+
+Reporting DEP Bugs, or Submitting DEP Updates
+=============================================
+
+How you report a bug, or submit a DEP update depends on several
+factors, such as the maturity of the DEP, the preferences of the DEP
+author, and the nature of your comments.  For the early draft stages
+of the DEP, it's probably best to send your comments and changes
+directly to the DEP author.  For more mature, or finished DEPs you may
+want to submit corrections to the Dylan issue tracker [2]_ so that your
+changes don't get lost.  Assign the bug/patch to the DEP author.
+
+When in doubt about where to send your changes, please check first
+with the DEP author.
+
+DEP authors who are also Dylan committers can update the DEPs
+themselves committing them to Git and pushing to the main repository.
+
+
+DEP Author Responsibilities & Workflow
+======================================
+
+A DEP author must subscribe to the <dylan-lang@googlegroups.com>
+list.  Before submitting a (new revision of a DEP) the author must do
+the following:
+
+* Read the DEP to check if it is ready, sound, and complete.  The ideas
+  must make technical sense, even if they don't seem likely to be
+  accepted.
+
+* The title should accurately describe the content.
+
+* Edit the DEP for language (spelling, grammar, sentence structure,
+  etc.), markup, and code style.
+
+Once the DEP is ready for the repository, the DEP author will:
+
+* Assign the next available DEP number.
+
+* List the DEP in the DEP index (in two places: the categorized list,
+  and the numeric list).
+
+* Add the DEP to Git.  All DEPs live in `the website repository
+  <https://github.com/dylan-lang/website>`_.  The command to check
+  it out is::
+
+    git clone https://github.com/dylan-lang/website
+
+  Commit your changes, push them to your fork of the repository and
+  submit a pull request.
+
+* Monitor `opendylan.org <https://opendylan.org>`_ to make sure the DEP
+  gets added to the site properly.
+
+Resources:
+
+* See the section `For Open Dylan Developers
+  <https://opendylan.org/documentation/index.html>`_ on the opendylan.org
+  documentation page.
+
+.. It would be nice to have equivalents for some of these:
+
+    * `How Dylan is Developed <http://www.python.org/dev/intro/>`_
+
+    * `Dylan's Development Process <http://www.python.org/dev/process/>`_
+
+    * `Why Develop Dylan? <http://www.python.org/dev/why/>`_
+
+    * `Development Tools <http://www.python.org/dev/tools/>`_
+
+    * `Frequently Asked Questions for Developers
+      <http://www.python.org/dev/faq/>`_
+
+
+References and Footnotes
+========================
+
+.. [1] This historical record is available by the normal Git commands
+   for retrieving older revisions.  For those without direct access to
+   Git, you can browse the current and past DEP revisions here:
+   https://github.com/dylan-lang/website/tree/master/source/proposals
+
+.. [2] Which issue tracker to use will depend on the content of the
+   DEP.  For language changes, changes to Open Dylan, or changes to
+   "core" libraries it will usually be `opendylan
+   <https://github.com/dylan-lang/opendylan/issues>`_.  For other
+   libraries there may be a separate repository and issue tracker.
+   This is still in flux.  When in doubt, ask in IRC on the #dylan
+   channel or on the hackers list.
+
+.. _Open Publication License: http://www.opencontent.org/openpub/
+
+.. _reStructuredText: https://web.archive.org/web/20120114014252/https://docutils.sourceforge.net/rst.html
+
+
+Copyright
+=========
+
+This document has been placed in the public domain.
diff --git a/documentation/website/source/proposals/dep-0002-define-function.rst b/documentation/website/source/proposals/dep-0002-define-function.rst
new file mode 100644
index 0000000000..822f103451
--- /dev/null
+++ b/documentation/website/source/proposals/dep-0002-define-function.rst
@@ -0,0 +1,149 @@
+***************
+Define Function
+***************
+
+==============  =============================================
+DEP #:          2
+Type:           Standards Track
+Affects-DRM:    Yes
+Author:         Bill Chiles
+Status:         Accepted
+Created:        26-Jan-1996
+Last-Modified:  26-Jan-1996
+Post-History:   None
+==============  =============================================
+
+*Note: This DEP was converted from the old Dylan Change Proposal
+Format to DEP format with minimal changes for ReStructuredText.  It
+does not fully conform to the new format.*
+
+Specification
+=============
+
+   Add a "define function" defining macro that creates a constant
+   binding in the current module and initializes it to a new function.
+   The new defining macro has the following syntax::
+
+      DEFINE { adjective }* FUNCTION name parameter-list
+        [ body ] 
+      END [ FUNCTION ] [ name ]
+
+   The adjectives allowed are implementation dependent.  The parameter
+   list describes the number and types of the arguments that the
+   function accepts, and the number and types of the values it returns.
+   It is an error to supply #next in the parameter list, and there is
+   no implicit #next parameter.
+
+   Using reflective operations on "define function" functions:
+
+      (1) For the following functions an implementation may choose to 
+          return a meaningful result (or perform a meaningful side-effect
+          operation), or the implementation may signal an error::
+
+            generic-function-methods, add-method, find-method, 
+            generic-function-mandatory-keywords, remove-method, 
+            sorted-applicable-methods, applicable-method?
+
+          Note, the error signalled might not be a <sealed-object-error>,
+          and this implementation choice holds for a "define function"
+          function that is passed as either argument to add-method and
+          remove-method.
+
+      (2) The following functions return the same values as they would 
+          for a bare method defined with the same signature::
+
+            function-specializers, function-arguments, 
+            function-return-values 
+
+   "Define function" could be added either to the core language or to a
+   library.
+
+Rationale
+=========
+
+   Many programmers desire a way to define a function that clearly
+   says to other programmers that the function is not part of any
+   generic operation; furthermore, the function won't be extended as a
+   generic function, and calling it need not involve any generic
+   dispatch.  The two main choices in current practice are:
+
+   .. code-block:: dylan
+
+     define constant cube = method (x) x * x * x end;
+
+     define method cube (x) x * x * x end;
+
+   The first choice is clumsy because it makes it hard to distinguish
+   function constants from non-function constants.  The second choice
+   does not make it clear that this is the only method for the
+   function.  The "define function" proposal gives everybody one
+   simple way to express their intent.  The expansion of the macro is
+   left unspecified so that Dylan implementations have latitude to
+   support it in the best way suited to the implementation.
+
+   This proposal defines the behavior of applicable-method? when called 
+   on "define function" functions based on new wording that describes
+   applicable-method? in the DRM.
+
+Examples
+========
+
+   An example use:
+
+   .. code-block:: dylan
+
+     define function cube (x) x * x * x end;
+
+   Below is one possible implementation of the macro.  This implementation
+   supports whatever adjectives are supported by "define constant".
+   Other implementations are possible.
+
+   .. code-block:: dylan
+
+     define macro function-definer
+         { define ?adjectives:* function ?name:name 
+              ?signature-and-body:* end }
+         => { define ?adjectives constant ?name = method 
+              ?signature-and-body end }
+     end macro function-definer;
+
+Cost to Implementors
+====================
+
+   The cost is very little, essentially a macro definition and exporting
+   the identifier for the macro.  An implementation may also want to
+   annotate the function's name in the compiler's database to indicate
+   that the function should not be extended (or added to a generic
+   function if it is a method), signalling appropriate errors or
+   protecting compiler optimizations based on assumptions about the
+   function.
+
+Revision History
+================
+::
+
+   Version 1; Harlequin, Inc.; Bill Chiles; 26 JAN 96.
+      Initial proposal with input from a few people.
+   Version 2; Harlequin, Inc.; Bill Chiles; 01 FEB 96.
+      New specification of reflective operations on functions.
+      Replaces rationale text for the specification of reflective 
+         operations with one sentences about applicable-method?.
+      Strengthens #next restriction by saying there is no implicit 
+         #next argument.
+      Removes controversial macro example.
+   Version 3; Harlequin, Inc.; Bill Chiles; 08 FEB 96.
+      Described "define function" defining macro without reference to 
+         "define method".
+   Version 4; Harlequin, Inc.; Peter Norvig 13 MAR 96.
+      Changed format to meet the new Dylan Change Proposal Format.  
+      Added two possible macro implementations.
+   Version 5; Kim Barrett 31 Dec 1996
+      Removed incorrect example macro definition which used "define method"
+      in the expansion.  (Incorrect because it introduces an implicit binding
+      of a variable named "next-method" around the body, which is counter to
+      the specified contract for this macro.)
+
+Status
+======
+
+   Accepted 31 December 1996
diff --git a/documentation/website/source/proposals/dep-0003-c3-linearization.rst b/documentation/website/source/proposals/dep-0003-c3-linearization.rst
new file mode 100644
index 0000000000..39003663f3
--- /dev/null
+++ b/documentation/website/source/proposals/dep-0003-c3-linearization.rst
@@ -0,0 +1,140 @@
+***************************
+C3 superclass linearization
+***************************
+
+===============  =============================================
+DEP-Number:      3
+Type:            Standards Track
+Affects-DRM:     Yes
+Author:          Hannes Mehnert
+Status:          Accepted
+Created:         09-Jan-2012
+Last-Modified:   09-Jan-2012
+Post-History:    09-Jan-2012
+Target-Version:  2012.1
+===============  =============================================
+
+
+Abstract
+========
+
+The Dylan superclass linearization is sometimes counter-intuitive. The
+C3 superclass linearization algorithm is more intuitive and allows for
+greater optimization.
+
+Copyright
+=========
+
+This DEP is public domain.
+
+Specification
+=============
+
+The C3 superclass linearization has been proposed in 1996 by Kim
+Barrett, Bob Cassels, Paul Haahr, David A. Moon, Keith Playford, and
+P. Tucker Withington in a `paper
+<https://dl.acm.org/doi/10.1145/236337.236343>`_ (`html version
+<https://web.archive.org/web/20120415074347/http://haahr.tempdomainname.com/dylan/linearization-oopsla96.html>`_).
+
+A superclass linearization (also known as a class precedence list) is
+used for resolving conflicts among multiply-inherited superclasses
+which provide differing definitions of the same method.
+
+Unfortunately the algorithm presented in the Dylan Reference Manual
+(`computing the class precedence list
+<https://opendylan.org/books/drm/Classes#HEADING-41-25>`_) is not
+consistent with the extended precedence graph, and may lead to
+counter-intuitive linearizations. To fix that, the C3 linearization
+was developed.
+
+Motivation
+==========
+
+In order to allow for more optimizations, especially compression of
+dispatch tables, which requires monotonicity of method orderings, a
+consistent superclass linearization algorithm is needed.
+
+After the C3 linearization was proposed in 1996, it was subsequently
+adapted in Python 2.3 (`article <https://www.python.org/download/releases/2.3/mro/>`__)
+and Perl 6 (`article
+<https://web.archive.org/web/20150216030253/http://use.perl.org/use.perl.org/_autrijus/journal/25768.html>`__).
+
+Rationale
+=========
+
+The C3 linearization has been around for a long time, does not break
+any existing code, and is commonly agreed upon as being the right thing
+to do (in mailing list discussions).
+
+Examples
+========
+
+The example from the paper is given here, consider the following Dylan classes:
+
+.. code-block:: dylan
+
+    define class <pane> (<object>) end;
+    define class <scrolling-mixin> (<object>) end;
+    define class <editing-mixin> (<object>) end;
+    define class <scrollable-pane> (<pane>, <scrolling-mixin>) end;
+    define class <editable-pane> (<pane>, <editing-mixin>) end;
+    define class <editable-scrollable-pane> (<scrollable-pane>, <editable-pane>) end;
+
+
+The Dylan linearization is:
+
+.. code-block:: dylan
+
+    <editable-scrollable-pane>, <scrollable-pane>, <editable-pane>, <pane>, <editing-mixin>, <scrolling-mixin>, <object>
+
+The C3 linearization is:
+
+.. code-block:: dylan
+
+    <editable-scrollable-pane>, <scrollable-pane>, <editable-pane>, <pane>, <scrolling-mixin>, <editing-mixin>, <object>
+
+The difference in the ordering of ``<scrolling-mixin>`` and
+``<editing-mixin>`` and having that match the ordering of
+``<scrollable-pane>`` and ``<editable-pane>`` is clearly
+more intuitive and consistent.
+
+Backwards Compatibility
+=======================
+
+In the first release a serious warning will be issued for superclass
+linearization which changed, in subsequent releases a warning should
+be issued (depending on a strict compatibility to DRM switch).
+
+Experiments show that there are some differences in existing code; we
+found so far three, two of them in duim-gadgets, one in
+win32-duim. According to Scott McKay, the author of DUIM, the first
+two look better when C3 is used (`mailing list post
+<https://web.archive.org/web/20160324145817/https://lists.opendylan.org/pipermail/hackers/2012-January/006309.html>`_). The
+latter does not alter behaviour (`post
+<https://web.archive.org/web/20160324142050/https://lists.opendylan.org/pipermail/hackers/2012-January/006310.html>`_).
+
+The class precedence list of <row-splitter-pane> differ, Dylan:
+    #(<row-splitter-pane>, <row-splitter>, <splitter>, <single-child-wrapping-pane>, <cached-space-requirement-mixin>, <client-overridability-mixin>, <wrapping-layout-mixin>, <composite-layout-mixin>, <layout-mixin>, <layout>, <single-child-mixin>, <basic-sheet>, <sheet>, <basic-gadget>, <gadget>, <abstract-gadget>, <abstract-sheet>, <event-handler>, <object>); 
+C3:
+    #(<row-splitter-pane>, <row-splitter>, <splitter>, <single-child-wrapping-pane>, <cached-space-requirement-mixin>, <client-overridability-mixin>, <wrapping-layout-mixin>, <composite-layout-mixin>, <layout-mixin>, <layout>, <basic-gadget>, <gadget>, <abstract-gadget>, <single-child-mixin>, <basic-sheet>, <sheet>, <abstract-sheet>, <event-handler>, <object>)
+
+
+The class precedence list of <column-splitter-pane> differ, Dylan:
+    #(<column-splitter-pane>, <column-splitter>, <splitter>, <single-child-wrapping-pane>, <cached-space-requirement-mixin>, <client-overridability-mixin>, <wrapping-layout-mixin>, <composite-layout-mixin>, <layout-mixin>, <layout>, <single-child-mixin>, <basic-sheet>, <sheet>, <basic-gadget>, <gadget>, <abstract-gadget>, <abstract-sheet>, <event-handler>, <object>);
+C3:
+    #(<column-splitter-pane>, <column-splitter>, <splitter>, <single-child-wrapping-pane>, <cached-space-requirement-mixin>, <client-overridability-mixin>, <wrapping-layout-mixin>, <composite-layout-mixin>, <layout-mixin>, <layout>, <basic-gadget>, <gadget>, <abstract-gadget>, <single-child-mixin>, <basic-sheet>, <sheet>, <abstract-sheet>, <event-handler>, <object>)
+
+
+The class precedence list of <win32-viewport> differ, Dylan:
+    #(<win32-viewport>, <viewport>, <basic-gadget>, <gadget>, <abstract-gadget>, <win32-pane-mixin>, <standard-input-mixin>, <sheet-with-event-queue-mixin>, <client-overridability-mixin>, <scrolling-sheet-mixin>, <permanent-medium-mixin>, <sheet-with-medium-mixin>, <mirrored-sheet-mixin>, <sheet-with-resource-mixin>, <single-child-composite-pane>, <single-child-mixin>, <basic-composite-pane>, <cached-space-requirement-mixin>, <composite-layout-mixin>, <layout-mixin>, <layout>, <basic-sheet>, <sheet>, <abstract-sheet>, <event-handler>, <object>);
+C3:
+    #(<win32-viewport>, <viewport>, <basic-gadget>, <gadget>, <abstract-gadget>, <win32-pane-mixin>, <standard-input-mixin>, <sheet-with-event-queue-mixin>, <client-overridability-mixin>, <scrolling-sheet-mixin>, <permanent-medium-mixin>, <mirrored-sheet-mixin>, <sheet-with-resource-mixin>, <sheet-with-medium-mixin>, <single-child-composite-pane>, <single-child-mixin>, <basic-composite-pane>, <cached-space-requirement-mixin>, <composite-layout-mixin>, <layout-mixin>, <layout>, <basic-sheet>, <sheet>, <abstract-sheet>, <event-handler>, <object>)
+
+
+Reference Implementation
+========================
+
+The `pull request #168
+<https://github.com/dylan-lang/opendylan/pull/168#issuecomment-3645980>`_
+was finally merged into master.
+
diff --git a/documentation/website/source/proposals/dep-0004-strings-library.rst b/documentation/website/source/proposals/dep-0004-strings-library.rst
new file mode 100644
index 0000000000..ce56bdbc28
--- /dev/null
+++ b/documentation/website/source/proposals/dep-0004-strings-library.rst
@@ -0,0 +1,360 @@
+*******************
+New strings Library
+*******************
+
+==============  =============================================
+DEP #:          4
+Type:           Standards Track
+Author:         Carl Gay
+Status:         Accepted
+Created:        08-Apr-2012
+Last-Modified:  05-May-2012
+Post-History:   01-May-2012, 09-Apr-2012
+Dylan-Version:  2012.1
+==============  =============================================
+
+
+Abstract
+========
+
+This proposal is an attempt to provide a simpler, more consistent
+strings API than is currently available via string-extensions, that is
+available from a single library (and a single module).
+
+Goals
+=====
+
+#. Comprehensive string APIs available via the ``strings`` module
+   exported from the ``strings`` library.
+
+#. Consistent naming and parameter lists.
+
+#. As simple as possible to use for common tasks.  Strive for the same
+   simplicity as Python, for example.
+
+#. Where possible, functions introduced here should be useful when
+   applied to standard Dylan mapping functions (map, every?, etc)
+   and collection functions (sort, reverse, etc).  In other words
+   they should not require currying in order to be used with the
+   mapping and collection functions for the most common cases.
+
+#. Replace existing string-extensions module, which will only be
+   retained (on GitHub) so as not to break Gwydion Dylan unnecessarily.
+   (It could be integrated into GD instead of being a submodule.)
+
+
+Non Goals
+=========
+
+#. Unicode
+
+#. Immutable strings
+
+#. Strings not implemented as subclasses of :drm:`<sequence>`.
+
+#. Text formatting APIs, such as justification and wrapping.
+
+#. Anything that is only applicable to a specific human language,
+   such as *pluralize*.
+
+
+Proposal
+========
+
+Open Dylan currently has a hodge-podge of string manipulation
+functionality.  A few functions (concatenate, subsequence-position,
+as-lowercase, ...) are built into the ``dylan`` library, some
+functions are exported from various modules in the string-extensions
+library, and a few in common-dylan.  Some Common Lisp-like strings
+functionality has been built into DUIM and Deuce.  This proposal is an
+attempt to provide a richer strings API in a single "strings" module.
+This is complicated by the fact that some string operations are also
+applicable to generalized sequences.
+
+The entire existing "strings" module (mainly used by the http library)
+will be replaced by this API.
+
+I first present the entire API and then later discuss it in detail.
+
+
+API Summary
+-----------
+
+Export the following functions from the "strings" module of the
+"strings" library.
+
+::
+
+    control?      (char-or-string, #key start, end) => (boolean)
+    printable?    (char-or-string, #key start, end) => (boolean)
+    graphic?      (char-or-string, #key start, end) => (boolean)
+    alphabetic?   (char-or-string, #key start, end) => (boolean)
+    alphanumeric? (char-or-string, #key start, end) => (boolean)
+
+    lowercase?  (char-or-string, #key start, end) => (boolean)
+    uppercase?  (char-or-string, #key start, end) => (boolean)
+    whitespace? (char-or-string, #key start, end) => (boolean)
+
+    decimal-digit?      (char-or-string, #key start, end) => (boolean)
+    octal-digit?        (char-or-string, #key start, end) => (boolean)
+    hexadecimal-digit?  (char-or-string, #key start, end) => (boolean)
+
+    char-compare      (char1, char2) => (one-of(-1, 0, 1))
+    char-compare-ic   (char1, char2) => (one-of(-1, 0, 1))
+    char-equal-ic?    (char1, char2) => (boolean)
+
+    string-compare  (string1, string2, #key start1, end1, start2, end2, test) => (one-of(-1, 0, 1))
+    string-equal?   (string1, string2, #key start1, end1, start2, end2) => (boolean)
+    string-less?    (string1, string2, #key start1, end1, start2, end2) => (boolean)
+    string-greater? (string1, string2, #key start1, end1, start2, end2) => (boolean)
+    string-equal-ic?   (string1, string2, #key start1, end1, start2, end2) => (boolean)
+    string-less-ic?    (string1, string2, #key start1, end1, start2, end2) => (boolean)
+    string-greater-ic? (string1, string2, #key start1, end1, start2, end2) => (boolean)
+
+    starts-with? (string, pattern-string, #key test) => (boolean)
+    ends-with?   (string, pattern-string, #key test) => (boolean)
+
+    lowercase  (char-or-string, #key start, end) => (new-char-or-string)
+    lowercase! (char-or-string, #key start, end) => (char-or-string)
+    uppercase  (char-or-string, #key start, end) => (new-char-or-string)
+    uppercase! (char-or-string, #key start, end) => (char-or-string)
+
+    strip       (string, #key test = whitespace?, start, end) => (new-string)
+    strip-left  (string, #key test = whitespace?, start, end) => (new-string)
+    strip-right (string, #key test = whitespace?, start, end) => (new-string)
+
+    pad       (string, width, #key fill = ' ')
+    pad-left  (string, width, #key fill = ' ')
+    pad-right (string, width, #key fill = ' ')
+
+    find-substring     (string, pattern-string, #key start, end, ignore-case?) => (index-or-#f)
+    count-substrings   (string, pattern-string, #key start, end, ignore-case?) => (count)
+    replace-substrings (string, pattern-string, new, #key start, end, count, ignore-case?) => (new-string)
+
+    split-lines (string, #key remove-if-empty?) => (strings)
+
+    // For reference, the following functions are available via dylan
+    // or common-dylan and, although for general sequences, are
+    // often useful for strings as well...
+
+    concatenate (sequence, #rest more-sequences) => (new-sequence)
+    join (parts, separator, #key start, end, key, conjunction) => (string)
+    replace-elements! (big, predicate, new-value-fn, #key count) => (big)
+    replace-subsequence! (big, small, #key start, end) => (big)
+    split (string, separator, #key start, end, max, remove-if-empty) => (strings)
+
+Some observations about this API:
+
+* Because this API provides *start* and *end* keywords where
+  appropriate, it is possible to do string operations within larger
+  strings without allocating.
+
+* Some functions, such as starts-with? and ends-with?, are provided
+  just for readability, despite being trivial to implement in terms of
+  other functions.
+
+The remainder of this proposal will repeat the above API with
+discussion interspersed.
+
+
+Discussion
+----------
+
+All comparisons default to being case-sensitive unless the function
+name ends with "-ic" or "-ic?" (meaning ignore case).
+
+In all cases, ``start`` (or start1 or start2) parameters default to 0.
+
+In all cases, ``end`` (or end1 or end2) parameters default to the size
+of the corresponding string.
+
+::
+
+    control?      (char-or-string, #key start, end) => (boolean)
+    printable?    (char-or-string, #key start, end) => (boolean)
+    graphic?      (char-or-string, #key start, end) => (boolean)
+    alphabetic?   (char-or-string, #key start, end) => (boolean)
+    alphanumeric? (char-or-string, #key start, end) => (boolean)
+
+    lowercase?  (char-or-string, #key start, end) => (boolean)
+    uppercase?  (char-or-string, #key start, end) => (boolean)
+    whitespace? (char-or-string, #key start, end) => (boolean)
+
+    decimal-digit?      (char-or-string, #key start, end) => (boolean)
+    octal-digit?        (char-or-string, #key start, end) => (boolean)
+    hexadecimal-digit?  (char-or-string, #key start, end) => (boolean)
+
+The methods on :drm:`<character>` do not have *start* and *end*
+parameters for obvious reasons.
+
+The methods on :drm:`<string>` return true if they would return true for
+each character in the string.  The :drm:`<string>` methods could be
+implemented as follows::
+
+    every?(f, copy-sequence(s, start: start, end: _end))
+
+Making these functions work on strings makes the resulting code more
+concise than using :drm:`every?` and :drm:`copy-sequence` together,
+and also more efficient, since no allocation is necessary.  The
+alternative is to write your own comparison function (which is the
+solution we have now, resulting in multiple implementations) or write
+a :drm:`for` loop inline.
+
+Note that ``lowercase?`` and ``uppercase?`` return true for
+non-alphabetic characters, so (for example) to determine whether a
+string contains all uppercase alphabetic characters you would use::
+
+    alphabetic?(string) & uppercase?(string)
+
+::
+
+    char-compare      (char1, char2) => (one-of(-1, 0, 1))
+    char-compare-ic   (char1, char2) => (one-of(-1, 0, 1))
+    char-equal-ic?    (char1, char2) => (boolean)
+
+    string-compare  (string1, string2, #key start1, end1, start2, end2, test) => (one-of(-1, 0, 1))
+    string-equal?   (string1, string2, #key start1, end1, start2, end2) => (boolean)
+    string-less?    (string1, string2, #key start1, end1, start2, end2) => (boolean)
+    string-greater? (string1, string2, #key start1, end1, start2, end2) => (boolean)
+    string-equal-ic?   (string1, string2, #key start1, end1, start2, end2) => (boolean)
+    string-less-ic?    (string1, string2, #key start1, end1, start2, end2) => (boolean)
+    string-greater-ic? (string1, string2, #key start1, end1, start2, end2) => (boolean)
+
+String and character comparisons, both case-sensitive and ignoring
+case (\*-ic?).  These default to comparing the entire string but allow
+comparing substrings via keyword arguments.
+
+``string-compare`` returns -1 if *string1* is less than *string2*, 0
+if the strings are equal, and 1 if *string1* is greater than
+*string2*.
+
+Some might object to the \*-ic? functions on the grounds that a "test"
+parameter could be added to the non-\*-ic?  functions
+instead.  But consider this type of code, which is likely to be fairly
+common::
+
+    sort(seq, test: string-less-ic?)
+
+Instead one would have to write this::
+
+    sort(seq, test: rcurry(string-less?, test: char-compare-ic))
+
+or worse, if ``char-compare-ic`` is removed on the same grounds::
+
+    sort(seq, test: rcurry(string-less?, test: method (c1, c2)
+                                                 char-compare(as-lowercase(c1), as-lowercase(c2))
+                                               end))
+
+or, the less efficient but more concise::
+
+    sort(seq, test: method (s1, s2) as-lowercase(s1) < as-lowercase(s2) end)
+
+::
+
+    // Included here for completeness
+    =  (char-or-string, char-or-string) => (boolean)
+    <  (char-or-string, char-or-string) => (boolean)
+    >  (char-or-string, char-or-string) => (boolean)
+
+If one doesn't mind allocating memory, the above built-in functions
+can be used in place of explicit *start* and *end* parameters::
+
+    copy-sequence(s1, start: x, end: y) = copy-sequence(s2, start: w, end: z)
+
+::
+
+    lowercase  (char-or-string, #key start, end) => (new-char-or-string)
+    lowercase! (char-or-string, #key start, end) => (char-or-string)
+    uppercase  (char-or-string, #key start, end) => (new-char-or-string)
+    uppercase! (char-or-string, #key start, end) => (char-or-string)
+
+The above are provided despite the existence of :drm:`as-uppercase`
+and :drm:`as-lowercase` in the dylan module because they provide
+*start* and *end* parameters, which makes them consistent with the
+rest of the API.
+
+::
+
+    strip       (string, #key test = whitespace?, start, end) => (new-string)
+    strip-left  (string, #key test = whitespace?, start, end) => (new-string)
+    strip-right (string, #key test = whitespace?, start, end) => (new-string)
+
+Return a copy of *string* between *start* and *end* with characters
+matching *test* removed.  Characters are removed from the left and/or
+right side of *string* until the first character *not* matching *test*
+is found.
+
+::
+
+    pad       (string, width, #key fill = ' ')
+    pad-left  (string, width, #key fill = ' ')
+    pad-right (string, width, #key fill = ' ')
+
+The above return a new string of the given *width*.  If *string*
+is shorter than *width*, the *fill* character is added to the left
+and/or right side of the string as appropriate.
+
+    Examples::
+
+      pad("x", 5) => "  x  "
+      pad("x", 4) => "  x " or " x  "    (unspecified)
+      pad("x", 7, fill: '.') => "...x..."
+
+::
+
+    starts-with? (string, pattern-string, #key test) => (boolean)
+    ends-with?   (string, pattern-string, #key test) => (boolean)
+
+These common operations are for convenience and readability.  The
+*test* parameter is the same as for ``string-compare``.
+
+::
+
+    find-substring     (string, pattern-string, #key start, end, ignore-case?) => (index-or-#f)
+
+``find-substring`` is like :drm:`subsequence-position` except that it
+accepts *start* and *end* keyword arguments instead of *count*, and it
+only applies to strings so the *ignore-case?* argument has been added.
+
+Note that this (and replace-substrings) use *ignore-case?* instead of
+a *test* parameter.  This is because the implementation (Boyer
+Moore-ish search) needs to setup skip tables and the code for that
+needs to know explicitly whether case is being ignored.
+
+::
+
+    count-substrings   (string, pattern-string, #key start, end, ignore-case?) => (count)
+
+``count-substrings`` counts the number of non-overlapping occurrences
+of *pattern-string* within *big*.
+
+::
+
+    replace-substrings (string, pattern-string, new, #key start, end, count, ignore-case?) => (new-string)
+
+``replace-substrings`` returns a new string with occurrences of
+*pattern-string* replaced by *new*.  If *count* is supplied then only *count*
+occurrences (moving left to right through *string*) are replaced.
+*ignore-case?* defaults to #f.
+
+
+Dropped string-extensions Names
+-------------------------------
+
+A few names exported from *string-extensions* have no equivalent in this
+library:
+
+* The *%parse-string* module.  This should be moved to
+  *regular-expressions* if it's needed at all.
+
+* The *string-hacking* module.  This includes character sets, and a
+  few character utilities.
+
+* The *string-conversions* module.  The only names this exports that
+  aren't available elsewhere are *digit-to-integer* and
+  *integer-to-digit*.  I suggest we put basic conversions like this
+  into *common-dylan* alongside *string-to-integer* et al.
+
+* Two names from the *substring-search* module:
+  *make-substring-positioner* and *make-substring-replacer*.
+
diff --git a/documentation/website/source/proposals/dep-0005-subclass-function.rst b/documentation/website/source/proposals/dep-0005-subclass-function.rst
new file mode 100644
index 0000000000..6d57112de0
--- /dev/null
+++ b/documentation/website/source/proposals/dep-0005-subclass-function.rst
@@ -0,0 +1,401 @@
+********
+Subclass
+********
+
+==============  =============================================
+DEP #:          5
+Type:           Standards Track
+Affects-DRM:    Yes
+Author:         Keith Playford
+Status:         Accepted
+Created:        13-Jul-1995
+Last-Modified:  08-Aug-1995
+Post-History:   None
+==============  =============================================
+
+*Note: This DEP was converted from the old Dylan Change Proposal
+Format to DEP format with minimal changes for ReStructuredText.  It
+does not fully conform to the new format.*
+
+Abstract
+========
+
+   Methods on generic functions such as Dylan's standard "make" and "as"
+   which take types as arguments are impossible to reuse in Dylan without
+   resorting to ad hoc techniques. As things stand, the only available
+   mechanism for specializing such methods is through the use of
+   singleton types. A singleton type specializer used in this way, by
+   definition, gives a method applicable to exactly one type. In
+   particular, such methods are not applicable to subtypes of the type in
+   question.
+
+   In order to define reusable methods on generic functions like this, we
+   need a type which allows us to express applicability to a type and all
+   its subtypes.
+
+Specification
+=============
+
+   Define the following:
+
+   .. code-block:: dylan
+
+     subclass (class) => type
+
+   A call to this function returns a type which describes all the
+   objects representing subclasses of the given class. We term such a
+   type a "subclass type".
+
+   The subclass function is allowed to return an existing type if that
+   type is type equivalent to the subclass type requested.
+
+   For an object O and class Y, the following instance? relationship
+   applies:
+
+   * INSTANCE-1. instance?(O, subclass(Y))
+     This will be true if and only if O is a class and O is a subclass of Y.
+
+   For classes X and Y the following subtype? relationships hold (note
+   that a rule applies only when no preceding rule matches):
+
+   * SUBTYPE-1. subtype?(subclass(X), subclass(Y))
+     This will be true if and only if X is a subclass of Y.
+
+   * SUBTYPE-2. subtype?(singleton(X), subclass(Y))
+     This will be true if and only if X is a class and X is a subclass of
+     Y.
+
+   * SUBTYPE-3. subtype?(subclass(X), singleton(Y))
+     This is always false.
+
+   * SUBTYPE-4. subtype?(subclass(X), Y), where Y is not a subclass type
+     This will be true if Y is <class> or any proper superclass of
+     <class> (including <object>, any implementation-defined supertypes,
+     and unions involving any of these). There may be other
+     implementation-defined combinations of types X and Y for which this
+     is also true.
+
+   * SUBTYPE-5. subtype?(X, subclass(Y)), where X is not a subclass type
+     This will be true if Y is <object> or any proper supertype of
+     <object> and X is a subclass of <class>.
+
+   Note that by subclass relationships SUBYPE-4 and SUBTYPE-5, we get
+   this correspondance:
+
+   * <class> and subclass(<object>) are type equivalent.
+
+   Where the subtype? test has not been sufficient to determine an
+   ordering for a method's argument position, the following further
+   method ordering rules apply to cases involving subclass types (note
+   that a rule applies only when no preceding rule matches):
+
+   * SPECIFICITY+1. subclass(X) precedes subclass(Y) when the argument is
+     a class C and X precedes Y in the class precedence list of C.
+
+   * SPECIFICITY+2. subclass(X) always precedes Y, Y not a subclass type.
+     That is, applicable subclass types precede any other applicable
+     class-describing specializer.
+
+   The constraints implied by sealing come by direct application of
+   sealing rules 1 - 3 and the following disjointness criteria for
+   subclass types (note that a rule applies only when no preceding rule
+   matches):
+
+   * DISJOINTNESS+1. A subclass type subclass(X) and a type Y are
+     disjoint if Y is disjoint from <class>.
+
+   * DISJOINTNESS+2. Two subclass types subclass(X) and subclass(Y) are
+     disjoint if the classes X and Y are disjoint.
+
+   * DISJOINTNESS+3. A subclass type subclass(X) and a singleton type
+     singleton(O) are disjoint unless O is a class and O is a subclass of
+     X.
+
+   Method sealing's rule 3 must be changed to include the following:
+
+   * A method M (with specializers S1...Sn) in G also potentially blocks
+     C at argument position i if there exist j and k such that
+     subclass(Dj) is a pseudosubtype of Si, subclass(Dk) is a
+     pseudosubtype of Ti, and subclass(Dk) is not a pseudosubtype of Si.
+
+   This relies on the acceptance of Version 6 of "Method Sealing Bug".
+
+Amendment
+=========
+
+   Specify that a subclass of <class> is considered disjoint from a
+   subclass type until a class is created that is a common instance of
+   both.
+
+   Do this by changing the disjointness rule:
+
+   * A subclass type subclass(X) and a type Y are disjoint if Y is
+     disjoint from <class>.
+
+   to read:
+
+   * A subclass type subclass(X) and a type Y are disjoint if Y is
+     disjoint from <class>, or if Y is a subclass of <class> without
+     instance classes that are also subclasses of X.
+
+Rationale
+=========
+
+   Subclass types don't address everything in the problem description,
+   particularly limited collection types, but are simpler to understand
+   than subtype types and still very useful, particularly within user-
+   defined frameworks where limited types are not an issue.
+
+   The guiding principle behind the semantics is that, as far as
+   possible, methods on classes called with an instance should behave
+   isomorphically to corresponding methods on corresponding subclass
+   types called with the class of that instance. So, for example, given
+   the heterachy::
+
+     <object>
+         \
+         <A>
+         / \
+       <B> <C>
+         \ /
+         <D>
+
+   and methods:
+
+   .. code-block:: dylan
+
+     method foo (<A>)
+     method foo (<B>)
+     method foo (<C>)
+     method foo (<D>)
+
+     method foo-using-type (subclass(<A>))
+     method foo-using-type (subclass(<B>))
+     method foo-using-type (subclass(<C>))
+     method foo-using-type (subclass(<D>))
+
+   that for a direct instance D1 of <D>:
+
+   .. code-block:: dylan
+
+     foo-using-type(<D>)
+
+   should behave analogously to:
+
+   .. code-block:: dylan
+
+     foo(D1)
+
+   with respect to method selection.
+
+   The clause added to sealing's "Rule 3" forces class creation to
+   respect sealing constraints on this parallel heterarchy. Thus, sealing
+   methods over subclass(C1), ..., subclass(CN) results in the same
+   constraints on class creation as sealing methods with the same
+   structure over C1, ..., CN if metaclasses are ignored.
+
+   The rule that has subclass specializers precede other specializers
+   applicable to types seems arbitrary but looks to be most useful and
+   leads to the simplest "rule of thumb", being that for a set of
+   applicable types the general order in decreasing order of
+   applicability is:
+
+   * singleton specializer
+   * subclass specializers
+   * class specializers
+
+   No attempt is made to be "clever" with subtype? relationships. In
+   particular, the simplifying assumption is made that any class might
+   have subclasses we know nothing about, regardless of any sealing
+   declarations that might appear in the code. This seems a reasonable
+   course to take.
+
+   The rationale for the amendment is to prevent sealing a generic
+   function over a subclass type of a class from blocking the creation of
+   new metaclasses unnecessarily. The amendment may or may not be
+   considered necessary at this point given that Dylan does not currently
+   address the issue of introducing new metaclasses. Note that even
+   without the amendment an implementation is free to have a number of
+   initial, explicitly-defined metaclasses without any problems, in which
+   case the situation is analogous to that of limited <integer>.
+
+Examples
+========
+
+   .. code-block:: dylan
+
+     // Common usage:
+
+     define class <A> (<object>) end;
+     define class <B> (<A>) end;
+     define class <C> (<A>) end;
+     define class <D> (<B>, <C>) end;
+
+     define method make (class :: subclass(<A>), #key)
+       print("Making an <A>");
+       next-method();
+     end method;
+
+     define method make (class :: subclass(<B>), #key)
+       print("Making a <B>");
+       next-method();
+     end method;
+
+     define method make (class :: subclass(<C>), #key)
+       print("Making a <C>");
+       next-method();
+     end method;
+
+     define method make (class :: subclass(<D>), #key)
+       print("Making a <D>");
+       next-method();
+     end method;
+
+     ? make(<D>);
+     Making a <D>
+     Making a <B>
+     Making a <C>
+     Making an <A>
+     {instance of <D>}
+
+     // Less common usage:
+
+     // Metatype methods
+
+     define method classify (type :: <type>)
+       print("A type");
+     end method;
+
+     define method classify (type :: <class>)
+       print("A class");
+       next-method();
+     end method;
+
+     define method classify (type :: <singleton>)
+       print("A singleton");
+       next-method();
+     end method;
+
+     // "User" level subclass methods
+
+     define method classify (type :: subclass(<object>))
+       print("A subclass of <object>");
+       next-method();
+     end method;
+
+     ? classify(<symbol>);
+     A subclass of <object>
+     A class
+     A type
+
+     ? classify(singleton(<symbol>))
+     A subclass of <object>
+     A singleton
+     A type
+
+     ? classify(subclass(<symbol>))
+     A subclass of <object>
+     A type
+
+Cost to implementors
+====================
+
+   Another type to implement. Given the number of types Dylan has and
+   allows you to specialize on already, any implementation is going to
+   require a well thought out type framework. Given this, it should be
+   reasonable to add in the new rules for <subclass> as specified.
+
+Cost to users
+=============
+
+   Another type to understand, although they shouldn't have to face it
+   unless they have need of it, and even then only the "obvious" aspects
+   of its behaviour are likely to be necessary in user programs.
+
+Performance impact
+==================
+
+   Singleton types, and possibly limited integer types, are likely to be
+   implemented through some kind of secondary dispatch scheme
+   already. Subclass types could be dealt with using the same
+   technique. In the common case where a generic function defines a
+   restriction on an argument that constrains it to be a type object
+   (make, as), there is potential to do somewhat better by hijacking the
+   primary dispatch mechanism in the corresponding argument position.
+
+Benefits
+========
+
+   Methods that take classes as arguments become reusable!
+
+Aesthetics
+==========
+
+   Good on balance because it fills a tangible hole in the language in a
+   consistent, intuitive way rather than leaving the hole there to be
+   fallen into or filled by ad hoc techniques.
+
+Discussion
+==========
+
+   The subclass relationship definitions don't spell everything out
+   explicitly when it comes to union types - for the definition of new
+   types to be tractable we have to be able to fall back on existing
+   definitions of composite types like union, and we do here.
+
+From Keith Playford in 1995
+===========================
+
+   Subclass specialisation is interesting in that most groups seem to
+   recognise the need for it and, in fact, actually implement and use it
+   in some form or another: we now support it, as does Mindy through an
+   extension of the "limited" type mechanism, and some of the mail on
+   collection coercion suggests that Apple Dylan supports it too.
+
+   Our own implementation follows the shelved proposal "Subclass
+   Specialization" by providing the type constructor "subclass" which
+   returns a type describing all the subclasses of its argument class.
+   The method specificity rules are extended such that the CPL of the
+   argument class is taken into account. Loosely, this means that a
+   method set specialising on the subclass types subclass(Ci) will be
+   selected and ordered by a class argument C in a way isomorphic to a
+   corresponding method set specialising on Ci given argument make(C).
+
+   We'd like to bring "Subclass Specialization" up to date, hopefully in
+   line with the above, and try to get it agreed between the partners.
+   Like all of these issues, if it can't be included in the book, we need
+   to at least negotiate a standard way (library/module) of getting at
+   "subclass" in implementations that support it. This could imply
+   registry as a standard implementation-dependent library, with
+   Gwydion's agreement.
+
+
+From the Gwydion docs
+=====================
+
+   Gwydion compilers supports subclass specializers via the *limited* function.
+   A subclass specializer causes a method to be invoked whenever the generic
+   function was called on a value that is the specified class or any subclass
+   of the specified class. The method is never invoked on a value that is an
+   instance (direct or indirect) of the specified class, only when the value
+   is a subclass of the specified class. The following is an example:
+
+   .. code-block:: dylan
+
+     define method make (result-class :: limited(<class>, subclass-of: <my-class>))
+       let x = next-method();
+       do-special-logging-or-something(x);
+       x;
+     end method;
+
+Revision History
+================
+::
+
+   Version 1, 13th July 95, Keith Playford (Harlequin)
+   Version 2, 8th August 95, Keith Playford (Harlequin)
+
+Status
+======
+
+   Accepted 08 August 1995
diff --git a/documentation/website/source/proposals/dep-0006-single-file-library.rst b/documentation/website/source/proposals/dep-0006-single-file-library.rst
new file mode 100644
index 0000000000..a80cf81fb7
--- /dev/null
+++ b/documentation/website/source/proposals/dep-0006-single-file-library.rst
@@ -0,0 +1,296 @@
+*********************
+Single File Libraries
+*********************
+
+==============  =============================================
+DEP #:          6
+Type:           Standards Track
+Author:         Carl Gay
+Status:         Draft
+Created:        12-Feb-2013 (Darwin's birthday)
+Last-Modified:  04-Dec-2021
+Post-History:   04-Dec-2021 https://gitter.im/dylan-lang/general
+Dylan-Version:  2020.1
+==============  =============================================
+
+
+Revision History
+================
+
+The revision history of this document is available on GitHub:
+https://github.com/dylan-lang/website/commits/master/source/proposals/dep-0006-single-file-library.rst
+
+Abstract
+========
+
+Open Dylan currently requires users to create three source files to
+define a simple library like hello-world:
+
+#. A project file (i.e., .lid file) to describe source files to
+   include, link options, etc.
+
+#. A library and module definition source file, often named library.dylan.
+
+#. At least one source file for main program logic, in a module
+   defined by the library definition.
+
+This DEP proposes a standard way to define a Dylan library in a single
+source file.  This DEP targets implementations of Dylan but does not
+propose a change to the Dylan language itself.  In particular it is
+proposed as an enhancement for Open Dylan.
+
+Rationale
+=========
+
+The three files described above are a lot of overhead for new users
+who want to get a feel for the language, who are generally used to
+creating a single file and running it directly, perhaps after
+compiling it.  A simpler setup would provide a better initial
+experience for new users, and would help to make Dylan more attractive
+for "scripting" purposes.  The mantra has been that Dylan was designed
+for large projects, but there's no reason it can't also excel at
+scripting, with this change and the right set of support libraries.
+
+Note that even though the ``make-dylan-app`` program will generate a
+skeleton project with three files (and a registry), this does not
+remove the need to jump back and forth between the library definition
+file and the main source file as you figure out which modules you need
+to use.  There is also the issue of new users figuring out that
+``make-dylan-app`` exists in the first place, and what LID files are.
+
+There are plenty of libraries that are small enough to comfortably fit
+in a single file.  Of the existing libraries in `the dylan-lang github
+repository <https://github.com/dylan-lang>`_, at least ten could
+comfortably fit in a single file.
+
+Having a library in a single file simplifies sharing of examples and
+small tests.  Indeed, one of the motivations for this feature was to
+be able to contribute Dylan solutions for the `The Computer Language
+Benchmarks Game <https://benchmarksgame-team.pages.debian.net/benchmarksgame/>`_, which
+prefers to receive one file per solution.  Obviously it is possible to
+explain to them about LID files and how to unpack and compile a
+multi-file solution for each problem, but it is more complex than it
+needs to be.
+
+This DEP is only the first step to adding better support for
+scripting.  More is needed, such as supporting "hash bang" lines
+(``#!/usr/bin/dylan``) and only recompiling when the source has
+changed.
+
+Gwydion Dylan already supports a simple form of single-file library,
+but it has limitations that this DEP removes, specifically the
+inability to deal with import conflicts.
+
+
+Goals
+=====
+
+* Make it possible to use the full power of the Dylan module system to
+  define a library in a single file.
+
+* Make all LID file options available in the single-file library
+  format.
+
+* Introduce a minimum of new syntax.  It should be obvious to someone
+  already used to Dylan what's going on.
+
+
+Background
+==========
+
+A typical hello-world application written in Dylan might look like
+this:
+
+**hello-world.lid**
+
+.. code-block:: dylan
+
+    Library: hello-world
+    Files: library.dylan
+           hello-world.dylan
+
+**library.dylan**
+
+.. code-block:: dylan
+
+    Module: dylan-user
+
+    define libary hello-world
+      use common-dylan;
+      use io;
+    end;
+
+    define module hello-world
+      use common-dylan;
+      use format-out;
+    end;
+
+**hello-world.dylan**
+
+.. code-block:: dylan
+
+    Module: hello-world
+
+    format-out("Hello, world!\n")
+
+A way to encode the same information into a regular dylan
+source file is needed.  After the implementation of this DEP, the
+above library can be defined in a single source file, as follows:
+
+**hello-world.dylan**
+
+.. code-block:: dylan
+
+    Module: hello-world
+
+    define libary hello-world
+      use common-dylan;
+      use io;
+    end;
+
+    define module hello-world
+      use common-dylan;
+      use format-out;
+    end;
+
+    format-out("Hello, world!\n")
+
+This continues to use the standard `Dylan Interchange Format
+<https://opendylan.org/books/drm/Dylan_Interchange_Format>`_ as defined
+in the DRM, with a set of headers, followed by a blank line, followed
+by a *code body*.
+
+
+Specification
+=============
+
+Replacing the LID File
+----------------------
+
+LID files have the same format as the header section of a Dylan
+Interchange Format source file.  When defining a Dylan library in a
+single source file, all LID keywords may appear in the header section.
+The compiler or interpreter should handle them in the same way it
+would if they were in a separate .lid file.  There is no conflict
+between the keywords used in LID files and those used in Dylan source
+files.  See https://opendylan.org/documentation/library-reference/lid.html
+for existing Open Dylan LID file keywords.
+
+Module Header
+~~~~~~~~~~~~~
+
+The ``Module`` header is required in a single-source library.
+
+Library Header
+~~~~~~~~~~~~~~
+
+The ``Library`` header is optional. If missing, the library name is the same as
+the module name specified by the ``Module`` header.
+
+.. note:: This decision could have gone the other way, with ``Library``
+          required and ``Module`` optional. The rationale for this choice is
+          that it is normal for each .dylan file to have a ``Module`` header
+          already, so this is consistent with current practice.
+
+Files Header
+~~~~~~~~~~~~
+
+The ``Files`` header should not appear in a single-file library.  If
+present, the behavior is undefined.
+
+.. note:: Rationale: an implementation could choose to point to a Dylan source
+          file instead of a LID file in its build system. For example, in Open
+          Dylan a "registry" file could point to a .dylan file instead of a
+          .lid file and there's no reason to prevent the .dylan file from
+          including other Dylan source files. However, that is not part of this
+          proposal.
+
+Replacing library.dylan
+-----------------------
+
+A single-file Dylan library is divided into three logical sections:
+
+1.  Dylan Interchange Format headers, including all headers that are allowed in
+    Dylan source files or in LID files.
+
+2.  Library and module definitions (see below).
+
+3.  Main Dylan code
+
+In the library and module definitions section of the source file normal Dylan
+code comments are allowed and there must be:
+
+* *Exactly one* ``define library`` expression and its name must match the name
+  specified in the ``Library`` header (or the ``Module`` header if there is no
+  ``Library`` header).
+
+* *At least* one ``define module`` expression whose name matches the ``Module``
+  header.
+
+* *No* other Dylan code.
+
+The library and module definitions section ends when the first expression that
+is not a ``define library`` or ``define module`` is encountered.
+
+The library and module definitions section is implicitly in the ``dylan-user``
+module.
+
+This construction allows the full power of Dylan's module system to be used,
+for example defining both implementation and interface modules, exporting the
+implementation module for use by a (possibly also single-file) test library,
+etc.
+
+Model Implementation
+====================
+
+A simple way to implement this proposal would be via the following source
+transformations. (Such a simplistic implementation is not recommended because
+it would cause problems mapping error messages back to the original source
+files, among other issues.  This example is provided primarily to demonstrate
+that a single-file library has the same semantics as a multi-file library.)
+
+1.  Generate a ``library.dylan`` file containing the entire library and module
+    definitions section, verbatim, but in the ``dylan-user`` module. Using the
+    hello-world example from above, we generate::
+
+      ------- file: library.dylan -------
+      Module: dylan-user
+
+      define libary hello-world
+        use common-dylan;
+        use io;
+      end;
+
+      define module hello-world
+        use common-dylan;
+        use format-out;
+      end;
+
+2.  Generate a "main.dylan" file containing the entire headers section and the
+    entire main Dylan code section::
+
+      ------- file: main.dylan -------
+      Module: hello-world
+
+      format-out("Hello, world!\n")
+
+#. Generate a LID file that includes the entire headers section. Add a
+   ``Library`` header matching the ``Module`` header if none was provided, and
+   add "library.dylan" and "main.dylan" to the ``Files`` header::
+
+     ------- file: hello-world.lid -------
+     Library: hello-world
+     Module: hello-world
+     Files: library.dylan
+            main.dylan
+
+#. Compile the generated LID file in the normal way.
+
+Alternatives Considered
+=======================
+
+The initial version of this DEP considered adding special Dylan Interchange
+Format headers (``Use-library``, ``Use-module``, etc.) in which the library and
+module imports would be specified. That version was rejected because it did not
+allow the full power of Dylan's module system to be used. See older revisions
+of this file for more detail.
diff --git a/documentation/website/source/proposals/dep-0007-collection-type-safety.rst b/documentation/website/source/proposals/dep-0007-collection-type-safety.rst
new file mode 100644
index 0000000000..1957f63d44
--- /dev/null
+++ b/documentation/website/source/proposals/dep-0007-collection-type-safety.rst
@@ -0,0 +1,300 @@
+*****************************
+Type-Safe Limited Collections
+*****************************
+
+===============  ========================
+DEP-Number:      0007
+Author:          Dustin Voss
+Status:          Draft
+Type:            Standards Track
+Affects-DRM:     Yes
+Created:         28-Jul-2013
+Last-Modified:   25-Dec-2013
+Post-History:    19-Dec-2013, 28-Jul-2013
+Target-Version:  2014.1
+===============  ========================
+
+
+Abstract
+========
+
+To improve type safety of collections and particularly limited collections,
+this DEP adds a ``default-fill:`` keyword argument to limited collection
+classes and an ``element-type-fill`` and ``element-type`` getter to all
+collections.
+
+
+Specification
+=============
+
+The collection classes that allow a ``fill:`` keyword argument are:
+
+- ``<array>``
+- ``<vector>``
+- ``<simple-vector>``
+- ``<simple-object-vector>``
+- ``<stretchy-vector>``
+- ``<deque>``
+- ``<list>``
+- ``<string>``
+- ``<byte-string>``
+- ``<unicode-string>``
+
+This DEP refers to these classes as *fillable collection classes*. Fillable
+collection classes are comprised of all the direct and indirect subclasses of
+``<mutable-sequence>`` excepting ``<mutable-sequence>`` itself, ``<pair>``, and
+``<empty-list>``.
+
+
+``limited``
+-----------
+
+The ``limited`` methods on fillable collection classes will each add the
+following additional parameter:
+
+====================  ==========================================
+Class                 Parameter
+====================  ==========================================
+``<string>``          ``#key default-fill :: <character> = ' '``
+``<byte-string>``     ``#key default-fill :: K1 = C1``
+``<unicode-string>``  ``#key default-fill :: K2 = C2``
+All others            ``#key default-fill :: <object> = #f``
+====================  ==========================================
+
+*K1* and *K2* are unspecified subclasses of ``<character>``. *C1* and *C2* are
+unspecified values equivalent to a space character.
+
+The ``limited`` methods on fillable collection classes each return a limited
+type designated *L*. The ``fill:`` init-keyword of all *L* will have a default
+value identical to the default value listed above instead of ``#f``.
+
+The ``type-for-copy`` method on instances of *L* will return a limited type *L2*
+as described in the [DRM]_, but with the additional requirement that *L2* will
+have the same default fill value as *L* (i.e., the same ``default-fill:``
+argument).
+
+The defaulted or supplied ``default-fill:`` argument should be an instance of
+the element type of the collection. However, it is not an error to supply a
+default fill value that the collection cannot accommodate, since a call to
+``make`` may specify a fill value of the correct type.
+
+
+``element-type-fill``
+---------------------
+
+A new open generic function will be added to the Dylan library::
+
+   element-type-fill (coll :: <collection>) => (fill-value :: <object>)
+
+For instances of a limited fillable collection class type, this function will
+return the (possibly defaulted) ``default-fill:`` argument to ``limited``. For
+instances of all other fillable collection classes, this function will return
+the following:
+
+====================  ============  
+Class                 Return Value
+====================  ============  
+``<string>``          ``' '``
+``<byte-string>``     C1
+``<unicode-string>``  C2
+All others            ``#f``
+====================  ============  
+
+*C1* and *C2* are unspecified values equivalent to a space character.
+
+It is an error to call ``element-type-fill`` on an instance of a collection
+class that does not support the ``fill:`` init-keyword. However,
+implementations may find this difficult to check (because users can introduce
+that keyword in any subclass) and may return ``#f`` for such collections
+instead. Portable programs should not rely on this behavior.
+
+
+``element-type``
+----------------
+
+A new open generic function will be added to the Dylan library::
+
+   element-type (coll :: <collection>) => (element-type :: <type>)
+
+For instances of collection classes with a limited element type, this function
+will return that element type. For instances of other collection classes, this
+function will return the element type described in
+`Element Types <https://opendylan.org/books/drm/Element_Types>`__ of the [DRM]_.
+
+
+Motivation
+==========
+
+The second paragraph of the 
+`Collection Operations <https://opendylan.org/books/drm/Collection_Operations>`__
+section of the [DRM]_ states the following:
+
+   Note to implementors: Functions such as ``map``, ``map-as`` that return a
+   new collection cannot rely on the type they instantiate having a valid
+   default for ``fill:``. Therefore, when the size of the result is nonzero,
+   these functions should compute the first element of the result before making
+   the collection and specify that element as the ``fill:`` value. Otherwise a
+   spurious type error could occur when making the collection.
+   
+However, there is a problem with the ``size-setter`` method that is not
+addressed by the above note. That method may be called on an empty collection
+to grow it. The DRM states:
+
+   The value of each new element is the same as would have been used if the
+   stretchy sequence had been created with ``make``, specifying ``size:``
+   *new-size* but not ``fill:``.
+
+That is, new elements are the default ``fill:`` value for the collection. This
+will be ``#f``, ``0``, or ``' '`` depending on the type of limited
+collection. But in a user-defined limited collection, such as
+``limited(<vector>, of: <shape>)``, the default causes a spurious type error.
+And if the collection is empty, the workaround described in the DRM of using
+the first element of the collection cannot be used.
+
+This DEP solves that problem by describing a way for ``size-setter`` to
+populate a collection with valid values. This DEP also improves the
+interface/implementation separation of limited collections by allowing a
+library author to specify a valid default for ``fill:`` in a type-defining
+``limited`` call rather than requiring the client to know and use a valid
+``fill:`` value in every call to ``make``.
+
+Additionally, this DEP adds the ``element-type`` method. This method is useful
+for code that transforms or manipulates one collection into a different form.
+The example of the ``<stream>`` classes comes to mind. If you write code that
+maps a stream to or from a user-supplied collection, that code cannot verify
+compatibility between the stream's ``stream-element-type`` and the collection's
+element type. Adding the ``element-type`` method solves that problem.
+
+
+Rationale
+=========
+
+I named ``element-type-fill`` as such rather than ``default-fill`` because the
+latter name is a little more misleading. A user can define a subclass of a
+collection and provide a new default value for the ``fill:`` init-keyword
+without needing to define a new ``element-type-fill`` method; they only need to
+do that when restricting the element type of a collection.
+
+The ``element-type-fill`` and ``element-type`` methods take an *instance* of a
+collection class as an argument rather than the *type* of the collection. This
+is necessary because the [DRM]_ allows the ``limited`` function on *C* to
+return *C* itself as a type, implying that the default fill and element type
+information associated with the limited collection has to be available on a
+per-instance basis. Plus, creating getters on types is not idiomatic to Dylan.
+
+A previous draft had changed the behavior of ``map``, etc., so that they would
+instantiate their resulting collection with the collection's default fill
+value. This turned out to be problematic. Most limited collections used in the
+Open Dylan source code do not have a ``false-or`` element type, and the element
+type they do have lacks a sensible "blank" value such as ``#f``, ``0``, or
+``""`` to use as a default fill. Strictly speaking, such a collection is poorly
+formed because it can never be directly instantiated with a specific size;
+however, that situation never occurs in the Open Dylan source code. Instead,
+the source code instantiates such a collection indirectly via ``map`` or
+``as``. Those functions fill the collection with a value derived from the first
+element of the argument(s), as described by the DRM's note to implementors
+quoted above. The value is not the "correct" value for any element but the
+first, but of course each other element is given its own "correct" value
+immediately thereafter, with the fill value merely acting as a placeholder.
+Under the previous draft this fill behavior would have been removed and all
+those limited collections would have needed to be changed; in order to tolerate
+being instantiated "empty", they would have needed a ``false-or`` element type.
+That would have been a significant lapse in backwards compatibility with the
+Open Dylan source code and presumably with other source code as well.
+Therefore, I revised this DEP to leave ``map``, etc., functioning as they
+always have. Those "poorly-formed" limited collections are still poorly formed,
+but…they work in their environment.
+
+I had originally considered a more extensive change where each instance of a
+fillable collection class would not only track its *default* fill value, but
+also track the *specific* ``fill:`` value that it was created with. But in
+thinking about it, I feel the designers made the right call in leaving that
+information out of each instance. In particular, the implementation of
+``<list>`` would be difficult if each instance tracked its ``fill:`` value.
+
+
+Implementation Notes
+--------------------
+
+``element-type``
+''''''''''''''''
+
+The Open Dylan implementation already defines this internally. The name just
+needs to be exported.
+
+
+Backwards Compatibility
+=======================
+
+This DEP does not change the limited collection type relationships described in
+the `Limited Collection Types <https://opendylan.org/books/drm/Limited_Collection_Types>`__
+section of the [DRM]_.
+
+Before this DEP, the Open Dylan implementation of limited collections
+effectively specified a ``default-fill:`` argument for certain combinations of
+collection and element type, as follows:
+
+=====================  =====================================================
+Collection             Element Types     
+=====================  =====================================================
+``<array>``            ``<byte>``, ``<double-byte>``, ``<machine-word>``,
+                       ``<integer>``, ``<single-float>``, ``<double-float>``
+``<vector>``           ``<byte>``, ``<double-byte>``, ``<machine-word>``,
+                       ``<integer>``, ``<single-float>``, ``<double-float>``
+``<stretchy-vector>``  ``<byte>``, ``<byte-character>``
+=====================  =====================================================
+
+Programs that relied on this behavior should instead specify either the
+``default-fill:`` argument to ``limited`` or the ``fill:`` init-keyword to 
+``make``.
+
+An additional side-effect of this relates to the ``subclass`` function in type
+specializers. The ``subclass`` function does not work with every limited
+collection type, because limited collection types are not classes. That is,
+``limited(<vector>, of: <color>)`` is not congruent to ``subclass(<vector>)``,
+and never has been. However, ``subclass`` will work with the above combinations
+of collection and element type, assuming the correct ``default-fill:`` is
+provided. That is, ``limited(<vector>, of: <integer>, default-fill: 0)`` is
+congruent to ``subclass(<vector>)``.
+
+Existing subclasses of ``<collection>`` that define their own ``fill:``
+init-keyword will still work, assuming they also specify a default value for
+that keyword that is of the element type of the subclass.
+
+New code may use ``element-type`` or ``element-type-fill`` in conjunction with
+an existing subclass of ``<collection>`` that does not define those methods but
+nonetheless has restricted element types. ``element-type`` and
+``element-type-fill`` will then return ``<object>`` and ``#f``, which may not
+be correct for that collection's allowed element types.
+
+The only other backwards compatibility issue is a namespace collision if the
+user defines their own unrelated "element-type" or "element-type-fill" bindings.
+
+
+Reference Implementation
+========================
+
+The reference implementation includes the following implementation-specified
+behavior:
+
+   * ``limited(<string>, …)`` returns a ``limited(<byte-string>, …)``.
+   * ``element-type-fill`` on an instance of a non-fillable collection class
+     returns ``#f`` (as opposed to signaling an error).
+
+The reference implementation currently includes an ``element-type-fill`` slot
+in every instance of a ``<simple-T-X>`` class (e.g. ``<simple-byte-vector>``).
+Ideally, the ``<simple-T-X>`` class would hard code a common
+``element-type-fill`` value like ``0`` or ``' '``, and an additional subclass
+``<simple-T-X-with-fill>`` would include the ``element-type-fill`` slot if the
+user wants a more unusual fill value. Unfortunately, it appears that the
+implementation of repeated slots does not allow for subclasses of a class with
+repeated slots.
+
+A possible remedy is to implement two subclasses of a ``<simple-T-X>`` class:
+``<simple-T-X-common-fill>`` and ``<simple-T-X-custom-fill>``. ``<simple-T-X>``
+would become abstract and the two concrete subclasses would define the repeated
+slot. The code specifically allows for this in the ``dfmc-modeling`` module's
+``limited-element-type-mappings-definer`` macro; it can return a different
+concrete class depending on the ``default-fill:`` argument to ``limited``.
+
+.. [DRM] `Dylan Reference Manual`:title-reference:
diff --git a/documentation/website/source/proposals/dep-0008-multi-line-strings.rst b/documentation/website/source/proposals/dep-0008-multi-line-strings.rst
new file mode 100644
index 0000000000..da2e7ba894
--- /dev/null
+++ b/documentation/website/source/proposals/dep-0008-multi-line-strings.rst
@@ -0,0 +1,123 @@
+******************
+Multi-line Strings
+******************
+
+===============  =============================================
+DEP #:           8
+Type:            Standards Track
+Affects-DRM:     Yes
+Author:          Carl Gay
+Status:          Withdrawn (superseded by DEP 12)
+Created:         16-Feb-2015
+Last-Modified:   16-Feb-2015
+Post-History:    16-Feb-2015 hackers@lists.opendylan.org
+Target-Version:  2015.2
+===============  =============================================
+
+
+Abstract
+========
+
+Dylan currently has no way to encode multi-line strings into a single source
+token that crosses multiple source lines.  This DEP proposes a literal syntax
+for multi-line strings.
+
+
+Rationale
+=========
+
+While it should be noted that encoding long string literals into source code is
+not good practice when internationalization is desired, it is convenient to
+have this ability for quick scripts and especially for encoding test data.
+Most modern programming languages provide this ability.
+
+For very short multi-line strings one can get away with using \\n or
+\\r\\n in a regular string::
+
+  "line one\nline two"
+
+but readability quickly suffers as these strings get longer.  An alternative is
+to put one string on each line and rely on automatic string concatenation by
+the compiler::
+
+  "line one\n"
+  "line two"
+
+The problem here is that changing the contents of the string quickly becomes an
+editing chore as you attempt to keep the lines similar length and remember to
+put the \\n at the end.  Having a multi-line string literal syntax would
+alleviate both of these problems.
+
+
+Specification
+=============
+
+Multi-line string literals are delimited by three double quote characters on
+each end.  The BNF, which augments the `Character and String Literals
+<https://opendylan.org/books/drm/Lexical_Grammar#HEADING-117-38>`_ section in
+the DRM, is ::
+
+  MULTI-LINE-STRING:
+
+      """ more-multi-line-string
+
+  MORE-MULTI-LINE-STRING:
+
+      multi-line-string-character more-multi-line-string
+
+      """
+
+  MULTI-LINE-STRING-CHARACTER:
+
+      any printing character (including space) except for \\
+
+      \\ escape-character
+
+Escape characters are interpreted as with the standard STRING production.
+Literal end-of-line sequences (\\n and \\r\\n) are always interpreted as a
+single newline character, regardless of operating system platform.
+
+Examples:
+
+Equivalent to ``"abc"``::
+
+  """abc"""
+
+Equivalent to ``"line one\nline two"``::
+
+  """line one
+  line two"""
+
+Equivalent to ``"let x = \"foo\";"``::
+
+  """let x = "foo";"""
+
+Equivalent to ``"\nfoo\nbar\n"``::
+
+  """
+  foo
+  bar
+  """
+
+
+Reference Implementation
+========================
+
+A reference implementation can be found `on github
+<https://github.com/cgay/opendylan/commits/multi-line-strings>`_.  As of this
+writing, the implementation is functional but needs a few internal cleanups.
+
+
+Open Issues
+===========
+
+This proposal currently has no provision for string literals in which there
+is no escape sequence interpretation, i.e. "raw" strings.
+
+
+
+Revision History
+================
+
+The revision history of this document is available here:
+https://github.com/dylan-lang/website/commits/master/source/proposals/dep-0008-multi-line-strings.rst
diff --git a/documentation/website/source/proposals/dep-0010-element-otherwise.rst b/documentation/website/source/proposals/dep-0010-element-otherwise.rst
new file mode 100644
index 0000000000..f5a98f20e5
--- /dev/null
+++ b/documentation/website/source/proposals/dep-0010-element-otherwise.rst
@@ -0,0 +1,81 @@
+**********************************
+Defaulted Element Reference Syntax
+**********************************
+
+===============  =============================================
+DEP #:           10
+Type:            Standards Track
+Author:          Peter S. Housel
+Status:          Draft
+Created:         13-Oct-2018
+Last-Modified:   24-Feb-2019
+Post-History:    `04-Mar-2019 <https://groups.google.com/forum/#!topic/dylan-lang/AmXDa5iNJOU/discussion>`_
+Target-Version:  2019.1
+===============  =============================================
+
+
+Revision History
+================
+
+The revision history of this document is available here:
+https://github.com/dylan-lang/website/commits/master/source/proposals/dep-0010-element-otherwise.rst
+
+Abstract
+========
+
+The Dylan language currently provides bracketed element reference
+syntax as a shorthand for calls to the :drm:`element` and :drm:`aref`
+functions. This DEP proposes an element reference syntax for providing
+default values for :drm:`element` calls.
+
+Motivation
+==========
+
+The element reference syntax ``collection[i]`` is a compact way of
+writing ``element(collection, i)``. However, whenever supplying a
+default becomes necessary, element reference syntax cannot be
+used. Sometimes this results in a mixing of the two styles in the same
+area of code. Adding defaulted element reference syntax can improve
+the conciseness and readability of code.
+
+Specification
+=============
+
+To the `operand` nonterminal identifier we add the following phrase
+grammar rule:
+
+   | `operand`: `operand` ``[`` `arguments` :subscript:`opt` ``]`` ``otherwise`` `otherwise-operand`
+
+In addition we add the following nonterminal and phrase grammar rules:
+
+   | `otherwise-operand`:
+   |     `leaf`
+   |     `SYMBOL`
+
+Just as ``collection[i]`` is syntactic sugar for ``element(collection, i)``
+under the interpretation of ``element`` in force for the module
+where it appears, the ``collection[i] otherwise y`` syntax is
+equivalent to ``element(collection, i, default: y)``.
+
+Rationale
+=========
+
+Note that to prevent parsing ambiguities the operand of the
+``otherwise`` clause uses the `leaf` grammar nonterminal rather than
+the `expression` nonterminal used for function call arguments. This
+requires that complex default value expressions be parenthesized, but
+since in practice most supplied defaults are either literals or
+(constant) variable names this should not provide much of an
+inconvenience.
+
+Backwards Compatibility
+=======================
+
+The addition of this new legal syntax does not affect the
+interpretation of existing programs.
+
+Reference Implementation
+========================
+
+A reference implementation for Open Dylan can be found at
+https://github.com/dylan-lang/opendylan/tree/element-otherwise
diff --git a/documentation/website/source/proposals/dep-0011-numeric-literal-syntax.rst b/documentation/website/source/proposals/dep-0011-numeric-literal-syntax.rst
new file mode 100644
index 0000000000..7b867b8d41
--- /dev/null
+++ b/documentation/website/source/proposals/dep-0011-numeric-literal-syntax.rst
@@ -0,0 +1,121 @@
+**********************
+Numeric Literal Syntax
+**********************
+
+===============  =============================================
+DEP #:           11
+Type:            Standards Track
+Author:          Carl Gay
+Status:          Final
+Created:         11-Feb-2019 (Thomas Edison's birthday)
+Last-Modified:   13-Feb-2019
+Post-History:    `04-Mar-2019 <https://groups.google.com/forum/#!topic/dylan-lang/Wb3D6ioe1GM/discussion>`_
+Target-Version:  Open Dylan 2019.1
+===============  =============================================
+
+
+Abstract
+========
+
+This DEP proposes to change the literal syntax for Dylan integers and
+floating point numbers by allowing the underscore character to be used
+between any two digits.
+
+Motivation
+==========
+
+This change is designed to aid readability of large integers and large
+or high precision floats.
+
+Consider ::
+
+  define constant $nanos-per-second = 1000000000;
+
+vs ::
+
+  define constant $nanos-per-second = 1_000_000_000;
+
+This should eliminate the need to count groups of three digits to be
+certain you're reading it correctly.
+
+Proposal
+========
+
+The Dylan lexical grammar is changed as follows:
+
+* For clarity, a new character class is introduced with a single
+  character, underscore (_):
+
+  | underscore:
+  |     _
+
+* underscore :subscript:`opt` is added to the second alternative of
+  the `decimal-integer`, `binary-integer`, `octal-integer`, and
+  `hex-integer` productions:
+
+  | binary-integer:
+  |     binary-digit
+  |     binary-integer underscore :subscript:`opt` binary-digit
+
+  | octal-integer:
+  |     octal-digit
+  |     octal-integer underscore :subscript:`opt` octal-digit
+
+  | decimal-integer:
+  |     decimal-digit
+  |     decimal-integer underscore :subscript:`opt` decimal-digit
+
+  | hex-integer:
+  |     hex-digit
+  |     hex-integer underscore :subscript:`opt` hex-digit
+
+The proposed change in floating point numeric syntax follows because
+the `floating-point` production references the `decimal-integer`
+production.
+
+Examples of valid numeric literals include::
+
+  1_000_000
+  -4_000_000
+  2.000_002
+  3_000.000_123
+  4.0e1_000
+  #xdead_beef
+  #b1111_0000
+
+and also::
+
+  1_2_3_4_5_6_7  // valid but not recommended
+
+Examples of uses of underscore that are **not** allowed include::
+
+  1__2
+  _123
+  -123_
+  1_.23
+  1._23
+  1.23_
+  #x_feed
+  #o777_
+
+Reference Implementation
+========================
+
+This was incorporated into Open Dylan 2020.1 in this commit
+`<https://github.com/dylan-lang/opendylan/commit/0b3c60e279c21b137c05051153738bc4034072e4>`_.
+
+
+Backward Compatibility
+======================
+
+Dylan code that uses the new syntax is not compatible with older
+versions of Dylan compilers. Any code that uses the new syntax creates
+a dependency on the Open Dylan version in which this feature is
+released.  In particular, this syntax should not be used in compiler
+code (or supporting libraries) until it is supported by the oldest
+bootstrapping compiler.
+
+Copyright
+=========
+
+This document may be freely redistributed.
diff --git a/documentation/website/source/proposals/dep-0012-string-literals.rst b/documentation/website/source/proposals/dep-0012-string-literals.rst
new file mode 100644
index 0000000000..3de39f2246
--- /dev/null
+++ b/documentation/website/source/proposals/dep-0012-string-literals.rst
@@ -0,0 +1,358 @@
+*********************
+String Literal Syntax
+*********************
+
+===============  =============================================
+DEP #:           12
+Supersedes:      DEP 8, multi-line-strings
+Type:            Standards Track
+Affects-DRM:     Yes
+Author:          Carl Gay
+Status:          Draft
+Created:         22-Mar-2023
+Last-Modified:   19-Aug-2023
+Post-History:    `28-Mar-2023 <https://groups.google.com/g/dylan-lang/c/xhofah0KYt8>`_
+Target-Version:  2023.2
+===============  =============================================
+
+
+Abstract
+========
+
+Dylan string literals have two deficiencies when compared to many current
+programming languages, most notably the inability to encode multi-line strings
+into a single source token that crosses multiple source lines and no fully
+supported way to represent unescaped ("raw") strings. This DEP proposes a
+literal syntax for both of these cases. Briefly, it proposes syntax for
+one-line raw strings delimited by ``#r"``, multi-line strings delimited by
+``"""`` and ``#r"""``, and quoted symbols delimited by ``#"""``.
+
+
+Rationale
+=========
+
+Summary: Literal syntax to address both of these deficiencies would be nice to
+have and is something that people expect to exist in modern programming
+languages.
+
+Multi-line String Literals
+--------------------------
+
+While it should be noted that encoding long string literals into source code is
+not good practice when internationalization is desired, it is convenient to
+have this ability for quick scripts, for encoding test data, and as simple
+format string templates.  Most modern programming languages provide this
+ability.
+
+For very short multi-line strings one can get away with using \\n or
+\\r\\n in a regular string::
+
+  "line one\nline two"
+
+but readability quickly suffers as these strings get longer.  An alternative is
+to put one string on each line and rely on automatic string concatenation by
+the compiler::
+
+  "line one\n"
+  "line two"
+
+The problem here is that changing the contents of the string quickly becomes an
+editing chore as the programmer attempts to keep the lines a similar length,
+and remembering to put the \\n at the end of each line.  Having a multi-line
+string literal syntax would alleviate both of these problems.
+
+Raw String Literals
+-------------------
+
+Raw string literals (that is, strings in which ``'\\'`` is not a special
+character) are useful for inputting data that needs to contain many ``'\\'``
+characters. The primary example of this is regular expressions, which quickly
+become difficult to interpret when they themselves contain many backslashes.
+
+Open Dylan has a fairly simple work-around for this problem, which it calls
+`parser expansions
+<https://opendylan.org/documentation/library-reference/language-extensions/parser-expansions.html>`_::
+
+   define function string-parser (s) s end;
+   define constant s1 = "\\.\\[\\*\\\\\\]";     // standard Dylan
+   define constant s2 = #:string:"\.\[\*\\\]";  // uses string-parser
+
+There are some problems with this mechanism:
+
+#. Because the parser can have any name ("string" in the above example) and
+   various different delimiters, it's difficult to provide good editor support.
+
+#. The parser only allows a single character to delimit the string, meaning
+   that that character is forbidden within the string literal.  For long string
+   literals it can be hard to predict which delimiter character (if any) will
+   not be needed.
+
+#. For the relatively common task of specifying a raw string, each individual
+   library needs to either define ``string-parser`` or import it. (This could
+   be made easier by exporting it from the ``common-dylan`` module.)
+
+#. This kind of parser prevents consecutive string literal concatenation by the
+   compiler because the reader doesn't produce a string literal fragment for
+   it.  Instead it emits a call to ``string-parser``.
+
+Having a standard raw string literal syntax would eliminate or reduce these
+problems.
+
+
+Specification
+=============
+
+Multi-line string literals are delimited by three double quote characters on
+each end: ``"""``. Any string literal, whether one-line or multi-line, may be
+prefixed with ``#r`` or ``#R`` to disable backslash escape processing, i.e., to
+make it a "raw" string literal.
+
+Literal end-of-line sequences are always interpreted as a single LF character,
+in both raw and escaped string literals, regardless of operating system
+platform. Specifically,
+
+#. CR (character code 13) by itself is converted to a single LF (character code
+   10).
+
+#. CRLF (character codes 13 10, when occurring consecutively) are converted to
+   a single LF (character code 10).
+
+An implication of this design is that the only way to include a CR character in
+a string literal is with the escape sequence ``\r`` in a non-raw string.
+
+All string literals, whether escaped, raw, one-line, or multi-line, continue to
+adhere to the rule that consecutive string literals separated by only
+whitespace are automatically concatenated.
+
+Because Dylan's quoted symbol syntax (also known as "unique string" syntax) is
+just `#` followed by any standard string, we also allow ``#"""`` to indicate a
+multi-line quoted symbol, to be consistent. No new syntax is provided to create
+a "raw" quoted symbols, i.e., quoted symbols without escape processing.
+
+The Rectangle Rule
+------------------
+
+`The Rectangle Rule
+<https://github.com/google/google-java-format/wiki/The-Rectangle-Rule>`_ states
+
+  When a source file is formatted, each subtree gets its own bounding
+  rectangle, containing all of that subtree’s text and none of any other
+  subtree’s.
+
+To permit (but not require) Dylan source code to conform to that rule,
+multi-line string literals need special treatment of leading whitespace. In the
+following two examples the programmer wants to ensure that there is no leading
+whitespace on any line in the resulting string literal token:
+
+.. code-block:: dylan
+   :linenos:
+   :caption: Without support for the Rectangle Rule
+   :emphasize-lines: 3,4,5
+
+   define method foo ()
+     let text = """bits on the wire
+   protocols well understood
+   where did my mail go?
+   """;
+     ...
+   end method;
+
+Here, without special handling for leading whitespace, there is no choice but
+to put the first line of text on the same line with ``"""`` and to left-align
+the highlighted lines, harming readability due to violating the Rectangle Rule.
+
+.. code-block:: dylan
+   :linenos:
+   :emphasize-lines: 3,4,5,6
+   :caption: With support for the Rectangle Rule
+
+   define method foo ()
+     let text = """
+                bits on the wire
+                protocols well understood
+                where did my mail go?
+                """;
+     ...
+   end method;
+
+Here, the ``\n`` (and any other whitespace) after the opening delimiter is
+removed and leading whitespace is removed from the highlighted lines in the
+resulting string literal token, so they may be moved (as a unit) left or right
+without affecting the result.
+
+To achieve this we adopt the techniques used for `raw strings in C#
+<https://learn.microsoft.com/en-us/dotnet/csharp/programming-guide/strings/#raw-string-literals>`_.
+
+The following rules apply to both raw and non-raw multi-line string literals:
+
+* Starts and ends with a sequence of at least three double quote characters
+  (``"""``, ``#r"""``, or ``#R"""``). More than three consecutive ``"``
+  characters are allowed to start and end the sequence in order to support
+  string literals that contain three (or more) repeated ``"`` characters.
+
+* Single line string literals that use triple-double-quoting require the
+  opening and closing delimiters to be on the same line.
+
+* In multi-line string literals, any whitespace to the left of the closing
+  delimiter is removed from all lines of the string literal.
+
+* In multi-line string literals, whitespace to the left of the closing
+  delimiter must be identical on each line. For example, it is not valid to use
+  tab characters on one line and space characters on another.
+
+* In multi-line string literals, whitespace following the opening delimiter on
+  the same line is ignored.
+
+* In multi-line string literals, whitespace-only lines following the opening
+  delimiter are included in the string literal.
+
+BNF
+---
+
+In the Dylan Reference Manual, in the section `Tokens
+<https://opendylan.org/books/drm/Lexical_Grammar#HEADING-117-3>`_, ``#r`` is
+added to the ``#-word`` production.
+
+The BNF, which augments `Character and String Literals
+<https://opendylan.org/books/drm/Lexical_Grammar#HEADING-117-38>`_ in the DRM,
+is shown below.
+
+::
+
+    CHARACTER-LITERAL:
+        ' character '
+
+    character:
+        any printing character (including space) except for ' or \
+
+        \ escape-character
+
+    STRING:
+        " more-string
+
+        " " "... multi-line-string
+
+        # r raw-string
+
+    more-string:
+        string-character more-string
+
+        "
+
+    multi-line-string:
+        multi-line-string-character more-multi-line-string
+
+    more-multi-line-string:
+        multi-line-string-character more-multi-line-string
+
+        " " "...     (must match the number of " in start delimiter)
+
+    multi-line-string-character:
+        any character except for \ or the """... closing delimiter
+
+        \ escape-character
+
+    raw-string:
+        " more-raw-string
+
+        " " "... more-raw-string-multi-line
+
+    more-raw-string:
+        raw-string-character more-raw-string
+
+        "
+
+    more-raw-string-multi-line:
+        raw-string-character-multi-line more-raw-string-multi-line
+
+        " " "...     (must match the number of " in start delimiter)
+
+    string-character:
+        any printing character (including space) except for " or \
+
+        \ escape-character
+
+    raw-string-character:
+        any printing character (including space) except for "
+
+    raw-string-character-multi-line:
+        any character but not three " in a row
+
+    escape-character:
+        one of \ ' " a b e f n r t 0
+
+        < hex-digits >
+
+Examples
+--------
+
+Strings equivalent to ``"abc"``::
+
+  """abc"""
+  #r"abc"
+  #r"""abc"""
+
+  """
+  abc
+  """
+
+  #r"""
+  abc
+  """
+
+Multi-line string equivalent to ``"line one\nline two"``::
+
+  let text = """
+             line one
+             line two
+             """;
+
+Same as above because whitespace *to the left of the closing delimiter* is
+removed::
+
+  let text = """
+        line one
+        line two
+        """;
+
+Multi-line string equivalent to ``"\nline one\nline two\n"``::
+
+  let text = """
+
+             line one
+             line two
+
+             """;
+
+Same as above but using escape sequences::
+
+  let text = """
+             \nline one
+             line two\n
+             """;
+
+Equivalent to ``"let x = \"foo\";"``::
+
+  """let x = "foo";"""
+
+Raw string for ``C:\users\``::
+
+  #R"C:\users\"
+
+Equivalent to ``"^\\s*([0-9A-Fa-f]+)\\s*"``::
+
+  #r"^\s*([0-9A-Fa-f]+)\s*"
+
+
+Reference Implementation
+========================
+
+A reference implementation is underway `on github
+<https://github.com/cgay/opendylan/commits/dep12>`_.
+
+
+Revision History
+================
+
+The revision history of this document is available here:
+https://github.com/dylan-lang/website/commits/master/source/proposals/dep-0012-string-literals.rst
diff --git a/documentation/website/source/proposals/index.rst b/documentation/website/source/proposals/index.rst
new file mode 100644
index 0000000000..5947642fdf
--- /dev/null
+++ b/documentation/website/source/proposals/index.rst
@@ -0,0 +1,79 @@
+***************************
+Dylan Enhancement Proposals
+***************************
+
+.. NOTE: Each proposal must be in the "All Proposals by Number" table,
+   regardless of status.  Open proposals must ADDITIONALLY be in the
+   "Open Proposals" table.
+
+This is the list of Dylan Enhancement Proposals, known as DEPs. A DEP is a
+design document which
+
+* provides information to the Dylan community, or
+* describes a new feature for the Dylan language or its standard libraries, or
+* describes changes to the processes or environment surrounding the Dylan
+  language or Open Dylan.
+
+The DEP should provide a concise technical specification of, and rationale for,
+the feature or process.
+
+We intend DEPs to be the primary mechanism for proposing new features, for
+collecting community input on an issue, and for documenting the design
+decisions that have gone into Dylan.  The DEP author is responsible for
+building consensus within the community and documenting dissenting opinions.
+
+Because the DEPs are maintained as text files in a versioned repository, their
+`revision history
+<https://github.com/dylan-lang/website/tree/master/source/proposals>`_ is the
+historical record of the feature proposal.
+
+For more information on the DEP process, see DEP 1,
+:doc:`dep-0001-dep-process`.
+
+
+Open Proposals (under consideration)
+====================================
+
+==== ============= ========== =============================================
+#    Track         Status     Title
+==== ============= ========== =============================================
+1    Process       Draft      :doc:`dep-0001-dep-process`
+6    Standard      Draft      :doc:`dep-0006-single-file-library`
+10   Standard      Draft      :doc:`dep-0010-element-otherwise`
+12   Standard      Draft      :doc:`dep-0012-string-literals`
+==== ============= ========== =============================================
+
+
+All Proposals by Number
+=======================
+
+==== ============= ========== =============================================
+#    Track         Status     Title
+==== ============= ========== =============================================
+1    Process       Draft      :doc:`dep-0001-dep-process`
+2    Standard      Final      :doc:`dep-0002-define-function`
+3    Standard      Final      :doc:`dep-0003-c3-linearization`
+4    Standard      Final      :doc:`dep-0004-strings-library`
+5    Standard      Final      :doc:`dep-0005-subclass-function`
+6    Standard      Draft      :doc:`dep-0006-single-file-library`
+7    Standard      Draft      :doc:`dep-0007-collection-type-safety`
+8    Standard      Withdrawn  :doc:`dep-0008-multi-line-strings`
+10   Standard      Draft      :doc:`dep-0010-element-otherwise`
+11   Standard      Final      :doc:`dep-0011-numeric-literal-syntax`
+12   Standard      Draft      :doc:`dep-0012-string-literals`
+==== ============= ========== =============================================
+
+.. toctree::
+   :hidden:
+
+   dep-0001-dep-process
+   dep-0002-define-function
+   dep-0003-c3-linearization
+   dep-0004-strings-library
+   dep-0005-subclass-function
+   dep-0006-single-file-library
+   dep-0007-collection-type-safety
+   dep-0008-multi-line-strings
+   dep-0010-element-otherwise
+   dep-0011-numeric-literal-syntax
+   dep-0012-string-literals
diff --git a/documentation/website/source/release-notes b/documentation/website/source/release-notes
new file mode 120000
index 0000000000..03d71a2b05
--- /dev/null
+++ b/documentation/website/source/release-notes
@@ -0,0 +1 @@
+../_packages/opendylan/current/src/documentation/release-notes
\ No newline at end of file
diff --git a/documentation/website/source/sphinx-extensions b/documentation/website/source/sphinx-extensions
new file mode 120000
index 0000000000..c767a36d4a
--- /dev/null
+++ b/documentation/website/source/sphinx-extensions
@@ -0,0 +1 @@
+../_packages/sphinx-extensions/current/src
\ No newline at end of file
diff --git a/documentation/website/source/style-guide b/documentation/website/source/style-guide
new file mode 120000
index 0000000000..1724574758
--- /dev/null
+++ b/documentation/website/source/style-guide
@@ -0,0 +1 @@
+../_packages/opendylan/current/src/documentation/style-guide
\ No newline at end of file
diff --git a/documentation/website/update-opendylan.org.sh b/documentation/website/update-opendylan.org.sh
new file mode 100755
index 0000000000..c0c846f158
--- /dev/null
+++ b/documentation/website/update-opendylan.org.sh
@@ -0,0 +1,21 @@
+#!/bin/bash -xe
+
+# This script is intended to be run from cron.
+
+logfile=/var/log/update-opendylan.org.`date +%Y%m%d%H%M`.log
+exec > $logfile 2>&1
+
+exe_dir="$(realpath $(dirname $0))"
+
+dest_dir=/var/www/opendylan.org
+
+# Update the repo first so we get any changes to the update.sh script,
+# dependencies, etc.
+git pull --rebase origin master
+
+${exe_dir}/update.sh "${dest_dir}"
+
+echo "Done updating opendylan.org in ${dest_DIR}."
+bzip2 $logfile
+# Keep 10 days of logs.
+find /var/log -name 'update-opendylan.org.*' -mtime +10 -print -exec rm {} \;
diff --git a/documentation/website/update.sh b/documentation/website/update.sh
new file mode 100755
index 0000000000..bcbee5b32e
--- /dev/null
+++ b/documentation/website/update.sh
@@ -0,0 +1,56 @@
+#!/bin/bash -xe
+
+# This script builds the opendylan.org website. It does a clean build of the
+# docs each time and copies files to ${dest_dir}, meaning that there could be
+# cruft left around in ${dest_dir}. Might want to fix that some day.
+
+# /var/www/opendylan.org/downloads is handled specially. New versions of Open
+# Dylan should be copied there by hand, or ... we could stop doing that.
+
+# Note the -e in the #! line above causes this script to abort on any command
+# failure.
+
+if [[ $# -ne 1 ]]; then
+    echo "Usage: `basename $0` dest_dir"
+    echo "  dest_dir:    Directory in which to place the built website documents."
+    echo "               Example: /var/www/opendylan.org"
+    exit 2
+fi
+
+# Get latest gendoc, DRM, DPG, etc, as specified in dylan-package.json.
+echo "Updating the Dylan workspace to get latest packages..."
+dylan update
+dylan build gendoc
+
+website_dir=$(realpath $(dirname "$0"))
+
+dest_dir=$(realpath "$1")
+if [[ ! -d "$dest_dir" ]]; then
+    echo "dest_dir ${dest_dir} doesn't exist, aborting."
+    exit 2
+fi
+
+gendoc_exe=${website_dir}/_build/bin/gendoc
+
+# Packages are downloaded here.
+gendoc_work_dir=$(mktemp -d gendoc-XXXX)
+
+# Doc for each package is generated in
+# ${gendoc_output_dir}/package/<package-name>
+gendoc_output_dir=${website_dir}/source
+echo "Generating package docs in ${gendoc_output_dir}..."
+
+rm -rf ${gendoc_output_dir}/package
+${gendoc_exe} -o ${gendoc_output_dir}
+
+echo "Building website..."
+make html
+rsync -avz build/html/ ${dest_dir}
+
+echo "Updating DRM files..."
+mkdir -p ${dest_dir}/books/drm
+rsync -avz _packages/dylan-reference-manual/current/src/source/  ${dest_dir}/books/drm
+
+echo "Updating DPG files..."
+mkdir -p ${dest_dir}/books/dpg
+rsync -avz _packages/dylan-programming-book/current/src/source/  ${dest_dir}/books/dpg