checkpoint

Failed attempt to construct missing `Repr` instances recursively.
The correct solution is to track the reason for a TC failure.
Or, add support at the TC procedure for generating "missing
instances". That is, when `TC` fails to find global instances for
`Repr Foo`, it tries to invoke the `deriving` handler. It seems a bit crazy.

.gitattributes

@@ -1,3 +1,3 @@
 *.expected.out -text
-doc/changes.md merge=union
+RELEASES.md merge=union
 stage0/** binary linguist-generated

.github/workflows/ci.yml

@@ -9,12 +9,35 @@ on:
     branches:
       - master
   schedule:
-    - cron: '0 0 * * *'
+    - cron: '0 7 * * *'  # 8AM CET/11PM PT
 
 jobs:
-  Build:
+  set-nightly:
     # don't schedule nightlies on forks
-    if: github.event_name != 'schedule' || github.repository == 'leanprover/lean4'
+    if: github.event_name == 'schedule' && github.repository == 'leanprover/lean4'
+    runs-on: ubuntu-latest
+    outputs:
+      nightly: ${{ steps.set.outputs.nightly }}
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v2
+      - name: Set Nightly
+        id: set
+        run: |
+          if [[ -n '${{ secrets.PUSH_NIGHTLY_TOKEN }}' ]]; then
+            git remote add nightly https://foo:'${{ secrets.PUSH_NIGHTLY_TOKEN }}'@github.com/${{ github.repository_owner }}/lean4-nightly.git
+            git fetch nightly --tags
+            LEAN_VERSION_STRING="nightly-$(date -u +%F)"
+            # do nothing if commit already has a different tag
+            if [[ $(git name-rev --name-only --tags --no-undefined HEAD 2> /dev/null || echo $LEAN_VERSION_STRING) == $LEAN_VERSION_STRING ]]; then
+              echo "::set-output name=nightly::$LEAN_VERSION_STRING"
+            fi
+          fi
+
+  build:
+    needs: set-nightly
+    # `always` *must* be used to continue even after a dependency has been skipped
+    if: always() && (github.event_name != 'schedule' || github.repository == 'leanprover/lean4')
     runs-on: ${{ matrix.os }}
     defaults:
       run:
@@ -27,9 +50,11 @@ jobs:
             os: ubuntu-latest
             release: true
             shell: nix-shell --arg pkgsDist "import (fetchTarball \"channel:nixos-19.03\") {{}}" --run "bash -euxo pipefail {0}"
-            llvm-url: https://github.com/leanprover/lean-llvm/releases/download/13.0.0/lean-llvm-x86_64-linux-gnu.tar.zst
-            prepare-llvm: script/prepare-llvm-linux.sh lean-llvm*
+            llvm-url: https://github.com/leanprover/lean-llvm/releases/download/14.0.0/lean-llvm-x86_64-linux-gnu.tar.zst
+            prepare-llvm: ../script/prepare-llvm-linux.sh lean-llvm*
             binary-check: ldd -v
+            # foreign code may be linked against more recent glibc
+            CTEST_OPTIONS: -E 'foreign|leanlaketest_git'
           - name: Linux
             os: ubuntu-latest
             check-stage3: true
@@ -41,13 +66,24 @@ jobs:
             os: ubuntu-latest
             # turn off custom allocator & symbolic functions to make LSAN do its magic
             CMAKE_OPTIONS: -DLEAN_EXTRA_CXX_FLAGS=-fsanitize=address,undefined -DLEANC_EXTRA_FLAGS='-fsanitize=address,undefined -fsanitize-link-c++-runtime' -DSMALL_ALLOCATOR=OFF -DBSYMBOLIC=OFF
+            # exclude problematic tests
+            CTEST_OPTIONS: -E laketest
           - name: macOS
             os: macos-latest
             release: true
             shell: bash -euxo pipefail {0}
             CMAKE_OPTIONS: -DCMAKE_OSX_DEPLOYMENT_TARGET=10.15
-            llvm-url: https://github.com/leanprover/lean-llvm/releases/download/13.0.0/lean-llvm-x86_64-apple-darwin.tar.zst
-            prepare-llvm: script/prepare-llvm-macos.sh lean-llvm*
+            llvm-url: https://github.com/leanprover/lean-llvm/releases/download/14.0.0/lean-llvm-x86_64-apple-darwin.tar.zst
+            prepare-llvm: ../script/prepare-llvm-macos.sh lean-llvm*
+            binary-check: otool -L
+          - name: macOS aarch64
+            os: macos-latest
+            release: true
+            cross: true
+            shell: bash -euxo pipefail {0}
+            CMAKE_OPTIONS: -DCMAKE_OSX_DEPLOYMENT_TARGET=10.15 -DUSE_GMP=OFF -DLEAN_INSTALL_SUFFIX=-darwin_aarch64
+            llvm-url: https://github.com/leanprover/lean-llvm/releases/download/14.0.0/lean-llvm-aarch64-apple-darwin.tar.zst https://github.com/leanprover/lean-llvm/releases/download/14.0.0/lean-llvm-x86_64-apple-darwin.tar.zst
+            prepare-llvm: EXTRA_FLAGS=--target=aarch64-apple-darwin ../script/prepare-llvm-macos.sh lean-llvm-aarch64-* lean-llvm-x86_64-*
             binary-check: otool -L
           - name: Windows
             os: windows-2022
@@ -56,9 +92,17 @@ jobs:
             CMAKE_OPTIONS: -G "Unix Makefiles"
             # for reasons unknown, interactivetests are flaky on Windows
             CTEST_OPTIONS: --repeat until-pass:2
-            llvm-url: https://github.com/leanprover/lean-llvm/releases/download/13.0.0/lean-llvm-x86_64-w64-windows-gnu.tar.zst
-            prepare-llvm: script/prepare-llvm-mingw.sh lean-llvm*
+            llvm-url: https://github.com/leanprover/lean-llvm/releases/download/14.0.0/lean-llvm-x86_64-w64-windows-gnu.tar.zst
+            prepare-llvm: ../script/prepare-llvm-mingw.sh lean-llvm*
             binary-check: ldd
+          - name: Linux aarch64
+            os: ubuntu-latest
+            CMAKE_OPTIONS: -DCMAKE_PREFIX_PATH=$GMP -DLEAN_INSTALL_SUFFIX=-linux_aarch64
+            release: true
+            cross: true
+            shell: nix-shell --arg pkgsDist "import (fetchTarball \"channel:nixos-19.03\") {{ localSystem.config = \"aarch64-unknown-linux-gnu\"; }}" --run "bash -euxo pipefail {0}"
+            llvm-url: https://github.com/leanprover/lean-llvm/releases/download/14.0.0/lean-llvm-x86_64-linux-gnu.tar.zst https://github.com/leanprover/lean-llvm/releases/download/14.0.0/lean-llvm-aarch64-linux-gnu.tar.zst
+            prepare-llvm: EXTRA_FLAGS=--target=aarch64-unknown-linux-gnu ../script/prepare-llvm-linux.sh lean-llvm-aarch64-* lean-llvm-x86_64-*
       # complete all jobs
       fail-fast: false
     name: ${{ matrix.name }}
@@ -70,12 +114,13 @@ jobs:
       CCACHE_MAXSIZE: 200M
       # squelch error message about missing nixpkgs channel
       NIX_BUILD_SHELL: bash
+      LSAN_OPTIONS: max_leaks=10
+      # somehow MinGW clang64 (or cmake?) defaults to `g++` even though it doesn't exist
+      CXX: c++
     steps:
       - name: Checkout
         uses: actions/checkout@v2
         with:
-          # interferes with lean4-nightly authentication
-          persist-credentials: false
           submodules: true
       - name: Install Nix
         uses: cachix/install-nix-action@v15
@@ -84,7 +129,8 @@ jobs:
         uses: msys2/setup-msys2@v2
         with:
           msystem: clang64
-          install: make python mingw-w64-clang-x86_64-cmake mingw-w64-clang-x86_64-clang mingw-w64-clang-x86_64-ccache git zip unzip diffutils binutils tree mingw-w64-clang-x86_64-zstd tar
+          # `:p` means prefix with appropriate msystem prefix
+          pacboy: "make python cmake:p clang:p ccache:p gmp:p git zip unzip diffutils binutils tree zstd:p tar"
         if: matrix.os == 'windows-2022'
       - name: Install Brew Packages
         run: |
@@ -94,35 +140,27 @@ jobs:
         uses: actions/cache@v2
         with:
           path: .ccache
-          key: ${{ matrix.name }}-build-${{ github.sha }}
+          key: ${{ matrix.name }}-build-v3-${{ github.sha }}
           # fall back to (latest) previous cache
           restore-keys: |
-            ${{ matrix.name }}-build
+            ${{ matrix.name }}-build-v3
       - name: Setup
         run: |
           # open nix-shell once for initial setup
           true
         if: matrix.os == 'ubuntu-latest'
-      # remove problematic tests for sanitized build
-      - name: Pre build
-        run: rm tests/compiler/StackOverflow.lean tests/compiler/StackOverflowTask.lean
-        if: matrix.name == 'Linux fsanitize'
       - name: Build
         run: |
           mkdir build
           cd build
           OPTIONS=()
-          [[ -z '${{ matrix.llvm-url }}' ]] || wget -q ${{ matrix.llvm-url }}
-          [[ -z '${{ matrix.prepare-llvm }}' ]] || eval "OPTIONS+=($(../${{ matrix.prepare-llvm }}))"
-          if [[ $GITHUB_EVENT_NAME == 'schedule' && -n '${{ matrix.release }}' && -n '${{ secrets.PUSH_NIGHTLY_TOKEN }}' ]]; then
-            git remote add nightly https://foo:'${{ secrets.PUSH_NIGHTLY_TOKEN }}'@github.com/${{ github.repository_owner }}/lean4-nightly.git
-            git fetch nightly --tags
-            LEAN_VERSION_STRING="nightly-$(date -u +%F)"
-            # do nothing if commit already has a different tag
-            if [[ $(git name-rev --name-only --tags --no-undefined HEAD 2> /dev/null || echo $LEAN_VERSION_STRING) == $LEAN_VERSION_STRING ]]; then
-              OPTIONS+=(-DLEAN_SPECIAL_VERSION_DESC=$LEAN_VERSION_STRING)
-              echo "LEAN_VERSION_STRING=$LEAN_VERSION_STRING" >> $GITHUB_ENV
-            fi
+          if [[ -n '${{ matrix.prepare-llvm }}' ]]; then
+            wget -q ${{ matrix.llvm-url }}
+            PREPARE="$(${{ matrix.prepare-llvm }})"
+            eval "OPTIONS+=($PREPARE)"
+          fi
+          if [[ -n '${{ matrix.release }}' && -n '${{ needs.set-nightly.outputs.nightly }}' ]]; then
+            OPTIONS+=(-DLEAN_SPECIAL_VERSION_DESC=${{ needs.set-nightly.outputs.nightly }})
           fi
           # contortion to support empty OPTIONS with old macOS bash
           cmake .. ${{ matrix.CMAKE_OPTIONS }} ${OPTIONS[@]+"${OPTIONS[@]}"} -DLEAN_INSTALL_PREFIX=$PWD/..
@@ -139,25 +177,34 @@ jobs:
           dir=$(echo lean-*)
           mkdir pack
           # high-compression tar.zst + zip for release, fast tar.zst otherwise
-          if [[ ${{ startsWith(github.ref, 'refs/tags/v') && matrix.release }} == true || -n ${LEAN_VERSION_STRING:-} ]]; then
+          if [[ '${{ startsWith(github.ref, 'refs/tags/v') && matrix.release }}' == true || -n '${{ needs.set-nightly.outputs.nightly }}' ]]; then
             tar cf - $dir | zstd -T0 --no-progress -19 -o pack/$dir.tar.zst
-            zip -r pack/$dir.zip $dir
+            zip -rq pack/$dir.zip $dir
           else
             tar cf - $dir | zstd -T0 --no-progress -o pack/$dir.tar.zst
           fi
       - uses: actions/upload-artifact@v2
+        if: matrix.release
         with:
           name: build-${{ matrix.name }}
-          path: pack/*.zst
+          path: pack/*
+      - name: Trigger TPIL build
+        run: |
+          curl -u '${{ github.repository_owner }}:${{ secrets.PUSH_NIGHTLY_TOKEN }}' 'https://api.github.com/repos/leanprover/theorem_proving_in_lean4/dispatches' -X POST -d '{ "event_type": "build_event" }'
+        if: matrix.name == 'Linux release' && github.event_name == 'push' && github.repository == 'leanprover/lean4'
       - name: Lean stats
         run: |
           build/stage1/bin/lean --stats src/Lean.lean
+        if: ${{ !matrix.cross }}
       - name: Test
         run: |
           cd build/stage1
-          ctest -j4 --output-on-failure --timeout 300 ${{ matrix.CTEST_OPTIONS }} < /dev/null
+          # exclude nonreproducible test
+          ctest -j4 --output-on-failure -E leanlaketest_git ${{ matrix.CTEST_OPTIONS }} < /dev/null
+        if: ${{ !matrix.cross }}
       - name: Check Test Binary
         run: ${{ matrix.binary-check }} tests/compiler/534.lean.out
+        if: ${{ !matrix.cross }}
       - name: Build Stage 2
         run: |
           cd build
@@ -172,7 +219,8 @@ jobs:
         run: |
           echo -1 | sudo tee /proc/sys/kernel/perf_event_paranoid
           export BUILD=$PWD/build PATH=$PWD/build/stage1/bin:$PATH
-          nix-shell -A with-temci --run "cd tests/bench; temci exec --config speedcenter.yaml --included_blocks fast --runs 1"
+          cd tests/bench
+          nix shell .#temci -c temci exec --config speedcenter.yaml --included_blocks fast --runs 1
         if: matrix.test-speedcenter
       - name: Check rebootstrap
         run: |
@@ -181,40 +229,62 @@ jobs:
         if: matrix.name == 'Linux'
       - name: CCache stats
         run: ccache -s
+
+  release:
+    # When GitHub says "If a job fails, all jobs that need it are skipped unless
+    # the jobs use a conditional expression that causes the job to continue.", don't believe
+    # their lies. It's actually the entire closure (i.e. including `set-nightly`) that
+    # must succeed for subsequent to be run without `always()`.
+    if: always() && needs.build.result == 'success' && startsWith(github.ref, 'refs/tags/v')
+    runs-on: ubuntu-latest
+    needs: build
+    steps:
+      - uses: actions/download-artifact@v2
+        with:
+          path: artifacts
       - name: Release
         uses: softprops/action-gh-release@v1
-        if: ${{ startsWith(github.ref, 'refs/tags/v') && matrix.release }}
         with:
-          files: pack/*
+          files: artifacts/*/*
+          fail_on_unmatched_files: true
         env:
           GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+
+  release-nightly:
+    needs: [set-nightly, build]
+    if: needs.set-nightly.outputs.nightly
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v2
+        with:
+          # needed for tagging
+          fetch-depth: 0
+          token: ${{ secrets.PUSH_NIGHTLY_TOKEN }}
+      - uses: actions/download-artifact@v2
+        with:
+          path: artifacts
       - name: Prepare Nightly Release
-        if: env.LEAN_VERSION_STRING
         run: |
-          # can't push shallow checkout
-          git fetch --unshallow
+          git remote add nightly https://foo:'${{ secrets.PUSH_NIGHTLY_TOKEN }}'@github.com/${{ github.repository_owner }}/lean4-nightly.git
           git fetch nightly --tags
-          if git tag $LEAN_VERSION_STRING && git push nightly $LEAN_VERSION_STRING; then
-            last_tag=$(git describe HEAD^ --abbrev=0 --tags)
-            echo -e "Changes since ${last_tag}:\n\n" > diff.md
-            #git show $last_tag:doc/changes.md > old.md
-            #./script/diff_changelogs.py old.md doc/changes.md >> diff.md
-            echo -e "*Full commit log*\n" >> diff.md
-            git log --oneline $last_tag..HEAD | sed 's/^/* /' >> diff.md
-          else
-            # make sure every runner is building the same commit
-            [ $(git rev-parse HEAD) == $(git rev-parse $LEAN_VERSION_STRING) ] || exit 11
-            echo -n > diff.md
-          fi
+          git tag ${{ needs.set-nightly.outputs.nightly }}
+          git push nightly ${{ needs.set-nightly.outputs.nightly }}
+          last_tag=$(git describe HEAD^ --abbrev=0 --tags)
+          echo -e "*Changes since ${last_tag}:*\n\n" > diff.md
+          git show $last_tag:RELEASES.md > old.md
+          #./script/diff_changelogs.py old.md doc/changes.md >> diff.md
+          diff --changed-group-format='%>' --unchanged-group-format='' old.md RELEASES.md >> diff.md || true
+          echo -e "\n*Full commit log*\n" >> diff.md
+          git log --oneline $last_tag..HEAD | sed 's/^/* /' >> diff.md
       - name: Release Nightly
-        # need unreleased version for fixed `repository`
-        uses: Kha/action-gh-release@master
-        if: env.LEAN_VERSION_STRING
+        uses: softprops/action-gh-release@v1
         with:
           body_path: diff.md
           prerelease: true
-          files: pack/*
-          tag_name: ${{ env.LEAN_VERSION_STRING }}
+          files: artifacts/*/*
+          fail_on_unmatched_files: true
+          tag_name: ${{ needs.set-nightly.outputs.nightly }}
           repository: ${{ github.repository_owner }}/lean4-nightly
         env:
           GITHUB_TOKEN: ${{ secrets.PUSH_NIGHTLY_TOKEN }}

.github/workflows/nix-ci.yml

@@ -14,18 +14,14 @@ jobs:
     runs-on: ${{ matrix.os }}
     defaults:
       run:
-        # Can't use `nix-shell` without configured nixpkgs path on macOS
         shell: nix -v --experimental-features "nix-command flakes" run .#ciShell -- bash -euxo pipefail {0}
     strategy:
       matrix:
         include:
-          - name: Linux
+          - name: Nix Linux
             os: ubuntu-latest
-            # latest builds on https://hydra.nixos.org/jobset/nix/master/all at the time
-            nix_url: https://hydra.nixos.org/build/135773533/download/1/nix-2.4pre20210125_36c4d6f-x86_64-linux.tar.xz
-          #- name: macOS
-          #  os: macos-latest
-          #  nix_url: https://hydra.nixos.org/build/135773542/download/1/nix-2.4pre20210125_36c4d6f-x86_64-darwin.tar.xz
+          - name: Nix macOS
+            os: macos-latest
       # complete all jobs
       fail-fast: false
     name: ${{ matrix.name }}
@@ -34,39 +30,30 @@ jobs:
     steps:
       - name: Checkout
         uses: actions/checkout@v2
-      # Install flakes-enabled Nix manually from Hydra since `install-nix-action` doesn't accept raw tarballs
       - name: Install Nix
-        shell: bash -euo pipefail {0}
-        run: |
-          curl ${{ matrix.nix_url }} | tar -xJ
-          # Do a single-user install so actions/cache doesn't get confused about permissions
-          nix-*/install --no-daemon --no-channel-add --darwin-use-unencrypted-nix-store-volume
-          rm -rf nix-*
-      # Call `install-nix-action` anyways to run its Actions-specific setup
-      - name: Setup Nix
-        uses: cachix/install-nix-action@v12
-      - name: Fixup install-nix-action
-        shell: bash -euo pipefail {0}
-        run: |
-          # the path set by install-nix-action is valid only for multi-user installations
-          echo "NIX_SSL_CERT_FILE=$HOME/.nix-profile/etc/ssl/certs/ca-bundle.crt" > $GITHUB_ENV
-        if: matrix.name == 'macOS'
-      - name: Further setup Nix
-        run: |
-          mkdir -p ~/.config/nix
-          echo '
-            max-jobs = auto
+        uses: cachix/install-nix-action@v15
+        with:
+          extra_nix_config: |
             extra-sandbox-paths = /nix/var/cache/ccache
-            extra-substituters = file://${{ github.workspace }}/nix-store-cache?priority=10&trusted=true
-            extra-trusted-substituters = https://lean4.cachix.org/
-            extra-trusted-public-keys = lean4.cachix.org-1:mawtxSxcaiWE24xCXXgh3qnvlTkyU7evRRnGeAhD4Wk=' > ~/.config/nix/nix.conf
+            substituters = file://${{ github.workspace }}/nix-store-cache-copy?priority=10&trusted=true https://cache.nixos.org
+      - name: Set Up Nix Cache
+        uses: actions/cache@v2
+        with:
+          path: nix-store-cache
+          key: ${{ matrix.name }}-nix-store-cache-${{ github.sha }}
+          # fall back to (latest) previous cache
+          restore-keys: |
+            ${{ matrix.name }}-nix-store-cache
+      - name: Further Set Up Nix Cache
+        shell: bash -euxo pipefail {0}
+        run: |
+          # Nix seems to mutate the cache, so make a copy
+          cp -r nix-store-cache nix-store-cache-copy || true
+      - name: Prepare CCache Cache
+        shell: bash -euxo pipefail {0}
+        run: |
           sudo mkdir -m0770 -p /nix/var/cache/ccache
-          # macOS standard chown doesn't support --reference
-          nix shell .#nixpkgs.coreutils -c sudo chown --reference=/nix /nix/var/cache/ccache
-          echo 'max_size = 50M' > /nix/var/cache/ccache/ccache.conf
-
-          # install & use Cachix manually since `cachix-action` pushes *all* derivations (incl. `$mod-deps`, stage 2&3, etc.)
-          [ -z '${{ secrets.CACHIX_AUTH_TOKEN }}' ] || nix-env -iA cachix -f https://cachix.org/api/v1/install
+          sudo chown -R $USER /nix/var/cache/ccache
       - name: Setup CCache Cache
         uses: actions/cache@v2
         with:
@@ -75,31 +62,33 @@ jobs:
           # fall back to (latest) previous cache
           restore-keys: |
             ${{ matrix.name }}-nix-ccache
-      - name: Setup Nix Cache
-        uses: actions/cache@v2
+      - name: Further Set Up CCache Cache
+        shell: bash -euxo pipefail {0}
+        run: |
+          sudo chown -R root:nixbld /nix/var/cache
+          sudo chmod -R 770 /nix/var/cache
+      - name: Install Cachix
+        uses: cachix/cachix-action@v10
         with:
-          path: nix-store-cache
-          key: ${{ matrix.name }}-nix-store-cache-${{ github.sha }}
-          # fall back to (latest) previous cache
-          restore-keys: |
-            ${{ matrix.name }}-nix-store-cache
+          name: lean4
+          authToken: '${{ secrets.CACHIX_AUTH_TOKEN }}'
+          skipPush: true  # we push specific outputs only
       - name: Build
         run: |
           # .o files are not a runtime dependency on macOS because of lack of thin archives
-          nix build $NIX_BUILD_ARGS .#stage0 .#stage1.lean-all .#Lean.oTree -o push-build
+          # leanc_src is required for building Leanc-deps
+          nix build $NIX_BUILD_ARGS .#stage0 .#stage1.lean-all .#lean-bin-tools-unwrapped.leanc_src .#Lean.oTree .#iTree -o push-build
       - name: Test
         run: |
           nix build $NIX_BUILD_ARGS .#test -o push-test
       - name: Build manual
         run: |
-          nix build $NIX_BUILD_ARGS .#mdbook .#doc-test -o push-doc
-          nix build $NIX_BUILD_ARGS .#doc
-        if: matrix.name == 'Linux'
+          nix build $NIX_BUILD_ARGS --update-input lean --no-write-lock-file ./doc#{lean-mdbook,leanInk,alectryon,test} -o push-doc
+          nix build $NIX_BUILD_ARGS --update-input lean --no-write-lock-file ./doc
+        if: matrix.name == 'Nix Linux'
       - name: Push to Cachix
         run: |
-          [ -z "$CACHIX_AUTH_TOKEN" ] || cachix push -j4 lean4 ./push-* || true
-        env:
-          CACHIX_AUTH_TOKEN: '${{ secrets.CACHIX_AUTH_TOKEN }}'
+          [ -z "${{ secrets.CACHIX_AUTH_TOKEN }}" ] || cachix push -j4 lean4 ./push-* || true
       - name: Rebuild Nix Store Cache
         run: |
           rm -rf nix-store-cache || true
@@ -110,6 +99,9 @@ jobs:
           github_token: ${{ secrets.GITHUB_TOKEN }}
           publish_dir: ./result
           destination_dir: ./doc
-        if: matrix.name == 'Linux' && github.ref == 'refs/heads/master' && github.event_name == 'push'
+        if: matrix.name == 'Nix Linux' && github.ref == 'refs/heads/master' && github.event_name == 'push'
+      - name: Fixup CCache Cache
+        run: |
+          sudo chown -R $USER /nix/var/cache/ccache
       - name: CCache stats
         run: CCACHE_DIR=/nix/var/cache/ccache nix run .#nixpkgs.ccache -- -s

.ignore

@@ -0,0 +1 @@
+stage0/

README.md

@@ -3,9 +3,13 @@ This is the repository for **Lean 4**, which is currently being released as mile
 
 # About
 
+- [Quickstart](https://github.com/leanprover/lean4/blob/master/doc/quickstart.md)
 - [Homepage](https://leanprover.github.io)
 - [Theorem Proving Tutorial](https://leanprover.github.io/theorem_proving_in_lean4/)
+- [Functional Programming in Lean](https://leanprover.github.io/functional_programming_in_lean/) **first chapter is available!**
 - [Manual](https://leanprover.github.io/lean4/doc/)
+- [Release notes](RELEASES.md) starting at v4.0.0-m3
+- [Examples](https://leanprover.github.io/lean4/doc/examples.html)
 - [FAQ](https://leanprover.github.io/lean4/doc/faq.html)
 
 # Installation

RELEASES.md

@@ -0,0 +1,745 @@
+Unreleased
+---------
+
+* Try to elaborate `do` notation even if the expected type is not available. We still delay elaboration when the expected type
+  is not available. This change is particularly useful when writing examples such as
+  ```lean
+  #eval do
+    IO.println "hello"
+    IO.println "world"
+  ```
+  That is, we don't have to use the idiom `#eval show IO _ from do ...` anymore.
+  Note that auto monadic lifting is less effective when the expected type is not available.
+  Monadic polymorphic functions (e.g., `ST.Ref.get`) also require the expected type.
+
+* On Linux, panics now print a backtrace by default, which can be disabled by setting the environment variable `LEAN_BACKTRACE` to `0`.
+  Other platforms are TBD.
+
+* The `group(·)` `syntax` combinator is now introduced automatically where necessary, such as when using multiple parsers inside `(...)+`.
+
+* Add ["Typed Macros"](https://github.com/leanprover/lean4/pull/1251): syntax trees produced and accepted by syntax antiquotations now remember their syntax kinds, preventing accidental production of ill-formed syntax trees and reducing the need for explicit `:kind` antiquotation annotations. See PR for details.
+
+* Aliases of protected definitions are protected too. Example:
+  ```lean
+  protected def Nat.double (x : Nat) := 2*x
+
+  namespace Ex
+  export Nat (double) -- Add alias Ex.double for Nat.double
+  end Ex
+
+  open Ex
+  #check Ex.double -- Ok
+  #check double -- Error, `Ex.double` is alias for `Nat.double` which is protected
+  ```
+
+* Use `IO.getRandomBytes` to initialize random seed for `IO.rand`. See discussion at [this PR](https://github.com/leanprover/lean4-samples/pull/2).
+
+* Improve dot notation and aliases interaction. See discussion on [Zulip](https://leanprover.zulipchat.com/#narrow/stream/270676-lean4/topic/Namespace-based.20overloading.20does.20not.20find.20exports/near/282946185) for additional details.
+  Example:
+  ```lean
+  def Set (α : Type) := α → Prop
+  def Set.union (s₁ s₂ : Set α) : Set α := fun a => s₁ a ∨ s₂ a
+  def FinSet (n : Nat) := Fin n → Prop
+
+  namespace FinSet
+    export Set (union) -- FinSet.union is now an alias for `Set.union`
+  end FinSet
+
+  example (x y : FinSet 10) : FinSet 10 :=
+    x.union y -- Works
+  ```
+
+* `ext` and `enter` conv tactics can now go inside let-declarations. Example:
+  ```lean
+  example (g : Nat → Nat) (y : Nat) (h : let x := y + 1; g (0+x) = x) : g (y + 1) = y + 1 := by
+    conv at h => enter [x, 1, 1]; rw [Nat.zero_add]
+    /-
+      g : Nat → Nat
+      y : Nat
+      h : let x := y + 1;
+          g x = x
+      ⊢ g (y + 1) = y + 1
+    -/
+    exact h
+  ```
+
+* Add `zeta` conv tactic to expand let-declarations. Example:
+  ```lean
+  example (h : let x := y + 1; 0 + x = y) : False := by
+    conv at h => zeta; rw [Nat.zero_add]
+    /-
+      y : Nat
+      h : y + 1 = y
+      ⊢ False
+    -/
+    simp_arith at h
+  ```
+
+* Improve namespace resolution. See issue [#1224](https://github.com/leanprover/lean4/issues/1224). Example:
+  ```lean
+  import Lean
+  open Lean Parser Elab
+  open Tactic -- now opens both `Lean.Parser.Tactic` and `Lean.Elab.Tactic`
+  ```
+
+* Rename `constant` command to `opaque`. See discussion at [Zulip](https://leanprover.zulipchat.com/#narrow/stream/270676-lean4/topic/What.20is.20.60opaque.60.3F/near/284926171).
+
+* Extend `induction` and `cases` syntax: multiple left-hand-sides in a single alternative. This extension is very similar to the one implemented for `match` expressions. Examples:
+  ```lean
+  inductive Foo where
+    | mk1 (x : Nat) | mk2 (x : Nat) | mk3
+
+  def f (v : Foo) :=
+    match v with
+    | .mk1 x => x + 1
+    | .mk2 x => 2*x + 1
+    | .mk3   => 1
+
+  theorem f_gt_zero : f v > 0 := by
+    cases v with
+    | mk1 x | mk2 x => simp_arith!  -- New feature used here!
+    | mk3 => decide
+  ```
+
+* [`let/if` indentation in `do` blocks in now supported.](https://github.com/leanprover/lean4/issues/1120)
+
+* Update Lake to v3.1.1. See the [v3.1.0 release note](https://github.com/leanprover/lake/releases/tag/v3.1.0) for detailed changes.
+
+* Add unnamed antiquotation `$_` for use in syntax quotation patterns.
+
+* [Add unused variables linter](https://github.com/leanprover/lean4/pull/1159). Feedback welcome!
+
+* Lean now generates an error if the body of a declaration body contains a universe parameter that does not occur in the declaration type, nor is an explicit parameter.
+  Examples:
+  ```lean
+  /-
+  The following declaration now produces an error because `PUnit` is universe polymorphic,
+  but the universe parameter does not occur in the function type `Nat → Nat`
+  -/
+  def f (n : Nat) : Nat :=
+    let aux (_ : PUnit) : Nat := n + 1
+    aux ⟨⟩
+
+  /-
+  The following declaration is accepted because the universe parameter was explicitly provided in the
+  function signature.
+  -/
+  def g.{u} (n : Nat) : Nat :=
+    let aux (_ : PUnit.{u}) : Nat := n + 1
+    aux ⟨⟩
+  ```
+
+* Add `subst_vars` tactic.
+
+* [Fix `autoParam` in structure fields lost in multiple inheritance.](https://github.com/leanprover/lean4/issues/1158).
+
+* Add `[eliminator]` attribute. It allows users to specify default recursor/eliminators for the `induction` and `cases` tactics.
+  It is an alternative for the `using` notation. Example:
+  ```lean
+  @[eliminator] protected def recDiag {motive : Nat → Nat → Sort u}
+      (zero_zero : motive 0 0)
+      (succ_zero : (x : Nat) → motive x 0 → motive (x + 1) 0)
+      (zero_succ : (y : Nat) → motive 0 y → motive 0 (y + 1))
+      (succ_succ : (x y : Nat) → motive x y → motive (x + 1) (y + 1))
+      (x y : Nat) :  motive x y :=
+    let rec go : (x y : Nat) → motive x y
+      | 0,     0 => zero_zero
+      | x+1, 0   => succ_zero x (go x 0)
+      | 0,   y+1 => zero_succ y (go 0 y)
+      | x+1, y+1 => succ_succ x y (go x y)
+    go x y
+  termination_by go x y => (x, y)
+
+  def f (x y : Nat) :=
+    match x, y with
+    | 0,   0   => 1
+    | x+1, 0   => f x 0
+    | 0,   y+1 => f 0 y
+    | x+1, y+1 => f x y
+  termination_by f x y => (x, y)
+
+  example (x y : Nat) : f x y > 0 := by
+    induction x, y <;> simp [f, *]
+  ```
+
+* Add support for `casesOn` applications to structural and well-founded recursion modules.
+  This feature is useful when writing definitions using tactics. Example:
+  ```lean
+  inductive Foo where
+    | a | b | c
+    | pair: Foo × Foo → Foo
+
+  def Foo.deq (a b : Foo) : Decidable (a = b) := by
+    cases a <;> cases b
+    any_goals apply isFalse Foo.noConfusion
+    any_goals apply isTrue rfl
+    case pair a b =>
+      let (a₁, a₂) := a
+      let (b₁, b₂) := b
+      exact match deq a₁ b₁, deq a₂ b₂ with
+      | isTrue h₁, isTrue h₂ => isTrue (by rw [h₁,h₂])
+      | isFalse h₁, _ => isFalse (fun h => by cases h; cases (h₁ rfl))
+      | _, isFalse h₂ => isFalse (fun h => by cases h; cases (h₂ rfl))
+  ```
+
+* `Option` is again a monad. The auxiliary type `OptionM` has been removed. See [Zulip thread](https://leanprover.zulipchat.com/#narrow/stream/270676-lean4/topic/Do.20we.20still.20need.20OptionM.3F/near/279761084).
+
+* Improve `split` tactic. It used to fail on `match` expressions of the form `match h : e with ...` where `e` is not a free variable.
+  The failure used to occur during generalization.
+
+
+* New encoding for `match`-expressions that use the `h :` notation for discriminants. The information is not lost during delaboration,
+  and it is the foundation for a better `split` tactic. at delaboration time. Example:
+  ```lean
+  #print Nat.decEq
+  /-
+  protected def Nat.decEq : (n m : Nat) → Decidable (n = m) :=
+  fun n m =>
+    match h : Nat.beq n m with
+    | true => isTrue (_ : n = m)
+    | false => isFalse (_ : ¬n = m)
+  -/
+```
+
+* `exists` tactic is now takes a comma separated list of terms.
+
+* Add `dsimp` and `dsimp!` tactics. They guarantee the result term is definitionally equal, and only apply
+  `rfl`-theorems.
+
+* Fix binder information for `match` patterns that use definitions tagged with `[matchPattern]` (e.g., `Nat.add`).
+  We now have proper binder information for the variable `y` in the following example.
+  ```lean
+  def f (x : Nat) : Nat :=
+    match x with
+    | 0 => 1
+    | y + 1 => y
+  ```
+
+* (Fix) the default value for structure fields may now depend on the structure parameters. Example:
+  ```lean
+  structure Something (i: Nat) where
+  n1: Nat := 1
+  n2: Nat := 1 + i
+
+  def s : Something 10 := {}
+  example : s.n2 = 11 := rfl
+  ```
+
+* Apply `rfl` theorems at the `dsimp` auxiliary method used by `simp`. `dsimp` can be used anywhere in an expression
+  because it preserves definitional equality.
+
+* Refine auto bound implicit feature. It does not consider anymore unbound variables that have the same
+  name of a declaration being defined. Example:
+  ```lean
+  def f : f → Bool := -- Error at second `f`
+    fun _ => true
+
+  inductive Foo : List Foo → Type -- Error at second `Foo`
+    | x : Foo []
+  ```
+  Before this refinement, the declarations above would be accepted and the
+  second `f` and `Foo` would be treated as auto implicit variables. That is,
+  `f : {f : Sort u} → f → Bool`, and
+  `Foo : {Foo : Type u} → List Foo → Type`.
+
+
+* Fix syntax hightlighting for recursive declarations. Example
+  ```lean
+  inductive List (α : Type u) where
+    | nil : List α  -- `List` is not highlighted as a variable anymore
+    | cons (head : α) (tail : List α) : List α
+
+  def List.map (f : α → β) : List α → List β
+    | []    => []
+    | a::as => f a :: map f as -- `map` is not highlighted as a variable anymore
+  ```
+* Add `autoUnfold` option to `Lean.Meta.Simp.Config`, and the following macros
+  - `simp!` for `simp (config := { autoUnfold := true })`
+  - `simp_arith!` for `simp (config := { autoUnfold := true, arith := true })`
+  - `simp_all!` for `simp_all (config := { autoUnfold := true })`
+  - `simp_all_arith!` for `simp_all (config := { autoUnfold := true, arith := true })`
+
+  When the `autoUnfold` is set to true, `simp` tries to unfold the following kinds of definition
+  - Recursive definitions defined by structural recursion.
+  - Non-recursive definitions where the body is a `match`-expression. This
+    kind of definition is only unfolded if the `match` can be reduced.
+  Example:
+  ```lean
+  def append (as bs : List α) : List α :=
+    match as with
+    | [] => bs
+    | a :: as => a :: append as bs
+
+  theorem append_nil (as : List α) : append as [] = as := by
+    induction as <;> simp_all!
+
+  theorem append_assoc (as bs cs : List α) : append (append as bs) cs = append as (append bs cs) := by
+    induction as <;> simp_all!
+  ```
+
+* Add `save` tactic for creating checkpoints more conveniently. Example:
+  ```lean
+  example : <some-proposition> := by
+    tac_1
+    tac_2
+    save
+    tac_3
+    ...
+  ```
+  is equivalent to
+  ```lean
+  example : <some-proposition> := by
+    checkpoint
+      tac_1
+      tac_2
+    tac_3
+    ...
+  ```
+
+* Remove support for `{}` annotation from inductive datatype contructors. This annotation was barely used, and we can control the binder information for parameter bindings using the new inductive family indices to parameter promotion. Example: the following declaration using `{}`
+  ```lean
+  inductive LE' (n : Nat) : Nat → Prop where
+    | refl {} : LE' n n -- Want `n` to be explicit
+    | succ  : LE' n m → LE' n (m+1)
+  ```
+  can now be written as
+  ```lean
+  inductive LE' : Nat → Nat → Prop where
+    | refl (n : Nat) : LE' n n
+    | succ : LE' n m → LE' n (m+1)
+  ```
+  In both cases, the inductive family has one parameter and one index.
+  Recall that the actual number of parameters can be retrieved using the command `#print`.
+
+* Remove support for `{}` annotation in the `structure` command.
+
+* Several improvements to LSP server. Examples: "jump to definition" in mutually recursive sections, fixed incorrect hover information in "match"-expression patterns, "jump to definition" for pattern variables, fixed auto-completion in function headers, etc.
+
+* In `macro ... xs:p* ...` and similar macro bindings of combinators, `xs` now has the correct type `Array Syntax`
+
+* Identifiers in syntax patterns now ignore macro scopes during matching.
+
+* Improve binder names for constructor auto implicit parameters. Example, given the inductive datatype
+  ```lean
+  inductive Member : α → List α → Type u
+    | head : Member a (a::as)
+    | tail : Member a bs → Member a (b::bs)
+  ```
+  before:
+  ```lean
+  #check @Member.head
+  -- @Member.head : {x : Type u_1} → {a : x} → {as : List x} → Member a (a :: as)
+  ```
+  now:
+  ```lean
+  #check @Member.head
+  -- @Member.head : {α : Type u_1} → {a : α} → {as : List α} → Member a (a :: as)
+  ```
+
+* Improve error message when constructor parameter universe level is too big.
+
+* Add support for `for h : i in [start:stop] do .. ` where `h : i ∈ [start:stop]`. This feature is useful for proving
+  termination of functions such as:
+  ```lean
+  inductive Expr where
+    | app (f : String) (args : Array Expr)
+
+  def Expr.size (e : Expr) : Nat := Id.run do
+    match e with
+    | app f args =>
+      let mut sz := 1
+      for h : i in [: args.size] do
+        -- h.upper : i < args.size
+        sz := sz + size (args.get ⟨i, h.upper⟩)
+      return sz
+  ```
+
+* Add tactic `case'`. It is similar to `case`, but does not admit the goal on failure.
+  For example, the new tactic is useful when writing tactic scripts where we need to use `case'`
+  at `first | ... | ...`, and we want to take the next alternative when `case'` fails.
+
+* Add tactic macro
+  ```lean
+  macro "stop" s:tacticSeq : tactic => `(repeat sorry)
+  ```
+  See discussion on [Zulip](https://leanprover.zulipchat.com/#narrow/stream/270676-lean4/topic/Partial.20evaluation.20of.20a.20file).
+
+* When displaying goals, we do not display inaccessible proposition names
+if they do not have forward dependencies. We still display their types.
+For example, the goal
+  ```lean
+  case node.inl.node
+  β : Type u_1
+  b : BinTree β
+  k : Nat
+  v : β
+  left : Tree β
+  key : Nat
+  value : β
+  right : Tree β
+  ihl : BST left → Tree.find? (Tree.insert left k v) k = some v
+  ihr : BST right → Tree.find? (Tree.insert right k v) k = some v
+  h✝ : k < key
+  a✝³ : BST left
+  a✝² : ForallTree (fun k v => k < key) left
+  a✝¹ : BST right
+  a✝ : ForallTree (fun k v => key < k) right
+  ⊢ BST left
+  ```
+  is now displayed as
+  ```lean
+  case node.inl.node
+  β : Type u_1
+  b : BinTree β
+  k : Nat
+  v : β
+  left : Tree β
+  key : Nat
+  value : β
+  right : Tree β
+  ihl : BST left → Tree.find? (Tree.insert left k v) k = some v
+  ihr : BST right → Tree.find? (Tree.insert right k v) k = some v
+   : k < key
+   : BST left
+   : ForallTree (fun k v => k < key) left
+   : BST right
+   : ForallTree (fun k v => key < k) right
+  ⊢ BST left
+  ```
+
+* The hypothesis name is now optional in the `by_cases` tactic.
+
+* [Fix inconsistency between `syntax` and kind names](https://github.com/leanprover/lean4/issues/1090).
+  The node kinds `numLit`, `charLit`, `nameLit`, `strLit`, and `scientificLit` are now called
+  `num`, `char`, `name`, `str`, and `scientific` respectively. Example: we now write
+  ```lean
+  macro_rules | `($n:num) => `("hello")
+  ```
+  instead of
+  ```lean
+  macro_rules | `($n:numLit) => `("hello")
+  ```
+
+* (Experimental) New `checkpoint <tactic-seq>` tactic for big interactive proofs.
+
+* Rename tactic `nativeDecide` => `native_decide`.
+
+* Antiquotations are now accepted in any syntax. The `incQuotDepth` `syntax` parser is therefore obsolete and has been removed.
+
+* Renamed tactic `nativeDecide` => `native_decide`.
+
+* "Cleanup" local context before elaborating a `match` alternative right-hand-side. Examples:
+  ```lean
+  example (x : Nat) : Nat :=
+    match g x with
+    | (a, b) => _ -- Local context does not contain the auxiliary `_discr := g x` anymore
+
+  example (x : Nat × Nat) (h : x.1 > 0) : f x > 0 := by
+    match x with
+    | (a, b) => _ -- Local context does not contain the `h✝ : x.fst > 0` anymore
+  ```
+
+* Improve `let`-pattern (and `have`-pattern) macro expansion. In the following example,
+  ```lean
+  example (x : Nat × Nat) : f x > 0 := by
+    let (a, b) := x
+    done
+  ```
+  The resulting goal is now `... |- f (a, b) > 0` instead of `... |- f x > 0`.
+
+* Add cross-compiled [aarch64 Linux](https://github.com/leanprover/lean4/pull/1066) and [aarch64 macOS](https://github.com/leanprover/lean4/pull/1076) releases.
+
+* [Add tutorial-like examples to our documentation](https://github.com/leanprover/lean4/tree/master/doc/examples), rendered using LeanInk+Alectryon.
+
+v4.0.0-m4 (23 March 2022)
+---------
+
+* `simp` now takes user-defined simp-attributes. You can define a new `simp` attribute by creating a file (e.g., `MySimp.lean`) containing
+  ```lean
+  import Lean
+  open Lean.Meta
+
+  initialize my_ext : SimpExtension ← registerSimpAttr `my_simp "my own simp attribute"
+  ```
+  If you don't neet to acces `my_ext`, you can also use the macro
+  ```lean
+  import Lean
+
+  register_simp_attr my_simp "my own simp attribute"
+  ```
+  Recall that the new `simp` attribute is not active in the Lean file where it was defined.
+  Here is a small example using the new feature.
+  ```lean
+  import MySimp
+
+  def f (x : Nat) := x + 2
+  def g (x : Nat) := x + 1
+
+  @[my_simp] theorem f_eq : f x = x + 2 := rfl
+  @[my_simp] theorem g_eq : g x = x + 1 := rfl
+
+  example : f x + g x = 2*x + 3 := by
+    simp_arith [my_simp]
+  ```
+
+* Extend `match` syntax: multiple left-hand-sides in a single alternative. Example:
+  ```lean
+  def fib : Nat → Nat
+  | 0 | 1 => 1
+  | n+2 => fib n + fib (n+1)
+  ```
+  This feature was discussed at [issue 371](https://github.com/leanprover/lean4/issues/371). It was implemented as a macro expansion. Thus, the following is accepted.
+  ```lean
+  inductive StrOrNum where
+    | S (s : String)
+    | I (i : Int)
+
+  def StrOrNum.asString (x : StrOrNum) :=
+    match x with
+    | I a | S a => toString a
+  ```
+
+
+* Improve `#eval` command. Now, when it fails to synthesize a `Lean.MetaEval` instance for the result type, it reduces the type and tries again. The following example now works without additional annotations
+  ```lean
+  def Foo := List Nat
+
+  def test (x : Nat) : Foo :=
+    [x, x+1, x+2]
+
+  #eval test 4
+  ```
+
+* `rw` tactic can now apply auto-generated equation theorems for a given definition. Example:
+  ```lean
+  example (a : Nat) (h : n = 1) : [a].length = n := by
+    rw [List.length]
+    trace_state -- .. |- [].length + 1 = n
+    rw [List.length]
+    trace_state -- .. |- 0 + 1 = n
+    rw [h]
+  ```
+
+* [Fuzzy matching for auto completion](https://github.com/leanprover/lean4/pull/1023)
+
+* Extend dot-notation `x.field` for arrow types. If type of `x` is an arrow, we look up for `Function.field`.
+For example, given `f : Nat → Nat` and `g : Nat → Nat`, `f.comp g` is now notation for `Function.comp f g`.
+
+* The new `.<identifier>` notation is now also accepted where a function type is expected.
+  ```lean
+  example (xs : List Nat) : List Nat := .map .succ xs
+  example (xs : List α) : Std.RBTree α ord := xs.foldl .insert ∅
+  ```
+
+* [Add code folding support to the language server](https://github.com/leanprover/lean4/pull/1014).
+
+* Support notation `let <pattern> := <expr> | <else-case>` in `do` blocks.
+
+* Remove support for "auto" `pure`. In the [Zulip thread](https://leanprover.zulipchat.com/#narrow/stream/270676-lean4/topic/for.2C.20unexpected.20need.20for.20type.20ascription/near/269083574), the consensus seemed to be that "auto" `pure` is more confusing than it's worth.
+
+* Remove restriction in `congr` theorems that all function arguments on the left-hand-side must be free variables. For example, the following theorem is now a valid `congr` theorem.
+  ```lean
+  @[congr]
+  theorem dep_congr [DecidableEq ι] {p : ι → Set α} [∀ i, Inhabited (p i)] :
+                    ∀ {i j} (h : i = j) (x : p i) (y : α) (hx : x = y), Pi.single (f := (p ·)) i x = Pi.single (f := (p ·)) j ⟨y, hx ▸ h ▸ x.2⟩ :=
+  ```
+
+* [Partially applied congruence theorems.](https://github.com/leanprover/lean4/issues/988)
+
+* Improve elaboration postponement heuristic when expected type is a metavariable. Lean now reduces the expected type before performing the test.
+
+* [Remove deprecated leanpkg](https://github.com/leanprover/lean4/pull/985) in favor of [Lake](https://github.com/leanprover/lake) now bundled with Lean.
+
+* Various improvements to go-to-definition & find-all-references accuracy.
+
+* Auto generated congruence lemmas with support for casts on proofs and `Decidable` instances (see [whishlist](https://github.com/leanprover/lean4/issues/988)).
+
+* Rename option `autoBoundImplicitLocal` => `autoImplicit`.
+
+* [Relax auto-implicit restrictions](https://github.com/leanprover/lean4/pull/1011). The command `set_option relaxedAutoImplicit false` disables the relaxations.
+
+* `contradiction` tactic now closes the goal if there is a `False.elim` application in the target.
+
+* Renamed tatic `byCases` => `by_cases` (motivation: enforcing naming convention).
+
+* Local instances occurring in patterns are now considered by the type class resolution procedure. Example:
+  ```lean
+  def concat : List ((α : Type) × ToString α × α) → String
+    | [] => ""
+    | ⟨_, _, a⟩ :: as => toString a ++ concat as
+  ```
+
+* Notation for providing the motive for `match` expressions has changed.
+  before:
+  ```lean
+  match x, rfl : (y : Nat) → x = y → Nat with
+  | 0,   h => ...
+  | x+1, h => ...
+  ```
+  now:
+  ```lean
+  match (motive := (y : Nat) → x = y → Nat) x, rfl with
+  | 0,   h => ...
+  | x+1, h => ...
+  ```
+  With this change, the notation for giving names to equality proofs in `match`-expressions is not whitespace sensitive anymore. That is,
+  we can now write
+  ```lean
+  match h : sort.swap a b with
+  | (r₁, r₂) => ... -- `h : sort.swap a b = (r₁, r₂)`
+  ```
+
+* `(generalizing := true)` is the default behavior for `match` expressions even if the expected type is not a proposition. In the following example, we used to have to include `(generalizing := true)` manually.
+  ```lean
+  inductive Fam : Type → Type 1 where
+    | any : Fam α
+    | nat : Nat → Fam Nat
+
+  example (a : α) (x : Fam α) : α :=
+    match x with
+    | Fam.any   => a
+    | Fam.nat n => n
+  ```
+
+* We now use `PSum` (instead of `Sum`) when compiling mutually recursive definitions using well-founded recursion.
+
+* Better support for parametric well-founded relations. See [issue #1017](https://github.com/leanprover/lean4/issues/1017). This change affects the low-level `termination_by'` hint because the fixed prefix of the function parameters in not "packed" anymore when constructing the well-founded relation type. For example, in the following definition, `as` is part of the fixed prefix, and is not packed anymore. In previous versions, the `termination_by'` term would be written as `measure fun ⟨as, i, _⟩ => as.size - i`
+  ```lean
+  def sum (as : Array Nat) (i : Nat) (s : Nat) : Nat :=
+    if h : i < as.size then
+      sum as (i+1) (s + as.get ⟨i, h⟩)
+    else
+      s
+  termination_by' measure fun ⟨i, _⟩ => as.size - i
+  ```
+
+* Add `while <cond> do <do-block>`, `repeat <do-block>`, and `repeat <do-block> until <cond>` macros for `do`-block. These macros are based on `partial` definitions, and consequently are useful only for writing programs we don't want to prove anything about.
+
+* Add `arith` option to `Simp.Config`, the macro `simp_arith` expands to `simp (config := { arith := true })`. Only `Nat` and linear arithmetic is currently supported. Example:
+  ```lean
+  example : 0 < 1 + x ∧ x + y + 2 ≥ y + 1 := by
+    simp_arith
+  ```
+
+* Add `fail <string>?` tactic that always fail.
+
+* Add support for acyclicity at dependent elimination. See [issue #1022](https://github.com/leanprover/lean4/issues/1022).
+
+* Add `trace <string>` tactic for debugging purposes.
+
+* Add nontrivial `SizeOf` instance for types `Unit → α`, and add support for them in the auto-generated `SizeOf` instances for user-defined inductive types. For example, given the inductive datatype
+  ```lean
+  inductive LazyList (α : Type u) where
+    | nil                               : LazyList α
+    | cons (hd : α) (tl : LazyList α)   : LazyList α
+    | delayed (t : Thunk (LazyList α))  : LazyList α
+  ```
+  we now have `sizeOf (LazyList.delayed t) = 1 + sizeOf t` instead of `sizeOf (LazyList.delayed t) = 2`.
+
+* Add support for guessing (very) simple well-founded relations when proving termination. For example, the following function does not require a `termination_by` annotation anymore.
+  ```lean
+  def Array.insertAtAux (i : Nat) (as : Array α) (j : Nat) : Array α :=
+    if h : i < j then
+      let as := as.swap! (j-1) j;
+      insertAtAux i as (j-1)
+    else
+      as
+  ```
+
+* Add support for `for h : x in xs do ...` notation where `h : x ∈ xs`. This is mainly useful for showing termination.
+
+* Auto implicit behavior changed for inductive families. An auto implicit argument occurring in inductive family index is also treated as an index (IF it is not fixed, see next item). For example
+  ```lean
+  inductive HasType : Index n → Vector Ty n → Ty → Type where
+  ```
+  is now interpreted as
+  ```lean
+  inductive HasType : {n : Nat} → Index n → Vector Ty n → Ty → Type where
+  ```
+
+* To make the previous feature more convenient to use, we promote a fixed prefix of inductive family indices to parameters. For example, the following declaration is now accepted by Lean
+  ```lean
+  inductive Lst : Type u → Type u
+    | nil  : Lst α
+    | cons : α → Lst α → Lst α
+  ```
+  and `α` in `Lst α` is a parameter. The actual number of parameters can be inspected using the command `#print Lst`. This feature also makes sure we still accept the declaration
+  ```lean
+  inductive Sublist : List α → List α → Prop
+    | slnil : Sublist [] []
+    | cons l₁ l₂ a : Sublist l₁ l₂ → Sublist l₁ (a :: l₂)
+    | cons2 l₁ l₂ a : Sublist l₁ l₂ → Sublist (a :: l₁) (a :: l₂)
+  ```
+
+* Added auto implicit "chaining". Unassigned metavariables occurring in the auto implicit types now become new auto implicit locals. Consider the following example:
+  ```lean
+  inductive HasType : Fin n → Vector Ty n → Ty → Type where
+    | stop : HasType 0 (ty :: ctx) ty
+    | pop  : HasType k ctx ty → HasType k.succ (u :: ctx) ty
+  ```
+  `ctx` is an auto implicit local in the two constructors, and it has type `ctx : Vector Ty ?m`. Without auto implicit "chaining", the metavariable `?m` will remain unassigned. The new feature creates yet another implicit local `n : Nat` and assigns `n` to `?m`. So, the declaration above is shorthand for
+  ```lean
+  inductive HasType : {n : Nat} → Fin n → Vector Ty n → Ty → Type where
+    | stop : {ty : Ty} → {n : Nat} → {ctx : Vector Ty n} → HasType 0 (ty :: ctx) ty
+    | pop  : {n : Nat} → {k : Fin n} → {ctx : Vector Ty n} → {ty : Ty} → HasType k ctx ty → HasType k.succ (u :: ctx) ty
+  ```
+
+* Eliminate auxiliary type annotations (e.g, `autoParam` and `optParam`) from recursor minor premises and projection declarations. Consider the following example
+  ```lean
+  structure A :=
+    x : Nat
+    h : x = 1 := by trivial
+
+  example (a : A) : a.x = 1 := by
+    have aux := a.h
+    -- `aux` has now type `a.x = 1` instead of `autoParam (a.x = 1) auto✝`
+    exact aux
+
+  example (a : A) : a.x = 1 := by
+    cases a with
+    | mk x h =>
+      -- `h` has now type `x = 1` instead of `autoParam (x = 1) auto✝`
+      assumption
+  ```
+
+* We now accept overloaded notation in patterns, but we require the set of pattern variables in each alternative to be the same. Example:
+  ```lean
+  inductive Vector (α : Type u) : Nat → Type u
+    | nil : Vector α 0
+    | cons : α → Vector α n → Vector α (n+1)
+
+  infix:67 " :: " => Vector.cons -- Overloading the `::` notation
+
+  def head1 (x : List α) (h : x ≠ []) : α :=
+    match x with
+    | a :: as => a -- `::` is `List.cons` here
+
+  def head2 (x : Vector α (n+1)) : α :=
+    match x with
+    | a :: as => a -- `::` is `Vector.cons` here
+  ```
+
+* New notation `.<identifier>` based on Swift. The namespace is inferred from the expected type. See [issue #944](https://github.com/leanprover/lean4/issues/944). Examples:
+  ```lean
+  def f (x : Nat) : Except String Nat :=
+    if x > 0 then
+      .ok x
+    else
+      .error "x is zero"
+
+  namespace Lean.Elab
+  open Lsp
+
+  def identOf : Info → Option (RefIdent × Bool)
+    | .ofTermInfo ti => match ti.expr with
+      | .const n .. => some (.const n, ti.isBinder)
+      | .fvar id .. => some (.fvar id, ti.isBinder)
+      | _ => none
+    | .ofFieldInfo fi => some (.const fi.projName, false)
+    | _ => none
+
+  def isImplicit (bi : BinderInfo) : Bool :=
+    bi matches .implicit
+
+  end Lean.Elab
+  ```

doc/SUMMARY.md

@@ -2,32 +2,44 @@
 
 - [What is Lean](./whatIsLean.md)
 - [Tour of Lean](./tour.md)
-- [Setting Up Lean](./setup.md)
-  - [Quickstart](./quickstart.md)
+- [Setting Up Lean](./quickstart.md)
+  - [Extended Setup Notes](./setup.md)
+- [Theorem Proving in Lean](./tpil.md)
+- [Functional Programming in Lean](fplean.md)
+- [Examples](./examples.md)
+  - [Palindromes](examples/palindromes.lean.md)
+  - [Binary Search Trees](examples/bintree.lean.md)
+  - [A Certified Type Checker](examples/tc.lean.md)
+  - [The Well-Typed Interpreter](examples/interp.lean.md)
+  - [Dependent de Bruijn Indices](examples/deBruijn.lean.md)
+  - [Parametric Higher-Order Abstract Syntax](examples/phoas.lean.md)
 
 # Language Manual
-- [Using Lean](./using_lean.md)
-- [Lexical Structure](./lexical_structure.md)
-- [Expressions](./expressions.md)
-- [Declarations](./declarations.md)
+<!-- - [Using Lean](./using_lean.md) -->
+<!-- - [Lexical Structure](./lexical_structure.md) -->
+<!-- - [Expressions](./expressions.md) -->
+<!-- - [Declarations](./declarations.md) -->
 - [Organizational features](./organization.md)
   - [Sections](./sections.md)
   - [Namespaces](./namespaces.md)
   - [Implicit Arguments](./implicit.md)
   - [Auto Bound Implicit Arguments](./autobound.md)
-- [Dependent Types](./deptypes.md)
-  - [Simple Type Theory](./simptypes.md)
-  - [Types as objects](./typeobjs.md)
-  - [Function Abstraction and Evaluation](./funabst.md)
-  - [Introducing Definitions](./introdef.md)
-  - [What makes dependent type theory dependent?](./dep.md)
-- [Tactics](./tactics.md)
+<!-- - [Dependent Types](./deptypes.md) -->
+<!--   - [Simple Type Theory](./simptypes.md) -->
+<!--   - [Types as objects](./typeobjs.md) -->
+<!--   - [Function Abstraction and Evaluation](./funabst.md) -->
+<!--   - [Introducing Definitions](./introdef.md) -->
+<!--   - [What makes dependent type theory dependent?](./dep.md) -->
+<!-- - [Tactics](./tactics.md) -->
 - [Syntax Extensions](./syntax.md)
   - [The `do` Notation](./do.md)
-  - [User-defined notation](./notation.md)
   - [String Interpolation](./stringinterp.md)
+  - [User-Defined Notation](./notation.md)
   - [Macro Overview](./macro_overview.md)
-  - [A Guided Example](./syntax_example.md)
+  - [Elaborators](./elaborators.md)
+  - [Examples](./syntax_examples.md)
+    - [Balanced Parentheses](./syntax_example.md)
+    - [Arithmetic DSL](./metaprogramming-arith.md)
 - [Declaring New Types](./decltypes.md)
   - [Enumerated Types](./enum.md)
   - [Inductive Types](./inductive.md)
@@ -47,7 +59,6 @@
   - [Thunk](./thunk.md)
   - [Task and Thread](./task.md)
 - [Functions](./functions.md)
-- [Tactics](./tactics.md)
 
 # Other
 
@@ -58,16 +69,15 @@
 # Development
 
 - [Development Guide](./dev/index.md)
-- [Commit Convention](./dev/commit_convention.md)
 - [Building Lean](./make/index.md)
   - [Ubuntu Setup](./make/ubuntu.md)
   - [macOS Setup](./make/osx-10.9.md)
   - [Windows MSYS2 Setup](./make/msys2.md)
   - [Windows with WSL](./make/wsl.md)
   - [Nix Setup (*Experimental*)](./make/nix.md)
-- [Foreign Function Interface](./dev/ffi.md)
-- [Unit Testing](./dev/testing.md)
-- [Building This Manual](./dev/mdbook.md)
-- [Fixing Tests](./dev/fixing_tests.md)
+- [Bootstrapping](./dev/bootstrap.md)
+- [Testing](./dev/testing.md)
 - [Debugging](./dev/debugging.md)
-- [C++ Coding Style](./dev/cpp_coding_style.md)
+- [Commit Convention](./dev/commit_convention.md)
+- [Building This Manual](./dev/mdbook.md)
+- [Foreign Function Interface](./dev/ffi.md)

doc/alectryon.css

@@ -0,0 +1,786 @@
+@charset "UTF-8";
+/*
+Copyright © 2019 Clément Pit-Claudel
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.
+*/
+
+/*******************************/
+/* CSS reset for .alectryon-io */
+/*******************************/
+
+.content {
+    /*
+    Use `initial` instead of `contents` to avoid a browser bug which removes
+    the element from the accessibility tree.
+    https://developer.mozilla.org/en-US/docs/Web/CSS/display#display_contents
+     */
+    display: initial;
+}
+
+.alectryon-io blockquote {
+    line-height: inherit;
+}
+
+.alectryon-io blockquote:after {
+    display: none;
+}
+
+.alectryon-io label {
+    display: inline;
+    font-size: inherit;
+    margin: 0;
+}
+
+.alectryon-io a {
+    text-decoration: none !important;
+    font-style: oblique !important;
+    color: unset;
+}
+
+/* Undo <small> and <blockquote>, added to improve RSS rendering. */
+
+.alectryon-io small.alectryon-output,
+.alectryon-io small.alectryon-type-info {
+    font-size: inherit;
+}
+
+.alectryon-io blockquote.alectryon-goal,
+.alectryon-io blockquote.alectryon-message {
+    font-weight: normal;
+    font-size: inherit;
+}
+
+/***************/
+/* Main styles */
+/***************/
+
+.alectryon-coqdoc .doc .code,
+.alectryon-coqdoc .doc .comment,
+.alectryon-coqdoc .doc .inlinecode,
+.alectryon-mref,
+.alectryon-block, .alectryon-io,
+.alectryon-toggle-label, .alectryon-banner {
+    font-family: "Source Code Pro", Consolas, "Ubuntu Mono", Menlo, "DejaVu Sans Mono", monospace, monospace !important;
+    font-size: 0.875em;
+    font-feature-settings: "COQX" 1 /* Coq ligatures */, "XV00" 1 /* Legacy */, "calt" 1 /* Fallback */;
+    line-height: initial;
+}
+
+.alectryon-io, .alectryon-block, .alectryon-toggle-label, .alectryon-banner {
+    overflow: visible;
+    overflow-wrap: break-word;
+    position: relative;
+    white-space: pre-wrap;
+}
+
+/*
+CoqIDE doesn't turn off the unicode bidirectional algorithm (and PG simply
+respects the user's `bidi-display-reordering` setting), so don't turn it off
+here either.  But beware unexpected results like `Definition test_אב := 0.`
+
+.alectryon-io span {
+    direction: ltr;
+    unicode-bidi: bidi-override;
+}
+
+In any case, make an exception for comments:
+
+.highlight .c {
+    direction: embed;
+    unicode-bidi: initial;
+}
+*/
+
+.alectryon-mref,
+.alectryon-mref-marker {
+    align-self: center;
+    box-sizing: border-box;
+    display: inline-block;
+    font-size: 80%;
+    font-weight: bold;
+    line-height: 1;
+    box-shadow: 0 0 0 1pt black;
+    padding: 1pt 0.3em;
+    text-decoration: none;
+}
+
+.alectryon-block .alectryon-mref-marker,
+.alectryon-io .alectryon-mref-marker {
+    user-select: none;
+    margin: -0.25em 0 -0.25em 0.5em;
+}
+
+.alectryon-inline .alectryon-mref-marker {
+    margin: -0.25em 0.15em -0.25em 0.625em; /* 625 = 0.5em / 80% */
+}
+
+.alectryon-mref {
+    color: inherit;
+    margin: -0.5em 0.25em;
+}
+
+.alectryon-goal:target .goal-separator .alectryon-mref-marker,
+:target > .alectryon-mref-marker {
+    animation: blink 0.2s step-start 0s 3 normal none;
+    background-color: #fcaf3e;
+    position: relative;
+}
+
+@keyframes blink {
+    50% {
+        box-shadow: 0 0 0 3pt #fcaf3e, 0 0 0 4pt black;
+        z-index: 10;
+    }
+}
+
+.alectryon-toggle,
+.alectryon-io .alectryon-extra-goal-toggle {
+    display: none;
+}
+
+.alectryon-bubble,
+.alectryon-io label,
+.alectryon-toggle-label {
+    cursor: pointer;
+}
+
+.alectryon-toggle-label {
+    display: block;
+    font-size: 0.8em;
+}
+
+.alectryon-io .alectryon-input {
+    padding: 0.1em 0; /* Enlarge the hitbox slightly to fill interline gaps */
+}
+
+.alectryon-io .alectryon-token {
+    white-space: pre-wrap;
+    display: inline;
+}
+
+.alectryon-io .alectryon-sentence.alectryon-target .alectryon-input {
+    /* FIXME if keywords were ‘bolder’ we wouldn't need !important */
+    font-weight: bold !important; /* Use !important to avoid a * selector */
+}
+
+.alectryon-bubble:before,
+.alectryon-toggle-label:before,
+.alectryon-io label.alectryon-input:after,
+.alectryon-io .alectryon-goal > label:before {
+    border: 1px solid #babdb6;
+    border-radius: 1em;
+    box-sizing: border-box;
+    content: '';
+    display: inline-block;
+    font-weight: bold;
+    height: 0.25em;
+    margin-bottom: 0.15em;
+    vertical-align: middle;
+    width: 0.75em;
+}
+
+.alectryon-toggle-label:before,
+.alectryon-io .alectryon-goal > label:before {
+    margin-right: 0.25em;
+}
+
+.alectryon-io .alectryon-goal > label:before {
+    margin-top: 0.125em;
+}
+
+.alectryon-io label.alectryon-input {
+    padding-right: 1em; /* Prevent line wraps before the checkbox bubble */
+}
+
+.alectryon-io label.alectryon-input:after {
+    margin-left: 0.25em;
+    margin-right: -1em; /* Compensate for the anti-wrapping space */
+}
+
+.alectryon-failed {
+    /* Underlines are broken in Chrome (they reset at each element boundary)… */
+    /* text-decoration: red wavy underline; */
+    /* … but it isn't too noticeable with dots */
+    text-decoration: red dotted underline;
+    text-decoration-skip-ink: none;
+    /* Chrome prints background images in low resolution, yielding a blurry underline */
+    /* background: bottom / 0.3em auto repeat-x url(data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHZpZXdCb3g9IjAgMCAyLjY0NiAxLjg1MiIgaGVpZ2h0PSI4IiB3aWR0aD0iMTAiPjxwYXRoIGQ9Ik0wIC4yNjVjLjc5NCAwIC41MyAxLjMyMiAxLjMyMyAxLjMyMi43OTQgMCAuNTMtMS4zMjIgMS4zMjMtMS4zMjIiIGZpbGw9Im5vbmUiIHN0cm9rZT0icmVkIiBzdHJva2Utd2lkdGg9Ii41MjkiLz48L3N2Zz4=); */
+}
+
+/* Wrapping :hover rules in a media query ensures that tapping a Coq sentence
+   doesn't trigger its :hover state (otherwise, on mobile, tapping a sentence to
+   hide its output causes it to remain visible (its :hover state gets triggered.
+   We only do it for the default style though, since other styles don't put the
+   output over the main text, so showing too much is not an issue. */
+@media (any-hover: hover) {
+    .alectryon-bubble:hover:before,
+    .alectryon-toggle-label:hover:before,
+    .alectryon-io label.alectryon-input:hover:after {
+        background: #eeeeec;
+    }
+
+    .alectryon-io label.alectryon-input:hover {
+        text-decoration: underline dotted #babdb6;
+	    text-shadow: 0 0 1px rgb(46, 52, 54, 0.3); /* #2e3436 + opacity */
+    }
+
+    .alectryon-io .alectryon-sentence:hover .alectryon-output,
+    .alectryon-io .alectryon-token:hover .alectryon-type-info-wrapper,
+    .alectryon-io .alectryon-token:hover .alectryon-type-info-wrapper {
+        z-index: 2; /* Place hovered goals above .alectryon-sentence.alectryon-target ones */
+    }
+}
+
+.alectryon-toggle:checked + .alectryon-toggle-label:before,
+.alectryon-io .alectryon-sentence > .alectryon-toggle:checked + label.alectryon-input:after,
+.alectryon-io .alectryon-extra-goal-toggle:checked + .alectryon-goal > label:before {
+    background-color: #babdb6;
+    border-color: #babdb6;
+}
+
+/* Disable clicks on sentences when the document-wide toggle is set. */
+.alectryon-toggle:checked + label + .alectryon-container label.alectryon-input {
+    cursor: unset;
+    pointer-events: none;
+}
+
+/* Hide individual checkboxes when the document-wide toggle is set. */
+.alectryon-toggle:checked + label + .alectryon-container label.alectryon-input:after {
+    display: none;
+}
+
+/* .alectryon-output is displayed by toggles, :hover, and .alectryon-target rules */
+.alectryon-io .alectryon-output {
+    box-sizing: border-box;
+    display: none;
+    left: 0;
+    right: 0;
+    position: absolute;
+    padding: 0.25em 0;
+    overflow: visible; /* Let box-shadows overflow */
+    z-index: 1; /* Default to an index lower than that used by :hover */
+}
+
+.alectryon-io .alectryon-type-info-wrapper {
+    position: absolute;
+    display: inline-block;
+    width: 100%;
+}
+
+.alectryon-io .alectryon-type-info-wrapper.full-width {
+    left: 0;
+    min-width: 100%;
+    max-width: 100%;
+}
+
+.alectryon-io .alectryon-type-info .goal-separator {
+    height: unset;
+    margin-top: 0em;
+}
+
+.alectryon-io .alectryon-type-info-wrapper .alectryon-type-info {
+    box-sizing: border-box;
+    bottom: 100%;
+    position: absolute;
+    /*padding: 0.25em 0;*/
+    visibility: hidden;
+    overflow: visible; /* Let box-shadows overflow */
+    z-index: 1; /* Default to an index lower than that used by :hover */
+    white-space: pre-wrap !important;
+}
+
+.alectryon-io .alectryon-type-info-wrapper .alectryon-type-info .alectryon-goal.alectryon-docstring {
+    white-space: pre-wrap !important;
+}
+
+@media (any-hover: hover) { /* See note above about this @media query */
+    .alectryon-io .alectryon-sentence:hover .alectryon-output:not(:hover) {
+        display: block;
+    }
+
+    .alectryon-io.output-hidden .alectryon-sentence:hover .alectryon-output:not(:hover) {
+        display: none !important;
+    }
+
+    .alectryon-io.type-info-hidden .alectryon-token:hover .alectryon-type-info-wrapper .alectryon-type-info,
+    .alectryon-io.type-info-hidden .alectryon-token:hover .alectryon-type-info-wrapper .alectryon-type-info {
+        /*visibility: hidden !important;*/
+    }
+
+    .alectryon-io .alectryon-token:hover .alectryon-type-info-wrapper .alectryon-type-info,
+    .alectryon-io .alectryon-token:hover .alectryon-type-info-wrapper .alectryon-type-info {
+        visibility: visible;
+        transition-delay: 0.5s;
+    }
+}
+
+.alectryon-io .alectryon-sentence.alectryon-target .alectryon-output {
+    display: block;
+}
+
+/* Indicate active (hovered or targeted) goals with a shadow. */
+.alectryon-io .alectryon-sentence:hover .alectryon-output:not(:hover) .alectryon-messages,
+.alectryon-io .alectryon-sentence.alectryon-target .alectryon-output  .alectryon-messages,
+.alectryon-io .alectryon-sentence:hover .alectryon-output:not(:hover) .alectryon-goals,
+.alectryon-io .alectryon-sentence.alectryon-target .alectryon-output  .alectryon-goals,
+.alectryon-io .alectryon-token:hover .alectryon-type-info-wrapper .alectryon-type-info {
+    box-shadow: 2px 2px 2px gray;
+}
+
+.alectryon-io .alectryon-extra-goals .alectryon-goal .goal-hyps {
+    display: none;
+}
+
+.alectryon-io .alectryon-extra-goals .alectryon-extra-goal-toggle:not(:checked) + .alectryon-goal label.goal-separator hr {
+    /* Dashes indicate that the hypotheses are hidden */
+    border-top-style: dashed;
+}
+
+
+/* Show just a small preview of the other goals; this is undone by the
+   "extra-goal" toggle and by :hover and .alectryon-target in windowed mode. */
+.alectryon-io .alectryon-extra-goals .alectryon-goal .goal-conclusion {
+    max-height: 5.2em;
+    overflow-y: auto;
+    /* Combining ‘overflow-y: auto’ with ‘display: inline-block’ causes extra space
+       to be added below the box. ‘vertical-align: middle’ gets rid of it. */
+    vertical-align: middle;
+}
+
+.alectryon-io .alectryon-goals,
+.alectryon-io .alectryon-messages {
+    background: #f6f7f6;
+	/*border: thin solid #d3d7cf; /* Convenient when pre's background is already #EEE */
+    display: block;
+    padding: 0.25em;
+}
+
+.alectryon-message::before {
+    content: '';
+    float: right;
+    /* etc/svg/square-bubble-xl.svg */
+    background: url("data:image/svg+xml,%3Csvg width='14' height='14' viewBox='0 0 3.704 3.704' xmlns='http://www.w3.org/2000/svg'%3E%3Cg fill-rule='evenodd' stroke='%23000' stroke-width='.264'%3E%3Cpath d='M.794.934h2.115M.794 1.463h1.455M.794 1.992h1.852'/%3E%3C/g%3E%3Cpath d='M.132.14v2.646h.794v.661l.926-.661h1.72V.14z' fill='none' stroke='%23000' stroke-width='.265'/%3E%3C/svg%3E") top right no-repeat;
+    height: 14px;
+    width: 14px;
+}
+
+.alectryon-toggle:checked + label + .alectryon-container {
+    width: unset;
+}
+
+/* Show goals when a toggle is set */
+.alectryon-toggle:checked + label + .alectryon-container label.alectryon-input + .alectryon-output,
+.alectryon-io .alectryon-sentence > .alectryon-toggle:checked ~ .alectryon-output {
+    display: block;
+    position: static;
+    width: unset;
+    background: unset; /* Override the backgrounds set in floating in windowed mode */
+    padding: 0.25em 0; /* Re-assert so that later :hover rules don't override this padding */
+}
+
+.alectryon-toggle:checked + label + .alectryon-container label.alectryon-input + .alectryon-output .goal-hyps,
+.alectryon-io .alectryon-sentence > .alectryon-toggle:checked ~ .alectryon-output .goal-hyps {
+    /* Overridden back in windowed style */
+    flex-flow: row wrap;
+    justify-content: flex-start;
+}
+
+.alectryon-toggle:checked + label + .alectryon-container .alectryon-sentence .alectryon-output > div,
+.alectryon-io .alectryon-sentence > .alectryon-toggle:checked ~ .alectryon-output > div {
+    display: block;
+}
+
+.alectryon-io .alectryon-extra-goal-toggle:checked + .alectryon-goal .goal-hyps {
+    display: flex;
+}
+
+.alectryon-io .alectryon-extra-goal-toggle:checked + .alectryon-goal .goal-conclusion {
+    max-height: unset;
+    overflow-y: unset;
+}
+
+.alectryon-toggle:checked + label + .alectryon-container .alectryon-sentence > .alectryon-toggle ~ .alectryon-wsp,
+.alectryon-io .alectryon-sentence > .alectryon-toggle:checked ~ .alectryon-wsp {
+    display: none;
+}
+
+.alectryon-io .alectryon-messages,
+.alectryon-io .alectryon-message,
+.alectryon-io .alectryon-goals,
+.alectryon-io .alectryon-goal,
+.alectryon-io .goal-hyps > span,
+.alectryon-io .goal-conclusion {
+    border-radius: 0.15em;
+}
+
+.alectryon-io .alectryon-goal,
+.alectryon-io .alectryon-message {
+    align-items: center;
+    background: #f6f7f6;
+    border: 0em;
+    display: block;
+    flex-direction: column;
+    margin: 0.25em;
+    padding: 0.5em;
+    position: relative;
+}
+
+.alectryon-io .goal-hyps {
+    align-content: space-around;
+    align-items: baseline;
+    display: flex;
+    flex-flow: column nowrap; /* re-stated in windowed mode */
+    justify-content: space-around;
+    /* LATER use a ‘gap’ property instead of margins once supported */
+    margin: -0.15em -0.25em; /* -0.15em to cancel the item spacing */
+    padding-bottom: 0.35em; /* 0.5em-0.15em to cancel the 0.5em of .goal-separator */
+}
+
+.alectryon-io .goal-hyps > br {
+    display: none; /* Only for RSS readers */
+}
+
+.alectryon-io .goal-hyps > span,
+.alectryon-io .goal-conclusion {
+    /*background: #eeeeec;*/
+    display: inline-block;
+    padding: 0.15em 0.35em;
+}
+
+.alectryon-io .goal-hyps > span {
+    align-items: baseline;
+    display: inline-flex;
+    margin: 0.15em 0.25em;
+}
+
+.alectryon-block var,
+.alectryon-inline var,
+.alectryon-io .goal-hyps > span > var {
+    font-weight: 600;
+    font-style: unset;
+}
+
+.alectryon-io .goal-hyps > span > var {
+    /* Shrink the list of names, but let it grow as long as space is available. */
+    flex-basis: min-content;
+    flex-grow: 1;
+}
+
+.alectryon-io .goal-hyps > span b {
+    font-weight: 600;
+    margin: 0 0 0 0.5em;
+    white-space: pre;
+}
+
+.alectryon-io .hyp-body,
+.alectryon-io .hyp-type {
+    display: flex;
+    align-items: baseline;
+}
+
+.alectryon-io .goal-separator {
+    align-items: center;
+    display: flex;
+    flex-direction: row;
+    height: 1em; /* Fixed height to ignore goal name and markers */
+    margin-top: -0.5em; /* Compensated in .goal-hyps when shown */
+}
+
+.alectryon-io .goal-separator hr {
+    border: none;
+    border-top: thin solid #555753;
+    display: block;
+    flex-grow: 1;
+    margin: 0;
+}
+
+.alectryon-io .goal-separator .goal-name {
+    font-size: 0.75em;
+    margin-left: 0.5em;
+}
+
+/**********/
+/* Banner */
+/**********/
+
+.alectryon-banner {
+    background: #eeeeec;
+    border: 1px solid #babcbd;
+    font-size: 0.75em;
+    padding: 0.25em;
+    text-align: center;
+    margin: 1em 0;
+}
+
+.alectryon-banner a {
+    cursor: pointer;
+    text-decoration: underline;
+}
+
+.alectryon-banner kbd {
+    background: #d3d7cf;
+    border-radius: 0.15em;
+    border: 1px solid #babdb6;
+    box-sizing: border-box;
+    display: inline-block;
+    font-family: inherit;
+    font-size: 0.9em;
+    height: 1.3em;
+    line-height: 1.2em;
+    margin: -0.25em 0;
+    padding: 0 0.25em;
+    vertical-align: middle;
+}
+
+/**********/
+/* Toggle */
+/**********/
+
+.alectryon-toggle-label {
+    margin: 1rem 0;
+}
+
+/******************/
+/* Floating style */
+/******************/
+
+/* If there's space, display goals to the right of the code, not below it. */
+@media (min-width: 80rem) {
+    /* Unlike the windowed case, we don't want to move output blocks to the side
+       when they are both :checked and -targeted, since it gets confusing as
+       things jump around; hence the commented-output part of the selector,
+       which would otherwise increase specificity */
+    .alectryon-floating .alectryon-sentence.alectryon-target /* > .alectryon-toggle ~ */ .alectryon-output,
+    .alectryon-floating .alectryon-sentence:hover .alectryon-output {
+        top: 0;
+        left: 100%;
+        right: -100%;
+        padding: 0 0.5em;
+        position:  absolute;
+    }
+
+    .alectryon-floating .alectryon-output {
+        min-height: 100%;
+    }
+
+    .alectryon-floating .alectryon-sentence:hover .alectryon-output {
+        background: white; /* Ensure that short goals hide long ones */
+    }
+
+    /* This odd margin-bottom property prevents the sticky div from bumping
+       against the bottom of its container (.alectryon-output).  The alternative
+       would be enlarging .alectryon-output, but that would cause overflows,
+       enlarging scrollbars and yielding scrolling towards the bottom of the
+       page.  Doing things this way instead makes it possible to restrict
+       .alectryon-output to a reasonable size (100%, through top = bottom = 0).
+       See also https://stackoverflow.com/questions/43909940/. */
+    /* See note on specificity above */
+    .alectryon-floating .alectryon-sentence.alectryon-target /* > .alectryon-toggle ~ */ .alectryon-output > div,
+    .alectryon-floating .alectryon-sentence:hover .alectryon-output > div {
+        margin-bottom: -200%;
+        position: sticky;
+        top: 0;
+    }
+
+    .alectryon-floating .alectryon-toggle:checked + label + .alectryon-container .alectryon-sentence .alectryon-output > div,
+    .alectryon-floating .alectryon-io .alectryon-sentence > .alectryon-toggle:checked ~ .alectryon-output > div {
+        margin-bottom: unset; /* Undo the margin */
+    }
+
+    /* Float underneath the current fragment
+    @media (max-width: 80rem) {
+        .alectryon-floating .alectryon-output {
+            top: 100%;
+        }
+    } */
+}
+
+/********************/
+/* Multi-pane style */
+/********************/
+
+.alectryon-windowed {
+    border: 0 solid #2e3436;
+    box-sizing: border-box;
+}
+
+.alectryon-windowed .alectryon-sentence:hover .alectryon-output {
+    background: white; /* Ensure that short goals hide long ones */
+}
+
+.alectryon-windowed .alectryon-output {
+    position: fixed; /* Overwritten by the ‘:checked’ rules */
+}
+
+/* See note about specificity below */
+.alectryon-windowed .alectryon-sentence:hover .alectryon-output,
+.alectryon-windowed .alectryon-sentence.alectryon-target > .alectryon-toggle ~ .alectryon-output {
+    padding: 0.5em;
+    overflow-y: auto; /* Windowed contents may need to scroll */
+}
+
+.alectryon-windowed .alectryon-io .alectryon-sentence:hover .alectryon-output:not(:hover) .alectryon-messages,
+.alectryon-windowed .alectryon-io .alectryon-sentence.alectryon-target .alectryon-output  .alectryon-messages,
+.alectryon-windowed .alectryon-io .alectryon-sentence:hover .alectryon-output:not(:hover) .alectryon-goals,
+.alectryon-windowed .alectryon-io .alectryon-sentence.alectryon-target .alectryon-output  .alectryon-goals {
+    box-shadow: none; /* A shadow is unnecessary here and incompatible with overflow-y set to auto */
+}
+
+.alectryon-windowed .alectryon-io .alectryon-sentence.alectryon-target .alectryon-output .goal-hyps {
+    /* Restated to override the :checked style */
+    flex-flow: column nowrap;
+    justify-content: space-around;
+}
+
+
+.alectryon-windowed .alectryon-sentence.alectryon-target .alectryon-extra-goals .alectryon-goal .goal-conclusion
+/* Like .alectryon-io .alectryon-extra-goal-toggle:checked + .alectryon-goal .goal-conclusion */ {
+    max-height: unset;
+    overflow-y: unset;
+}
+
+.alectryon-windowed .alectryon-output > div {
+    display: flex; /* Put messages after goals */
+    flex-direction: column-reverse;
+}
+
+/*********************/
+/* Standalone styles */
+/*********************/
+
+.alectryon-standalone {
+    font-family: 'IBM Plex Serif', 'PT Serif', 'Merriweather', 'DejaVu Serif', serif;
+    line-height: 1.5;
+}
+
+@media screen and (min-width: 50rem) {
+    html.alectryon-standalone {
+        /* Prevent flickering when hovering a block causes scrollbars to appear. */
+        margin-left: calc(100vw - 100%);
+        margin-right: 0;
+    }
+}
+
+/* Coqdoc */
+
+.alectryon-coqdoc .doc .code,
+.alectryon-coqdoc .doc .inlinecode,
+.alectryon-coqdoc .doc .comment {
+    display: inline;
+}
+
+.alectryon-coqdoc .doc .comment {
+    color: #eeeeec;
+}
+
+.alectryon-coqdoc .doc .paragraph {
+    height: 0.75em;
+}
+
+/* Centered, Floating */
+
+.alectryon-standalone .alectryon-centered,
+.alectryon-standalone .alectryon-floating {
+    max-width: 50rem;
+    margin: auto;
+}
+
+@media (min-width: 80rem) {
+    .alectryon-standalone .alectryon-floating {
+        max-width: 80rem;
+    }
+
+    .alectryon-standalone .alectryon-floating > * {
+        width: 50%;
+        margin-left: 0;
+    }
+}
+
+/* Windowed */
+
+.alectryon-standalone .alectryon-windowed {
+    display: block;
+    margin: 0;
+    overflow-y: auto;
+    position: absolute;
+    padding: 0 1em;
+}
+
+.alectryon-standalone .alectryon-windowed > * {
+    /* Override properties of docutils_basic.css */
+    margin-left: 0;
+    max-width: unset;
+}
+
+.alectryon-standalone .alectryon-windowed .alectryon-io {
+    box-sizing: border-box;
+    width: 100%;
+}
+
+/* No need to predicate the ‘:hover’ rules below on ‘:not(:checked)’, since ‘left’,
+   ‘right’, ‘top’, and ‘bottom’ will be inactived by the :checked rules setting
+   ‘position’ to ‘static’ */
+
+
+/* Specificity: We want the output to stay inline when hovered while unfolded
+   (:checked), but we want it to move when it's targeted (i.e. when the user
+   is browsing goals one by one using the keyboard, in which case we want to
+   goals to appear in consistent locations).  The selectors below ensure
+   that :hover < :checked < -targeted in terms of specificity. */
+/* LATER: Reimplement this stuff with CSS variables */
+.alectryon-windowed .alectryon-sentence.alectryon-target > .alectryon-toggle ~ .alectryon-output {
+    position: fixed;
+}
+
+@media screen and (min-width: 60rem) {
+    .alectryon-standalone .alectryon-windowed {
+        border-right-width: thin;
+        bottom: 0;
+        left: 0;
+        right: 50%;
+        top: 0;
+    }
+
+    .alectryon-standalone .alectryon-windowed .alectryon-sentence:hover .alectryon-output,
+    .alectryon-standalone .alectryon-windowed .alectryon-sentence.alectryon-target .alectryon-output {
+        bottom: 0;
+        left: 50%;
+        right: 0;
+        top: 0;
+    }
+}
+
+@media screen and (max-width: 60rem) {
+    .alectryon-standalone .alectryon-windowed {
+        border-bottom-width: 1px;
+        bottom: 40%;
+        left: 0;
+        right: 0;
+        top: 0;
+    }
+
+    .alectryon-standalone .alectryon-windowed .alectryon-sentence:hover .alectryon-output,
+    .alectryon-standalone .alectryon-windowed .alectryon-sentence.alectryon-target .alectryon-output {
+        bottom: 0;
+        left: 0;
+        right: 0;
+        top: 60%;
+    }
+}

doc/alectryon.js

@@ -0,0 +1,190 @@
+var Alectryon;
+(function(Alectryon) {
+    (function (slideshow) {
+        function anchor(sentence) { return "#" + sentence.id; }
+
+        function current_sentence() { return slideshow.sentences[slideshow.pos]; }
+
+        function unhighlight() {
+            var sentence = current_sentence();
+            if (sentence) sentence.classList.remove("alectryon-target");
+            slideshow.pos = -1;
+        }
+
+        function highlight(sentence) {
+            sentence.classList.add("alectryon-target");
+        }
+
+        function scroll(sentence) {
+            // Put the top of the current fragment close to the top of the
+            // screen, but scroll it out of view if showing it requires pushing
+            // the sentence past half of the screen.  If sentence is already in
+            // a reasonable position, don't move.
+            var parent = sentence.parentElement;
+            /* We want to scroll the whole document, so start at root… */
+            while (parent && !parent.classList.contains("alectryon-root"))
+                parent = parent.parentElement;
+            /* … and work up from there to find a scrollable element.
+               parent.scrollHeight can be greater than parent.clientHeight
+               without showing scrollbars, so we add a 10px buffer. */
+            while (parent && parent.scrollHeight <= parent.clientHeight + 10)
+                parent = parent.parentElement;
+            /* <body> and <html> elements can have their client rect overflow
+             * the window if their height is unset, so scroll the window
+             * instead */
+            if (parent && (parent.nodeName == "BODY" || parent.nodeName == "HTML"))
+                parent = null;
+
+            var rect = function(e) { return e.getBoundingClientRect(); };
+            var parent_box = parent ? rect(parent) : { y: 0, height: window.innerHeight },
+                sentence_y = rect(sentence).y - parent_box.y,
+                fragment_y = rect(sentence.parentElement).y - parent_box.y;
+
+            // The assertion below sometimes fails for the first element in a block.
+            // console.assert(sentence_y >= fragment_y);
+
+            if (sentence_y < 0.1 * parent_box.height ||
+                sentence_y > 0.7 * parent_box.height) {
+                (parent || window).scrollBy(
+                    0, Math.max(sentence_y - 0.5 * parent_box.height,
+                                fragment_y - 0.1 * parent_box.height));
+            }
+        }
+
+        function highlighted(pos) {
+            return slideshow.pos == pos;
+        }
+
+        function navigate(pos, inhibitScroll) {
+            unhighlight();
+            slideshow.pos = Math.min(Math.max(pos, 0), slideshow.sentences.length - 1);
+            var sentence = current_sentence();
+            highlight(sentence);
+            if (!inhibitScroll)
+                scroll(sentence);
+        }
+
+        var keys = {
+            PAGE_UP: 33,
+            PAGE_DOWN: 34,
+            ARROW_UP: 38,
+            ARROW_DOWN: 40,
+            h: 72, l: 76, p: 80, n: 78
+        };
+
+        function onkeydown(e) {
+            e = e || window.event;
+            if (e.ctrlKey || e.metaKey) {
+                if (e.keyCode == keys.ARROW_UP)
+                    slideshow.previous();
+                else if (e.keyCode == keys.ARROW_DOWN)
+                    slideshow.next();
+                else
+                    return;
+            } else {
+                // if (e.keyCode == keys.PAGE_UP || e.keyCode == keys.p || e.keyCode == keys.h)
+                //     slideshow.previous();
+                // else if (e.keyCode == keys.PAGE_DOWN || e.keyCode == keys.n || e.keyCode == keys.l)
+                //     slideshow.next();
+                // else
+                return;
+            }
+            e.preventDefault();
+        }
+
+        function start() {
+            slideshow.navigate(0);
+        }
+
+        function toggleHighlight(idx) {
+            if (highlighted(idx))
+                unhighlight();
+            else
+                navigate(idx, true);
+        }
+
+        function handleClick(evt) {
+            if (evt.ctrlKey || evt.metaKey) {
+                var sentence = evt.currentTarget;
+
+                // Ensure that the goal is shown on the side, not inline
+                var checkbox = sentence.getElementsByClassName("alectryon-toggle")[0];
+                if (checkbox)
+                    checkbox.checked = false;
+
+                toggleHighlight(sentence.alectryon_index);
+                evt.preventDefault();
+            }
+        }
+
+        function init() {
+            document.onkeydown = onkeydown;
+            slideshow.pos = -1;
+            slideshow.sentences = Array.from(document.getElementsByClassName("alectryon-sentence"));
+            slideshow.sentences.forEach(function (s, idx) {
+                s.addEventListener('click', handleClick, false);
+                s.alectryon_index = idx;
+            });
+        }
+
+        slideshow.start = start;
+        slideshow.end = unhighlight;
+        slideshow.navigate = navigate;
+        slideshow.next = function() { navigate(slideshow.pos + 1); };
+        slideshow.previous = function() { navigate(slideshow.pos + -1); };
+        window.addEventListener('DOMContentLoaded', init);
+    })(Alectryon.slideshow || (Alectryon.slideshow = {}));
+
+    (function (styles) {
+        var styleNames = ["centered", "floating", "windowed"];
+
+        function className(style) {
+            return "alectryon-" + style;
+        }
+
+        function setStyle(style) {
+            var root = document.getElementsByClassName("alectryon-root")[0];
+            styleNames.forEach(function (s) {
+                root.classList.remove(className(s)); });
+            root.classList.add(className(style));
+        }
+
+        function init() {
+            var banner = document.getElementsByClassName("alectryon-banner")[0];
+            if (banner) {
+                banner.append(" Style: ");
+                styleNames.forEach(function (styleName, idx) {
+                    var s = styleName;
+                    var a = document.createElement("a");
+                    a.onclick = function() { setStyle(s); };
+                    a.append(styleName);
+                    if (idx > 0) banner.append("; ");
+                    banner.appendChild(a);
+                });
+                banner.append(".");
+            }
+        }
+
+        window.addEventListener('DOMContentLoaded', init);
+
+        styles.setStyle = setStyle;
+    })(Alectryon.styles || (Alectryon.styles = {}));
+})(Alectryon || (Alectryon = {}));
+
+function setHidden(elements, isVisible, token) {
+    for (let i = 0; i < elements.length; i++) {
+        if (isVisible) {
+            elements[i].classList.remove(token)
+        } else {
+            elements[i].classList.add(token)
+        }
+    }
+}
+
+function toggleShowTypes(checkbox) {
+    setHidden(document.getElementsByClassName("alectryon-io"), checkbox.checked, "type-info-hidden")
+}
+
+function toggleShowGoals(checkbox) {
+    setHidden(document.getElementsByClassName("alectryon-io"), checkbox.checked, "output-hidden")
+}

doc/autobound.md

@@ -36,9 +36,9 @@ Note that, Lean inferred a more general type using `Sort` instead of `Type`.
 
 Although we love this feature and use it extensively when implementing Lean,
 we realize some users may feel uncomfortable with it. Thus, you can disable it using
-the command `set_option autoBoundImplicitLocal false`.
+the command `set_option autoImplicit false`.
 ```lean
-set_option autoBoundImplicitLocal false
+set_option autoImplicit false
 /- The following definition produces `unknown identifier` errors -/
 -- def compose (g : β → γ) (f : α → β) (x : α) : γ :=
 --   g (f x)

doc/book.toml

@@ -10,6 +10,12 @@ build-dir = "out"
 
 [output.html]
 git-repository-url = "https://github.com/leanprover/lean4"
+additional-css = ["alectryon.css", "pygments.css"]
+additional-js = ["alectryon.js"]
+
+[output.html.fold]
+enable = true
+level = 0
 
 [output.html.playground.boring-prefixes]
 lean = "# "

doc/declarations.md

@@ -675,6 +675,20 @@ When a ``match`` has only one line, the vertical bar may be left out. In that ca
     def bar₄ (p : Nat × Nat) : Nat :=
     let ⟨m, n⟩ := p in m + n
 
+Information about the term being matched can be preserved in each branch using the syntax `match h : t with`. For example, a user may want to match a term `ns ++ ms : List Nat`, while tracking the hypothesis `ns ++ ms = []` or `ns ++ ms= h :: t` in the respective match arm:
+
+```lean
+def foo (ns ms : List Nat) (h1 : ns ++ ms ≠ []) (k : Nat -> Char) : Char :=
+  match h2 : ns ++ ms with
+  -- in this arm, we have the hypothesis `h2 : ns ++ ms = []`
+  | [] => absurd h2 h1
+  -- in this arm, we have the hypothesis `h2 : ns ++ ms = h :: t`
+  | h :: t => k h
+
+-- '7'
+#eval foo [7, 8, 9] [] (by decide) Nat.digitChar
+```
+
 .. _structures_and_records:
 
 Structures and Records

doc/dev/bootstrap.md

@@ -1,4 +1,3 @@
-
 # Lean Build Bootstrapping
 
 Since version 4, Lean is a partially bootstrapped program: most parts of the
@@ -16,17 +15,18 @@ stage0/
   bin/lean
 stage1/
   include/
-    config.h  # config variables used to build `lean` such as use allocator
-    runtime/lean.h  # runtime headers, used by extracted C code, uses `config.h`
+    config.h  # config variables used to build `lean` such as used allocator
+    runtime/lean.h  # runtime header, used by extracted C code, uses `config.h`
   share/lean/
-    Makefile  # used by `leanmake`
+    lean.mk  # used by `leanmake`
   lib/
     lean/**/*.olean  # the Lean library (incl. the compiler) compiled by the previous stage's `lean`
     temp/**/*.{c,o}  # the library extracted to C and compiled by `leanc`
     libInit.a libStd.a libLean.a  # static libraries of the Lean library
     libleancpp.a  # a static library of the C++ sources of Lean
+    libleanshared.so  # a dynamic library including the static libraries above
   bin/
-    lean  # the Lean compiler & server linked together from the above libraries
+    lean  # the Lean compiler & server, a small executable that calls directly into libleanshared.so
     leanc  # a wrapper around a C compiler supplying search paths etc
     leanmake  # a wrapper around `make` supplying the Makefile above
 stage2/...
@@ -55,7 +55,7 @@ We are not aware of any "meta-meta" parts that influence more than two stages of
 compilation, so stage 3 should always be identical to stage 2 and only exists as
 a sanity check.
 
-In summary, doing a standard build via `make` involves these steps:
+In summary, doing a standard build via `make` internally involves these steps:
 
 1. compile the `stage0/src` archived sources into `stage0/bin/lean`
 1. use it to compile the current library (*including* your changes) into `stage1/lib`
@@ -119,4 +119,4 @@ affect later stages. This is an issue in two specific cases.
 To modify either of these flags both for building and editing the stdlib, adjust
 the code in `stage0/src/stdlib_flags.h`. The flags will automatically be reset
 on the next `update-stage0` when the file is overwritten with the original
-version in `src/`.
+version in `src/`.

doc/dev/cpp_coding_style.md

@@ -1,155 +0,0 @@
-[google-style]: https://google.github.io/styleguide/cppguide.html
-[cpplint]: /src/cmake/Modules/cpplint.py
-
-# Coding Style
-
-The Lean project is moving away from using any C++ as more and more of
-the compiler is being bootstrapped in Lean itself. But the remaining
-C++ codebase is using modified version of [Google's C++ Style
-Guide][google-style].
-
-## [C++11](http://en.wikipedia.org/wiki/C%2B%2B11) features
-
-Lean makes extensive use of new features in the C++ 11 standard.
-Developers must be familiar with the standard to be able to understand
-the code. Here are some of the features that are extensively used.
-
-- Type inference (aka `auto` keyword).
-- Initializer lists.
-- Lambda functions and expressions.
-- `nullptr` constant.
-- Strongly typed enumerations.
-- Right angle brackets with no space is now allowed in C++ 11.
-- Thread local storage.
-- Threading facilities.
-- Tuple types.
-- Smart pointers.
-- When using ``std::list`` make sure to include the `std::`
-  qualifier so you do not accidentally use the ``lean::list`` type.
-- When using ``std::copy`` make sure to include the `std::`
-  qualifier so you do not accidentally use the ``lean::copy`` type.
-- Small and focused functions are preferred: foo().  Try not to
-  exceed 500 lines in a function, except in tests.
-- Do **not** use the `#ifndef-#define-#endif` idiom for header files.
-  Instead use `#pragma once`.
-- Write `type const & v` instead of `const type & v`.
-- Use `const` extensively.
-- Use the macro `lean_assert` for assertions. The macro `lean_assert`
-  is extensively used when writing unit tests.
-
-## Naming
-
-- Class, method, and function names are lower case
-Use `_` for composite names. Example: `type_checker`.
-- Class/struct fields should start with the prefix `m_`.
-
-  Example:
-  ```c++
-  class point {
-      int m_x;
-      int m_y;
-  public:
-      ...
-  };
-  ```
-
-## Namespaces
-
-All code is in the `lean` namespace. Each frontend is stored in a
-separate nested namespace. For example, the SMT 2.0 frontend is stored
-in the `lean::smt` namespace.
-
-Exception: some debugging functions are stored outside of the `lean`
-namespace. These functions are called `print` and are meant to be used
-when debugging Lean using `gdb`.
-
-Do not use `using namespace` in a header file.
-
-## Templates
-
-Organize template source code using the approach described at http://www.codeproject.com/Articles/3515/How-To-Organize-Template-Source-Code
-
-## Idioms
-
-Use some popular C++ idioms:
-
-- [Pimpl](http://c2.com/cgi/wiki?PimplIdiom)
-- [RAII](http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization) Resource Acquisition Is Initialization
-
-## Formatting
-
-* Use 4 spaces for indentation.
-
-* `if-then-else` curly brackets not always required.  The following
-  forms are acceptable:
-
-  ```c++
-  if (cond) {
-      ...
-  } else {
-      ...
-  }
-  ```
-  and
-
-  ```c++
-  if (cond)
-    statement1;
-  else
-    statement2;
-  ```
-
-  In *exceptional cases*, we also use
-
-  ```c++
-  if (cond) statement;
-  ```
-
-  and
-
-  ```c++
-  if (cond) statement1; else stament2;
-  ```
-  * `if-then-else-if-else`
-
-  The following forms are acceptable:
-
-  ```c++
-  if (cond) {
-      ...
-  } else if (cond) {
-      ...
-  } else {
-      ...
-  }
-  ```c++
-  and
-
-  ```c++
-  if (cond)
-      statement1;
-  else if (cond)
-      statement2;
-  else
-      statement3;
-  ```
-
-* Format code using extra spaces to make code more readable.  For example:
-
-  ```c++
-  environment const & m_env;
-  cache               m_cache;
-  normalizer          m_normalizer;
-  volatile bool       m_interrupted;
-  ```
-  instead of:
-
-  ```c++
-  environment const & m_env;
-  cache m_cache;
-  normalizer m_normalizer;
-  volatile bool m_interrupted;
-  ```
-
-* Spaces in expressions.  Write `a == b` instead of `a==b`. Similarly,
-  we write `x < y + 1` instead of `x<y+1`.

doc/dev/debugging.md

@@ -20,8 +20,9 @@ Notable trace classes:
 * `Meta.isDefEq`: unification
 * `interpreter`: full execution trace of the interpreter. Only available in debug builds.
 
-In pure contexts or when execution is aborted before the messages are finally printed, one can instead use the term `dbg_trace "msg with {interpolations}"; val` (`;` can also be replaced by a newline), which will print the message directly to stderr before evaluating `val`. `dbgTraceVal val` can be used as a shorthand for `dbg_trace "{val}"; val`.
+In pure contexts or when execution is aborted before the messages are finally printed, one can instead use the term `dbg_trace "msg with {interpolations}"; val` (`;` can also be replaced by a newline), which will print the message to stderr before evaluating `val`. `dbgTraceVal val` can be used as a shorthand for `dbg_trace "{val}"; val`.
 Note that if the return value is not actually used, the trace code is silently dropped as well.
+In the language server, stderr output is buffered and shown as messages after a command has been elaborated, unless the option `server.stderrAsMessages` is deactivated.
 
 ## Debuggers
 

doc/dev/ffi.md

@@ -66,33 +66,45 @@ Return values and `@[export]` parameters are always owned at the moment.
 ## Initialization
 
 When including Lean code as part of a larger program, modules must be *initialized* before accessing any of their declarations.
+Module initialization entails
+* initialization of all "constants" (nullary functions), including closed terms lifted out of other functions
+* execution of all `[init]` functions
+* execution of all `[builtinInit]` functions, if the `builtin` parameter of the module initializer has been set
+
+The module initializer is automatically run with the `builtin` flag for executables compiled from Lean code and for "plugins" loaded with `lean --plugin`.
+For all other modules imported by `lean`, the initializer is run without `builtin`.
+Thus `[init]` functions are run iff their module is imported, regardless of whether they have native code available or not, while `[builtinInit]` functions are only run for native executable or plugins, regardless of whether their module is imported or not.
+`lean` uses built-in initializers for e.g. registering basic parsers that should be available even without importing their module (which is necessary for bootstrapping).
+  
 The initializer for module `A.B` is called `initialize_A_B` and will automatically initialize any imported modules.
-Module initializers are idempotent, but not thread-safe.
+Module initializers are idempotent (when run with the same `builtin` flag), but not thread-safe.
 Together with initialization of the Lean runtime, you should execute code like the following exactly once before accessing any Lean declarations:
 ```c
 void lean_initialize_runtime_module();
 void lean_initialize();
-lean_object * initialize_A_B(lean_object *);
-lean_object * initialize_C(lean_object *);
+lean_object * initialize_A_B(uint8_t builtin, lean_object *);
+lean_object * initialize_C(uint8_t builtin, lean_object *);
 ...
 
 lean_initialize_runtime_module();
 //lean_initialize();  // necessary if you (indirectly) access the `Lean` package
 
 lean_object * res;
-res = initialize_A_B(lean_io_mk_world());
+// use same default as for Lean executables
+uint8_t builtin = 1;
+res = initialize_A_B(builtin, lean_io_mk_world());
 if (lean_io_result_is_ok(res)) {
     lean_dec_ref(res);
 } else {
     lean_io_result_show_error(res);
     lean_dec(res);
-    return ...; // do not access Lean declarations if initialization failed
+    return ...;  // do not access Lean declarations if initialization failed
 }
-res = initialize_C(lean_io_mk_world());
+res = initialize_C(builtin, lean_io_mk_world());
 if (lean_io_result_is_ok(res)) {
 ...
 
-//lean_init_task_manager(); // necessary if you (indirectly) use `Task`
+//lean_init_task_manager();  // necessary if you (indirectly) use `Task`
 lean_io_mark_end_initialization();
 ```
 

doc/dev/fixing_tests.md

@@ -1,39 +0,0 @@
-Fixing Tests
-============
-
-The test suite contains some tests that compare the produced output
-with the expected output. For example, the directory `tests/lean`
-contains files such as [`bad_class.lean`](../tests/lean/bad_class.lean) and
-[`bad_class.lean.expected.out`](../tests/lean/bad_class.lean.expected.out).
-The later contains the expected output for the test file `bad_class.lean`.
-
-When the Lean source code or the standard library are modified, some of these
-tests break because the produced output is slightly different, and we have
-to reflect the changes in the `.lean.expected.out` files.
-We should not blindly copy the new produced output since we may accidentally
-miss a bug introduced by recent changes.
-The test suite contains commands that allow us to see what changed in a convenient way.
-First, we must install [meld](http://meldmerge.org/). On Ubuntu, we can do it by simply executing
-
-```
-sudo apt-get install meld
-```
-
-Now, suppose `bad_class.lean` test is broken. We can see the problem by going to `test/lean` directory and
-executing
-
-```
-./test_single.sh -i bad_class.lean
-```
-
-When the `-i` option is provided, `meld` is automatically invoked
-whenever there is discrepancy between the produced and expected
-outputs. `meld` can also be used to repair the problems.
-
-In Emacs, we can also execute `M-x lean4-diff-test-file` to check/diff the file of the current buffer.
-To mass-copy all `.produced.out` files to the respective `.expected.out` file, use `tests/lean/copy-produced`.
-When using the Nix setup, add `--keep-failed` to the `nix build` call and then call
-```sh
-tests/lean/copy-produced <build-dir>/source/tests/lean
-```
-instead where `<build-dir>` is the path printed out by `nix build`.

doc/dev/index.md

@@ -1,48 +1,30 @@
 # Development Workflow
-- [Commit Convention](./commit_convention.md)
-- [Building Lean](../make/index.md)
-  - [Ubuntu Setup](../make/ubuntu.md)
-  - [macOS Setup](../make/osx-10.9.md)
-  - [Windows MSYS2 Setup](../make/msys2.md)
-  - [Windows with WSL](../make/wsl.md)
-  - [Nix Setup (*Experimental*)](../make/nix.md)
-- [Unit Testing](./testing.md)
-- [Building This Manual](./mdbook.md)
-- [Fixing Tests](./fixing_tests.md)
-- [Debugging](./debugging.md)
-- [C++ Coding Style](./dev/cpp_coding_style.md)
 
-You will notice there is a `stage0` folder. This is for bootstrapping
-the compiler development.  Generally you do not change any code in
-`stage0` manually.  It is important that you read [bootstrapping
-pipeline](bootstrap.md) so you understand how this works.
+If you want to make changes to Lean itself, start by [building Lean](../make/index.html) from a clean checkout to make sure that everything is set up correctly.
+After that, read on below to find out how to set up your editor for changing the Lean source code, followed by further sections of the development manual where applicable such as on the [test suite](testing.md) and [commit convention](commit_convention.md).
 
-The dev team uses `elan` to manage which `lean` toolchain to use
-locally and `elan` can be used to setup the version of Lean you are
-manually building.  This means you generally do not use `make
-install`. You use `elan` instead.
+If you are planning to make any changes that may affect the compilation of Lean itself, e.g. changes to the parser, elaborator, or compiler, you should first read about the [bootstrapping pipeline](bootstrap.md).
+You should not edit the `stage0` directory except using the commands described in that section when necessary.
 
 ## Development Setup
 
-You can use any of the [supported editors](../setup.md) for editing
-the Lean source code. If you set up `elan` as below, opening `src/` as
-a *workspace folder* should ensure that stage 0 will be used for file
-in that directory.
+You can use any of the [supported editors](../setup.md) for editing the Lean source code.
+If you set up `elan` as below, opening `src/` as a *workspace folder* should ensure that stage 0 (i.e. the stage that first compiles `src/`) will be used for files in that directory.
 
-## Dev setup using elan
+### Dev setup using elan
 
 You can use [`elan`](https://github.com/leanprover/elan) to easily
 switch between stages and build configurations based on the current
 directory, both for the `lean`, `leanc`, and `leanmake` binaries in your shell's
 PATH and inside your editor.
 
-To install elan, you can do so, without installing a default version of Lean, using
+To install elan, you can do so, without installing a default version of Lean, using (Unix)
 
 ```bash
-[Unix]
 curl https://raw.githubusercontent.com/leanprover/elan/master/elan-init.sh -sSf | sh -s -- --default-toolchain none
-
-[Windows]
+```
+or (Windows)
+```
 curl -O --location https://raw.githubusercontent.com/leanprover/elan/master/elan-init.ps1
 powershell -f elan-init.ps1 --default-toolchain none
 del elan-init.ps1
@@ -63,6 +45,7 @@ cd src
 # make `lean` etc. point to stage0 anywhere inside `src`
 elan override set lean4-stage0
 ```
+
 You can also use the `+toolchain` shorthand (e.g. `lean +lean4-debug`) to switch
 toolchains on the spot. `lean4-mode` will automatically use the `lean` executable
 associated with the directory of the current file as long as `lean4-rootdir` is

doc/dev/testing.md

@@ -1,8 +1,6 @@
-# Unit Testing
+# Test Suite
 
-You can run the unit tests after completing a build using the following:
-
-After [building lean](../make/index.md) you can run all the tests using
+After [building Lean](../make/index.md) you can run all the tests using
 ```
 cd build/release
 make test ARGS=-j4
@@ -29,10 +27,11 @@ ctest -j 4 --output-on-failure --timeout 300
 
 To get verbose output from ctest pass the `--verbose` command line
 option. Test output is normally suppressed and only summary
-information is displayed. This option will show all test output
+information is displayed. This option will show all test output.
 
-Here is the summary of the test source code organization.
-All these tests are included by [/src/shell/CMakeLists.txt](https://github.com/leanprover/lean4/blob/master/src/shell/CMakeLists.txt):
+## Test Suite Organization
+
+All these tests are included by [src/shell/CMakeLists.txt](https://github.com/leanprover/lean4/blob/master/src/shell/CMakeLists.txt):
 
 - `tests/lean`: contains tests that come equipped with a
   .lean.expected.out file. The driver script `test_single.sh` runs
@@ -88,11 +87,35 @@ All these tests are included by [/src/shell/CMakeLists.txt](https://github.com/l
 - `tests/plugin`: tests that compiled Lean code can be loaded into
   `lean` via the `--plugin` command line option.
 
-- `tests/leanpkg`: tests the `leanpkg` program, where each sub-folder
-  is a complete "lean package", including:
-    - `cyclic`
-    - `user_ext`
-    - `user_attr`
-    - `user_opt`
-    - `prv`
-    - `user_attr_app`
+## Fixing Tests
+
+When the Lean source code or the standard library are modified, some of the
+tests break because the produced output is slightly different, and we have
+to reflect the changes in the `.lean.expected.out` files.
+We should not blindly copy the new produced output since we may accidentally
+miss a bug introduced by recent changes.
+The test suite contains commands that allow us to see what changed in a convenient way.
+First, we must install [meld](http://meldmerge.org/). On Ubuntu, we can do it by simply executing
+
+```
+sudo apt-get install meld
+```
+
+Now, suppose `bad_class.lean` test is broken. We can see the problem by going to `test/lean` directory and
+executing
+
+```
+./test_single.sh -i bad_class.lean
+```
+
+When the `-i` option is provided, `meld` is automatically invoked
+whenever there is discrepancy between the produced and expected
+outputs. `meld` can also be used to repair the problems.
+
+In Emacs, we can also execute `M-x lean4-diff-test-file` to check/diff the file of the current buffer.
+To mass-copy all `.produced.out` files to the respective `.expected.out` file, use `tests/lean/copy-produced`.
+When using the Nix setup, add `--keep-failed` to the `nix build` call and then call
+```sh
+tests/lean/copy-produced <build-dir>/source/tests/lean
+```
+instead where `<build-dir>` is the path printed out by `nix build`.

doc/do.md

@@ -276,8 +276,8 @@ def sum (xs : Array Nat) : IO Nat := do
 -- x: 3
 -- 6
 
--- We can write pure code using the `do` DSL too.
-def sum' (xs : Array Nat) : Nat := do
+-- We can write pure code using the `Id.run <| do` DSL too.
+def sum' (xs : Array Nat) : Nat := Id.run <| do
   let mut s := 0
   for x in xs do
     s := s + x
@@ -348,6 +348,46 @@ TODO: describe `forIn`
 
 TODO
 
+## Returning early from a failed match
+
+Inside a `do` block, the pattern `let _ ← <success> | <fail>` will continue with the rest of the block if the match on the left hand side succeeds, but will execute the right hand side and exit the block on failure:
+
+```lean
+def showUserInfo (getUsername getFavoriteColor : IO (Option String)) : IO Unit := do
+  let some n ← getUsername | IO.println "no username!"
+  IO.println s!"username: {n}"
+  let some c ← getFavoriteColor | IO.println "user didn't provide a favorite color!"
+  IO.println s!"favorite color: {c}"
+
+-- username: JohnDoe
+-- favorite color: red
+#eval showUserInfo (pure <| some "JohnDoe") (pure <| some "red")
+
+-- no username
+#eval showUserInfo (pure none) (pure <| some "purple")
+
+-- username: JaneDoe
+-- user didn't provide a favorite color
+#eval showUserInfo (pure <| some "JaneDoe") (pure none)
+```
+
+## If-let
+
+Inside a `do` block, users can employ the `if let` pattern to destructure actions:
+
+```lean
+def tryIncrement (getInput : IO (Option Nat)) : IO (Except String Nat) := do
+  if let some n ← getInput
+  then return Except.ok n.succ
+  else return Except.error "argument was `none`"
+
+-- Except.ok 2
+#eval tryIncrement (pure <| some 1)
+
+-- Except.error "argument was `none`"
+#eval tryIncrement (pure <| none)
+```
+
 ## Pattern matching
 
 TODO

doc/elaborators.md

@@ -0,0 +1,8 @@
+## Elaborators
+
+TODO. See [Lean Together 2021: Metaprogramming in Lean
+4](https://youtu.be/hxQ1vvhYN_U) for an overview as well [the
+continuation](https://youtu.be/vy4JWIiiXSY) about tactic programming.
+For more information on antiquotations, see also §4.1 of [Beyond
+Notations: Hygienic Macro Expansion for Theorem Proving
+Languages](https://arxiv.org/pdf/2001.10490.pdf#page=11).

doc/examples.md

@@ -0,0 +1,9 @@
+Examples
+========
+
+- [Palindromes](examples/palindromes.lean.md)
+- [Binary Search Trees](examples/bintree.lean.md)
+- [A Certified Type Checker](examples/tc.lean.md)
+- [The Well-Typed Interpreter](examples/interp.lean.md)
+- [Dependent de Bruijn Indices](examples/deBruijn.lean.md)
+- [Parametric Higher-Order Abstract Syntax](examples/phoas.lean.md)

doc/examples/NFM2022/nfm1.lean

@@ -0,0 +1,22 @@
+/- "Hello world" -/
+
+#eval "hello" ++ " " ++ "world"
+-- "hello world"
+
+#check true
+-- Bool
+
+def x := 10
+
+#eval x + 2
+-- 12
+
+def double (x : Int) := 2*x
+
+#eval double 3
+-- 6
+#check double
+-- Int → Int
+example : double 4 = 8 := rfl
+
+

doc/examples/NFM2022/nfm10.lean

@@ -0,0 +1,19 @@
+/- Dependent pattern matching -/
+
+inductive Vector (α : Type u) : Nat → Type u
+  | nil : Vector α 0
+  | cons : α → Vector α n → Vector α (n+1)
+
+infix:67 "::" => Vector.cons
+
+def Vector.zip : Vector α n → Vector β n → Vector (α × β) n
+  | nil, nil => nil
+  | a::as, b::bs => (a, b) :: zip as bs
+
+#print Vector.zip
+/-
+def Vector.zip.{u_1, u_2} : {α : Type u_1} → {n : Nat} → {β : Type u_2} → Vector α n → Vector β n → Vector (α × β) n :=
+fun {α} {n} {β} x x_1 =>
+  Vector.brecOn (motive := fun {n} x => {β : Type u_2} → Vector β n → Vector (α × β) n) x
+    ...
+-/

doc/examples/NFM2022/nfm11.lean

@@ -0,0 +1,22 @@
+/- Structures -/
+
+structure Point where
+  x : Int := 0
+  y : Int := 0
+  deriving Repr
+
+#eval Point.x (Point.mk 10 20)
+-- 10
+
+#eval { x := 10, y := 20 : Point }
+
+def p : Point := { y := 20 }
+
+#eval p.x
+#eval p.y
+#eval { p with x := 5 }
+-- { x := 5, y := 20 }
+
+structure Point3D extends Point where
+  z : Int
+

doc/examples/NFM2022/nfm12.lean

@@ -0,0 +1,28 @@
+/- Type classes -/
+namespace Example
+
+class ToString (α : Type u) where
+  toString : α → String
+
+#check @ToString.toString
+-- {α : Type u_1} → [self : ToString α] → α → String
+
+instance : ToString String where
+  toString s := s
+
+instance : ToString Bool where
+  toString b := if b then "true" else "false"
+
+#eval ToString.toString "hello"
+export ToString (toString)
+#eval toString true
+-- "true"
+-- #eval toString (true, "hello") -- Error
+
+instance [ToString α] [ToString β] : ToString (α × β) where
+  toString p := "(" ++ toString p.1 ++ ", " ++ toString p.2 ++ ")"
+
+#eval toString (true, "hello")
+-- "(true, hello)"
+
+end Example

doc/examples/NFM2022/nfm13.lean

@@ -0,0 +1,44 @@
+/- Type classes are heavily used in Lean -/
+namespace Example
+
+class Mul (α : Type u) where
+  mul : α → α → α
+
+infixl:70 " * " => Mul.mul
+
+def double [Mul α] (a : α) := a * a
+
+class Semigroup (α : Type u) extends Mul α where
+  mul_assoc : ∀ a b c : α, (a * b) * c = a * (b * c)
+
+instance : Semigroup Nat where
+  mul := Nat.mul
+  mul_assoc := Nat.mul_assoc
+
+#eval double 5
+
+class Functor (f : Type u → Type v) : Type (max (u+1) v) where
+  map : (α → β) → f α → f β
+
+infixr:100 " <$> " => Functor.map
+
+class LawfulFunctor (f : Type u → Type v) [Functor f] : Prop where
+  id_map   (x : f α) : id <$> x = x
+  comp_map (g : α → β) (h : β → γ) (x : f α) :(h ∘ g) <$> x = h <$> g <$> x
+
+end Example
+
+/-
+`Deriving instances automatically`
+
+We have seen `deriving Repr` in a few examples.
+It is an instance generator.
+Lean comes equipped with generators for the following classes.
+`Repr`, `Inhabited`, `BEq`, `DecidableEq`,
+`Hashable`, `Ord`, `FromToJson`, `SizeOf`
+-/
+
+inductive Tree (α : Type u) where
+  | leaf (val : α)
+  | node (left right : Tree α)
+  deriving DecidableEq, Ord, Inhabited, Repr

doc/examples/NFM2022/nfm14.lean

@@ -0,0 +1,31 @@
+/- Tactics -/
+
+example : p → q → p ∧ q ∧ p := by
+  intro hp hq
+  apply And.intro
+  exact hp
+  apply And.intro
+  exact hq
+  exact hp
+
+example : p → q → p ∧ q ∧ p := by
+  intro hp hq; apply And.intro hp; exact And.intro hq hp
+
+/- Structuring proofs -/
+
+example : p → q → p ∧ q ∧ p := by
+  intro hp hq
+  apply And.intro
+  case left => exact hp
+  case right =>
+    apply And.intro
+    case left => exact hq
+    case right => exact hp
+
+example : p → q → p ∧ q ∧ p := by
+  intro hp hq
+  apply And.intro
+  . exact hp
+  . apply And.intro
+    . exact hq
+    . exact hp

doc/examples/NFM2022/nfm15.lean

@@ -0,0 +1,19 @@
+/- intro tactic variants -/
+
+example (p q : α → Prop) : (∃ x, p x ∧ q x) → ∃ x, q x ∧ p x := by
+  intro h
+  match h with
+  | Exists.intro w (And.intro hp hq) => exact Exists.intro w (And.intro hq hp)
+
+example (p q : α → Prop) : (∃ x, p x ∧ q x) → ∃ x, q x ∧ p x := by
+  intro (Exists.intro _ (And.intro hp hq))
+  exact Exists.intro _ (And.intro hq hp)
+
+example (p q : α → Prop) : (∃ x, p x ∧ q x) → ∃ x, q x ∧ p x := by
+  intro ⟨_, hp, hq⟩
+  exact ⟨_, hq, hp⟩
+
+example (α : Type) (p q : α → Prop) : (∃ x, p x ∨ q x) → ∃ x, q x ∨ p x := by
+  intro
+    | ⟨_, .inl h⟩ => exact ⟨_, .inr h⟩
+    | ⟨_, .inr h⟩ => exact ⟨_, .inl h⟩

doc/examples/NFM2022/nfm16.lean

@@ -0,0 +1,12 @@
+/- Inaccessible names -/
+
+example : ∀ x y : Nat, x = y → y = x := by
+  intros
+  apply Eq.symm
+  assumption
+
+example : ∀ x y : Nat, x = y → y = x := by
+  intros
+  apply Eq.symm
+  rename_i a b hab
+  exact hab

doc/examples/NFM2022/nfm17.lean

@@ -0,0 +1,19 @@
+/- More tactics -/
+
+example (p q : Nat → Prop) : (∃ x, p x ∧ q x) → ∃ x, q x ∧ p x := by
+  intro h
+  cases h with
+  | intro x hpq =>
+    cases hpq with
+    | intro hp hq =>
+      exists x
+
+example : p ∧ q → q ∧ p := by
+  intro p
+  cases p
+  constructor <;> assumption
+
+example : p ∧ ¬ p → q := by
+  intro h
+  cases h
+  contradiction

doc/examples/NFM2022/nfm18.lean

@@ -0,0 +1,20 @@
+/- Structuring proofs (cont.) -/
+
+example : p ∧ (q ∨ r) → (p ∧ q) ∨ (p ∧ r) := by
+  intro h
+  have hp : p := h.left
+  have hqr : q ∨ r := h.right
+  show (p ∧ q) ∨ (p ∧ r)
+  cases hqr with
+  | inl hq => exact Or.inl ⟨hp, hq⟩
+  | inr hr => exact Or.inr ⟨hp, hr⟩
+
+example : p ∧ (q ∨ r) → (p ∧ q) ∨ (p ∧ r) := by
+  intro ⟨hp, hqr⟩
+  cases hqr with
+  | inl hq =>
+    have := And.intro hp hq
+    apply Or.inl; exact this
+  | inr hr =>
+    have := And.intro hp hr
+    apply Or.inr; exact this

doc/examples/NFM2022/nfm19.lean

@@ -0,0 +1,10 @@
+/- Tactic combinators -/
+
+example : p → q → r → p ∧ ((p ∧ q) ∧ r) ∧ (q ∧ r ∧ p) := by
+  intros
+  repeat (any_goals constructor)
+  all_goals assumption
+
+example : p → q → r → p ∧ ((p ∧ q) ∧ r) ∧ (q ∧ r ∧ p) := by
+  intros
+  repeat (any_goals (first | assumption | constructor))

doc/examples/NFM2022/nfm2.lean

@@ -0,0 +1,14 @@
+/- First-class functions -/
+
+def twice (f : Nat → Nat) (a : Nat) :=
+  f (f a)
+
+#check twice
+-- (Nat → Nat) → Nat → Nat
+
+#eval twice (fun x => x + 2) 10
+
+theorem twice_add_2 (a : Nat) : twice (fun x => x + 2) a = a + 4 := rfl
+
+-- `(· + 2)` is syntax sugar for `(fun x => x + 2)`.
+#eval twice (· + 2) 10

doc/examples/NFM2022/nfm20.lean

@@ -0,0 +1,22 @@
+/- Rewriting -/
+
+example (f : Nat → Nat) (k : Nat) (h₁ : f 0 = 0) (h₂ : k = 0) : f k = 0 := by
+  rw [h₂] -- replace k with 0
+  rw [h₁] -- replace f 0 with 0
+
+example (f : Nat → Nat) (k : Nat) (h₁ : f 0 = 0) (h₂ : k = 0) : f k = 0 := by
+  rw [h₂, h₁]
+
+example (f : Nat → Nat) (a b : Nat) (h₁ : a = b) (h₂ : f a = 0) : f b = 0 := by
+  rw [← h₁, h₂]
+
+example (f : Nat → Nat) (a : Nat) (h : 0 + a = 0) : f a = f 0 := by
+  rw [Nat.zero_add] at h
+  rw [h]
+
+def Tuple (α : Type) (n : Nat) :=
+  { as : List α // as.length = n }
+
+example (n : Nat) (h : n = 0) (t : Tuple α n) : Tuple α 0 := by
+  rw [h] at t
+  exact t

doc/examples/NFM2022/nfm21.lean

@@ -0,0 +1,21 @@
+/- Simplifier -/
+
+example (p : Nat → Prop) : (x + 0) * (0 + y * 1 + z * 0) = x * y := by
+  simp
+
+example (p : Nat → Prop) (h : p (x * y)) : p ((x + 0) * (0 + y * 1 + z * 0)) := by
+  simp; assumption
+
+example (p : Nat → Prop) (h : p ((x + 0) * (0 + y * 1 + z * 0))) : p (x * y) := by
+  simp at h; assumption
+
+def f (m n : Nat) : Nat :=
+  m + n + m
+
+example (h : n = 1) (h' : 0 = m) : (f m n) = n := by
+  simp [h, ←h', f]
+
+example (p : Nat → Prop) (h₁ : x + 0 = x') (h₂ : y + 0 = y')
+        : x + y + 0 = x' + y' := by
+  simp at *
+  simp [*]

doc/examples/NFM2022/nfm22.lean

@@ -0,0 +1,13 @@
+/- Simplifier -/
+
+def mk_symm (xs : List α) :=
+  xs ++ xs.reverse
+
+@[simp] theorem reverse_mk_symm : (mk_symm xs).reverse = mk_symm xs := by
+  simp [mk_symm]
+
+theorem tst : (xs ++ mk_symm ys).reverse = mk_symm ys ++ xs.reverse := by
+  simp
+
+#print tst
+-- Lean reverse_mk_symm, and List.reverse_append

doc/examples/NFM2022/nfm23.lean

@@ -0,0 +1,26 @@
+/- split tactic -/
+
+def f (x y z : Nat) : Nat :=
+  match x, y, z with
+  | 5, _, _ => y
+  | _, 5, _ => y
+  | _, _, 5 => y
+  | _, _, _ => 1
+
+example : x ≠ 5 → y ≠ 5 → z ≠ 5 → z = w → f x y w = 1 := by
+  intros
+  simp [f]
+  split
+  . contradiction
+  . contradiction
+  . contradiction
+  . rfl
+
+def g (xs ys : List Nat) : Nat :=
+  match xs, ys with
+  | [a, b], _ => a+b+1
+  | _, [b, c] => b+1
+  | _, _      => 1
+
+example (xs ys : List Nat) (h : g xs ys = 0) : False := by
+  unfold g at h; split at h <;> simp_arith at h

doc/examples/NFM2022/nfm24.lean

@@ -0,0 +1,9 @@
+/- induction tactic -/
+
+example (as : List α) (a : α) : (as.concat a).length = as.length + 1 := by
+  induction as with
+  | nil => rfl
+  | cons x xs ih => simp [List.concat, ih]
+
+example (as : List α) (a : α) : (as.concat a).length = as.length + 1 := by
+  induction as <;> simp! [*]

doc/examples/NFM2022/nfm3.lean

@@ -0,0 +1,59 @@
+/- Enumerated types -/
+
+inductive Weekday where
+  | sunday | monday | tuesday | wednesday
+  | thursday | friday | saturday
+
+#check Weekday.sunday
+-- Weekday
+
+open Weekday
+#check sunday
+
+def natOfWeekday (d : Weekday) : Nat :=
+  match d with
+  | sunday    => 1
+  | monday    => 2
+  | tuesday   => 3
+  | wednesday => 4
+  | thursday  => 5
+  | friday    => 6
+  | saturday  => 7
+
+def Weekday.next (d : Weekday) : Weekday :=
+  match d with
+  | sunday    => monday
+  | monday    => tuesday
+  | tuesday   => wednesday
+  | wednesday => thursday
+  | thursday  => friday
+  | friday    => saturday
+  | saturday  => sunday
+
+def Weekday.previous : Weekday → Weekday
+  | sunday    => saturday
+  | monday    => sunday
+  | tuesday   => monday
+  | wednesday => tuesday
+  | thursday  => wednesday
+  | friday    => thursday
+  | saturday  => friday
+
+/- Proving theorems using tactics -/
+
+theorem Weekday.next_previous (d : Weekday) : d.next.previous = d :=
+  match d with
+  | sunday    => rfl
+  | monday    => rfl
+  | tuesday   => rfl
+  | wednesday => rfl
+  | thursday  => rfl
+  | friday    => rfl
+  | saturday  => rfl
+
+theorem Weekday.next_previous' (d : Weekday) : d.next.previous = d := by -- switch to tactic mode
+  cases d -- Creates 7 goals
+  rfl; rfl; rfl; rfl; rfl; rfl; rfl
+
+theorem Weekday.next_previous'' (d : Weekday) : d.next.previous = d := by
+  cases d <;> rfl

doc/examples/NFM2022/nfm4.lean

@@ -0,0 +1,20 @@
+/- What is the type of Nat? -/
+
+#check 0
+-- Nat
+#check Nat
+-- Type
+#check Type
+-- Type 1
+#check Type 1
+-- Type 2
+#check Eq.refl 2
+-- 2 = 2
+#check 2 = 2
+-- Prop
+#check Prop
+-- Type
+
+example : Prop = Sort 0   := rfl
+example : Type = Sort 1   := rfl
+example : Type 1 = Sort 2 := rfl

doc/examples/NFM2022/nfm5.lean

@@ -0,0 +1,21 @@
+/- Implicit arguments and universe polymorphism -/
+
+def f (α β : Sort u) (a : α) (b : β) : α := a
+
+#eval f Nat String 1 "hello"
+-- 1
+
+def g {α β : Sort u} (a : α) (b : β) : α := a
+
+#eval g 1 "hello"
+
+def h (a : α) (b : β) : α := a
+
+#check g
+-- ?m.1 → ?m.2 → ?m.1
+#check @g
+-- {α β : Sort u} → α → β → α
+#check @h
+-- {α : Sort u_1} → {β : Sort u_2} → α → β → α
+#check g (α := Nat) (β := String)
+-- Nat → String → Nat

doc/examples/NFM2022/nfm6.lean

@@ -0,0 +1,14 @@
+/- Inductive Types -/
+
+inductive Tree (β : Type v) where
+  | leaf
+  | node (left : Tree β) (key : Nat) (value : β) (right : Tree β)
+  deriving Repr
+
+#eval Tree.node .leaf 10 true .leaf
+-- Tree.node Tree.leaf 10 true Tree.leaf
+
+inductive Vector (α : Type u) : Nat → Type u
+  | nil : Vector α 0
+  | cons : α → Vector α n → Vector α (n+1)
+

doc/examples/NFM2022/nfm7.lean

@@ -0,0 +1,25 @@
+/- Recursive functions -/
+
+#print Nat -- Nat is an inductive datatype
+
+def fib (n : Nat) : Nat :=
+  match n with
+  | 0 => 1
+  | 1 => 1
+  | n+2 => fib (n+1) + fib n
+
+example : fib 5 = 8 := rfl
+
+example : fib (n+2) = fib (n+1) + fib n := rfl
+
+#print fib
+/-
+def fib : Nat → Nat :=
+fun n =>
+  Nat.brecOn n fun n f =>
+    (match (motive := (n : Nat) → Nat.below n → Nat) n with
+      | 0 => fun x => 1
+      | 1 => fun x => 1
+      | Nat.succ (Nat.succ n) => fun x => x.fst.fst + x.fst.snd.fst.fst)
+      f
+-/

doc/examples/NFM2022/nfm8.lean

@@ -0,0 +1,25 @@
+/- Well-founded recursion -/
+
+def ack : Nat → Nat → Nat
+  | 0,   y   => y+1
+  | x+1, 0   => ack x 1
+  | x+1, y+1 => ack x (ack (x+1) y)
+termination_by ack x y => (x, y)
+
+def sum (a : Array Int) : Int :=
+  let rec go (i : Nat) :=
+     if i < a.size then
+        a[i] + go (i+1)
+     else
+        0
+  go 0
+termination_by go i => a.size - i
+
+set_option pp.proofs true
+#print sum.go
+/-
+def sum.go : Array Int → Nat → Int :=
+fun a =>
+  WellFounded.fix (sum.go.proof_1 a) fun i a_1 =>
+    if h : i < Array.size a then Array.getOp a i + a_1 (i + 1) (sum.go.proof_2 a i h) else 0
+-/

doc/examples/NFM2022/nfm9.lean

@@ -0,0 +1,44 @@
+/- Mutual recursion -/
+
+inductive Term where
+ | const : String → Term
+ | app   : String → List Term → Term
+
+namespace Term
+mutual
+ def numConsts : Term → Nat
+   | const _ => 1
+   | app _ cs => numConstsLst cs
+
+ def numConstsLst : List Term → Nat
+   | [] => 0
+   | c :: cs => numConsts c + numConstsLst cs
+end
+
+mutual
+  def replaceConst (a b : String) : Term → Term
+   | const c => if a = c then const b else const c
+   | app f cs => app f (replaceConstLst a b cs)
+
+  def replaceConstLst (a b : String) : List Term → List Term
+   | [] => []
+   | c :: cs => replaceConst a b c :: replaceConstLst a b cs
+end
+
+/- Mutual recursion in theorems -/
+
+mutual
+  theorem numConsts_replaceConst (a b : String) (e : Term)
+            : numConsts (replaceConst a b e) = numConsts e := by
+    match e with
+    | const c => simp [replaceConst]; split <;> simp [numConsts]
+    | app f cs => simp [replaceConst, numConsts, numConsts_replaceConstLst a b cs]
+
+  theorem numConsts_replaceConstLst (a b : String) (es : List Term)
+            : numConstsLst (replaceConstLst a b es) = numConstsLst es := by
+    match es with
+    | [] => simp [replaceConstLst, numConstsLst]
+    | c :: cs =>
+      simp [replaceConstLst, numConstsLst, numConsts_replaceConst a b c,
+            numConsts_replaceConstLst a b cs]
+end

doc/examples/bintree.lean

@@ -0,0 +1,295 @@
+/-!
+# Binary Search Trees
+
+If the type of keys can be totally ordered -- that is, it supports a well-behaved `≤` comparison --
+then maps can be implemented with binary search trees (BSTs). Insert and lookup operations on BSTs take time
+proportional to the height of the tree. If the tree is balanced, the operations therefore take logarithmic time.
+
+This example is based on a similar example found in the ["Sofware Foundations"](https://softwarefoundations.cis.upenn.edu/vfa-current/SearchTree.html)
+book (volume 3).
+-/
+
+/-!
+We use `Nat` as the key type in our implementation of BSTs,
+since it has a convenient total order with lots of theorems and automation available.
+We leave as an exercise to the reader the generalization to arbitrary types.
+-/
+
+inductive Tree (β : Type v) where
+  | leaf
+  | node (left : Tree β) (key : Nat) (value : β) (right : Tree β)
+  deriving Repr
+
+/-!
+The function `contains` returns `true` iff the given tree contains the key `k`.
+-/
+def Tree.contains (t : Tree β) (k : Nat) : Bool :=
+  match t with
+  | leaf => false
+  | node left key value right =>
+    if k < key then
+      left.contains k
+    else if key < k then
+      right.contains k
+    else
+      true
+
+/-!
+`t.find? k` returns `some v` if `v` is the value bound to key `k` in the tree `t`. It returns `none` otherwise.
+-/
+def Tree.find? (t : Tree β) (k : Nat) : Option β :=
+  match t with
+  | leaf => none
+  | node left key value right =>
+    if k < key then
+      left.find? k
+    else if key < k then
+      right.find? k
+    else
+      some value
+
+/-!
+`t.insert k v` is the map containing all the bindings of `t` along with a binding of `k` to `v`.
+-/
+def Tree.insert (t : Tree β) (k : Nat) (v : β) : Tree β :=
+  match t with
+  | leaf => node leaf k v leaf
+  | node left key value right =>
+    if k < key then
+      node (left.insert k v) key value right
+    else if key < k then
+      node left key value (right.insert k v)
+    else
+      node left k v right
+/-!
+Let's add a new operation to our tree: converting it to an association list that contains the key--value bindings from the tree stored as pairs.
+If that list is sorted by the keys, then any two trees that represent the same map would be converted to the same list.
+Here's a function that does so with an in-order traversal of the tree.
+-/
+def Tree.toList (t : Tree β) : List (Nat × β) :=
+  match t with
+  | leaf => []
+  | node l k v r => l.toList ++ [(k, v)] ++ r.toList
+
+#eval Tree.leaf.insert 2 "two"
+      |>.insert 3 "three"
+      |>.insert 1 "one"
+
+#eval Tree.leaf.insert 2 "two"
+      |>.insert 3 "three"
+      |>.insert 1 "one"
+      |>.toList
+
+/-!
+The implemention of `Tree.toList` is inefficient because of how it uses the `++` operator.
+On a balanced tree its running time is linearithmic, because it does a linear number of
+concatentations at each level of the tree. On an unbalanced tree it's quadratic time.
+Here's a tail-recursive implementation than runs in linear time, regardless of whether the tree is balanced:
+-/
+def Tree.toListTR (t : Tree β) : List (Nat × β) :=
+  go t []
+where
+  go (t : Tree β) (acc : List (Nat × β)) : List (Nat × β) :=
+    match t with
+    | leaf => acc
+    | node l k v r => l.go ((k, v) :: r.go acc)
+
+/-!
+We now prove that `t.toList` and `t.toListTR` return the same list.
+The proof is on induction, and as we used the auxiliary function `go`
+to define `Tree.toListTR`, we use the auxiliary theorem `go` to prove the theorem.
+
+The proof of the auxiliary theorem is by induction on `t`.
+The `generalizing acc` modifier instructs Lean to revert `acc`, apply the
+induction theorem for `Tree`s, and then reintroduce `acc` in each case.
+By using `generalizing`, we obtain the more general induction hypotheses
+
+- `left_ih : ∀ acc, toListTR.go left acc = toList left ++ acc`
+
+- `right_ih : ∀ acc, toListTR.go right acc = toList right ++ acc`
+
+Recall that the combinator `tac <;> tac'` runs `tac` on the main goal and `tac'` on each produced goal,
+concatenating all goals produced by `tac'`. In this theorem, we use it to apply
+`simp` and close each subgoal produced by the `induction` tactic.
+
+The `simp` parameters `toListTR.go` and `toList` instruct the simplifier to try to reduce
+and/or apply auto generated equation theorems for these two functions.
+The parameter `*` intructs the simplifier to use any equation in a goal as rewriting rules.
+In this particular case, `simp` uses the induction hypotheses as rewriting rules.
+Finally, the parameter `List.append_assoc` intructs the simplifier to use the
+`List.append_assoc` theorem as a rewriting rule.
+-/
+theorem Tree.toList_eq_toListTR (t : Tree β)
+        : t.toList = t.toListTR := by
+  simp [toListTR, go t []]
+where
+  go (t : Tree β) (acc : List (Nat × β))
+     : toListTR.go t acc = t.toList ++ acc := by
+    induction t generalizing acc <;>
+      simp [toListTR.go, toList, *, List.append_assoc]
+
+/-!
+The `[csimp]` annotation instructs the Lean code generator to replace
+any `Tree.toList` with `Tree.toListTR` when generating code.
+-/
+@[csimp] theorem Tree.toList_eq_toListTR_csimp
+                 : @Tree.toList = @Tree.toListTR := by
+  funext β t
+  apply toList_eq_toListTR
+
+/-!
+The implementations of `Tree.find?` and `Tree.insert` assume that values of type tree obey the BST invariant:
+for any non-empty node with key `k`, all the values of the `left` subtree are less than `k` and all the values
+of the right subtree are greater than `k`. But that invariant is not part of the definition of tree.
+
+So, let's formalize the BST invariant. Here's one way to do so. First, we define a helper `ForallTree`
+to express that idea that a predicate holds at every node of a tree:
+-/
+inductive ForallTree (p : Nat → β → Prop) : Tree β → Prop
+  | leaf : ForallTree p .leaf
+  | node :
+     ForallTree p left →
+     p key value →
+     ForallTree p right →
+     ForallTree p (.node left key value right)
+
+/-!
+Second, we define the BST invariant:
+An empty tree is a BST.
+A non-empty tree is a BST if all its left nodes have a lesser key, its right nodes have a greater key, and the left and right subtrees are themselves BSTs.
+-/
+inductive BST : Tree β → Prop
+  | leaf : BST .leaf
+  | node :
+     ForallTree (fun k v => k < key) left →
+     ForallTree (fun k v => key < k) right →
+     BST left → BST right →
+     BST (.node left key value right)
+
+/-!
+We can use the `macro` command to create helper tactics for organizing our proofs.
+The macro `have_eq x y` tries to prove `x = y` using linear arithmetic, and then
+immediately uses the new equality to substitute `x` with `y` everywhere in the goal.
+
+The modifier `local` specifies the scope of the macro.
+-/
+/-- The `have_eq lhs rhs` tactic (tries to) prove that `lhs = rhs`,
+    and then replaces `lhs` with `rhs`. -/
+local macro "have_eq " lhs:term:max rhs:term:max : tactic =>
+  `((have h : $lhs:term = $rhs:term :=
+       -- TODO: replace with linarith
+       by simp_arith at *; apply Nat.le_antisymm <;> assumption
+     try subst $lhs:term))
+
+/-!
+The `by_cases' e` is just the regular `by_cases` followed by `simp` using all
+hypotheses in the current goal as rewriting rules.
+Recall that the `by_cases` tactic creates two goals. One where we have `h : e` and
+another one containing `h : ¬ e`. The simplier uses the `h` to rewrite `e` to `True`
+in the first subgoal, and `e` to `False` in the second. This is particularly
+useful if `e` is the condition of an `if`-statement.
+-/
+/-- `by_cases' e` is a shorthand form `by_cases e <;> simp[*]` -/
+local macro "by_cases' " e:term :  tactic =>
+  `(by_cases $e:term <;> simp [*])
+
+
+/-!
+We can use the attribute `[simp]` to instruct the simplifier to reduce given definitions or
+apply rewrite theorems. The `local` modifier limits the scope of this modification to this file.
+-/
+attribute [local simp] Tree.insert
+
+/-!
+We now prove that `Tree.insert` preserves the BST invariant using induction and case analysis.
+Recall that the tactic `. tac` focuses on the main goal and tries to solve it using `tac`, or else fails.
+It is used to structure proofs in Lean.
+The notation `‹e›` is just syntax sugar for `(by assumption : e)`. That is, it tries to find a hypothesis `h : e`.
+It is useful to access hypothesis that have auto generated names (aka "inaccessible") names.
+-/
+
+theorem Tree.forall_insert_of_forall
+        (h₁ : ForallTree p t) (h₂ : p key value)
+        : ForallTree p (t.insert key value) := by
+  induction h₁ with
+  | leaf => exact .node .leaf h₂ .leaf
+  | node hl hp hr ihl ihr =>
+    rename Nat => k
+    by_cases' key < k
+    . exact .node ihl hp hr
+    . by_cases' k < key
+      . exact .node hl hp ihr
+      . have_eq key k
+        exact .node hl h₂ hr
+
+theorem Tree.bst_insert_of_bst
+        {t : Tree β} (h : BST t) (key : Nat) (value : β)
+        : BST (t.insert key value) := by
+  induction h with
+  | leaf => exact .node .leaf .leaf .leaf .leaf
+  | node h₁ h₂ b₁ b₂ ih₁ ih₂ =>
+    rename Nat => k
+    simp
+    by_cases' key < k
+    . exact .node (forall_insert_of_forall h₁ ‹key < k›) h₂ ih₁ b₂
+    . by_cases' k < key
+      . exact .node h₁ (forall_insert_of_forall h₂ ‹k < key›) b₁ ih₂
+      . have_eq key k
+        exact .node h₁ h₂ b₁ b₂
+
+/-!
+Now, we define the type `BinTree` using a `Subtype` that states that only trees satisfying the BST invariant are `BinTree`s.
+-/
+def BinTree (β : Type u) := { t : Tree β // BST t }
+
+def BinTree.mk : BinTree β :=
+  ⟨.leaf, .leaf⟩
+
+def BinTree.contains (b : BinTree β) (k : Nat) : Bool :=
+  b.val.contains k
+
+def BinTree.find? (b : BinTree β) (k : Nat) : Option β :=
+  b.val.find? k
+
+def BinTree.insert (b : BinTree β) (k : Nat) (v : β) : BinTree β :=
+  ⟨b.val.insert k v, b.val.bst_insert_of_bst b.property k v⟩
+
+/-!
+Finally, we prove that `BinTree.find?` and `BinTree.insert` satisfy the map properties.
+-/
+
+attribute [local simp]
+  BinTree.mk BinTree.contains BinTree.find?
+  BinTree.insert Tree.find? Tree.contains Tree.insert
+
+theorem BinTree.find_mk (k : Nat)
+        : BinTree.mk.find? k = (none : Option β) := by
+  simp
+
+theorem BinTree.find_insert (b : BinTree β) (k : Nat) (v : β)
+        : (b.insert k v).find? k = some v := by
+  let ⟨t, h⟩ := b; simp
+  induction t with simp
+  | node left key value right ihl ihr =>
+    by_cases' k < key
+    . cases h; apply ihl; assumption
+    . by_cases' key < k
+      cases h; apply ihr; assumption
+
+theorem BinTree.find_insert_of_ne (b : BinTree β) (h : k ≠ k') (v : β)
+        : (b.insert k v).find? k' = b.find? k' := by
+  let ⟨t, h⟩ := b; simp
+  induction t with simp
+  | leaf =>
+    split <;> simp <;> split <;> simp
+    have_eq k k'
+    contradiction
+  | node left key value right ihl ihr =>
+    let .node hl hr bl br := h
+    specialize ihl bl
+    specialize ihr br
+    by_cases' k < key; by_cases' key < k
+    have_eq key k
+    by_cases' k' < k; by_cases' k  < k'
+    have_eq k k'
+    contradiction

doc/examples/bintree.lean.md

@@ -0,0 +1,5 @@
+(this example is rendered by Alectryon in the CI)
+
+```lean
+{{#include bintree.lean}}
+```

doc/examples/deBruijn.lean

@@ -0,0 +1,163 @@
+/-!
+# Dependent de Bruijn Indices
+
+In this example, we represent program syntax terms in a type family parameterized by a list of types,
+representing the typing context, or information on which free variables are in scope and what
+their types are.
+
+
+Remark: this example is based on an example in the book [Certified Programming with Dependent Types](http://adam.chlipala.net/cpdt/) by Adam Chlipala.
+-/
+
+/-!
+Programmers who move to statically typed functional languages from scripting languages
+often complain about the requirement that every element of a list have the same type. With
+fancy type systems, we can partially lift this requirement. We can index a list type with a
+“type-level” list that explains what type each element of the list should have. This has been
+done in a variety of ways in Haskell using type classes, and we can do it much more cleanly
+and directly in Lean.
+
+We parameterize our heterogeneous lists by at type `α` and an `α`-indexed type `β`.
+-/
+
+inductive HList {α : Type v} (β : α → Type u) : List α → Type (max u v)
+  | nil  : HList β []
+  | cons : β i → HList β is → HList β (i::is)
+
+/-!
+We overload the `List.cons` notation `::` so we can also use it to create
+heterogeneous lists.
+-/
+infix:67 " :: " => HList.cons
+
+/-! We similarly overload the `List` notation `[]` for the empty heterogeneous list. -/
+notation "[" "]" => HList.nil
+
+/-!
+Variables are represented in a way isomorphic to the natural numbers, where
+number 0 represents the first element in the context, number 1 the second element, and so
+on. Actually, instead of numbers, we use the `Member` inductive family.
+
+The value of type `Member a as` can be viewed as a certificate that `a` is
+an element of the list `as`. The constructor `Member.head` says that `a`
+is in the list if the list begins with it. The constructor `Member.tail`
+says that if `a` is in the list `bs`, it is also in the list `b::bs`.
+-/
+inductive Member : α → List α → Type
+  | head : Member a (a::as)
+  | tail : Member a bs → Member a (b::bs)
+
+/-!
+Given a heterogeneous list `HList β is` and value of type `Member i is`, `HList.get`
+retrieves an element of type `β i` from the list.
+The pattern `.head` and `.tail h` are sugar for `Member.head` and `Member.tail h` respectively.
+Lean can infer the namespace using the expected type.
+-/
+def HList.get : HList β is → Member i is → β i
+  | a::as, .head => a
+  | a::as, .tail h => as.get h
+
+/-!
+Here is the definition of the simple type system for our programming language, a simply typed
+lambda calculus with natural numbers as the base type.
+-/
+inductive Ty where
+  | nat
+  | fn : Ty → Ty → Ty
+
+/-!
+We can write a function to translate `Ty` values to a Lean type
+— remember that types are first class, so can be calculated just like any other value.
+We mark `Ty.denote` as `[reducible]` to make sure the typeclass resolution procedure can
+unfold/reduce it. For example, suppose Lean is trying to synthesize a value for the instance
+`Add (Ty.denote Ty.nat)`. Since `Ty.denote` is marked as `[reducible]`,
+the typeclass resolution procedure can reduce `Ty.denote Ty.nat` to `Nat`, and use
+the builtin instance for `Add Nat` as the solution.
+
+Recall that the term `a.denote` is sugar for `denote a` where `denote` is the function being defined.
+We call it the "dot notation".
+-/
+@[reducible] def Ty.denote : Ty → Type
+  | nat    => Nat
+  | fn a b => a.denote → b.denote
+
+/-!
+Here is the definition of the `Term` type, including variables, constants, addition,
+function application and abstraction, and let binding of local variables.
+Since `let` is a keyword in Lean, we use the "escaped identifier" `«let»`.
+You can input the unicode (French double quotes) using `\f<<` (for `«`) and `\f>>` (for `»`).
+The term `Term ctx .nat` is sugar for `Term ctx Ty.nat`, Lean infers the namespace using the expected type.
+-/
+inductive Term : List Ty → Ty → Type
+  | var   : Member ty ctx → Term ctx ty
+  | const : Nat → Term ctx .nat
+  | plus  : Term ctx .nat → Term ctx .nat → Term ctx .nat
+  | app   : Term ctx (.fn dom ran) → Term ctx dom → Term ctx ran
+  | lam   : Term (dom :: ctx) ran → Term ctx (.fn dom ran)
+  | «let» : Term ctx ty₁ → Term (ty₁ :: ctx) ty₂ → Term ctx ty₂
+
+/-!
+Here are two example terms encoding, the first addition packaged as a two-argument
+curried function, and the second of a sample application of addition to constants.
+
+The command `open Ty Term Member` opens the namespaces `Ty`, `Term`, and `Member`. Thus,
+you can write `lam` instead of `Term.lam`.
+-/
+open Ty Term Member
+def add : Term [] (fn nat (fn nat nat)) :=
+  lam (lam (plus (var (tail head)) (var head)))
+
+def three_the_hard_way : Term [] nat :=
+  app (app add (const 1)) (const 2)
+
+/-!
+Since dependent typing ensures that any term is well-formed in its context and has a particular type,
+it is easy to translate syntactic terms into Lean values.
+
+The attribute `[simp]` instructs Lean to always try to unfold `Term.denote` applications when one applies
+the `simp` tactic. We also say this is a hint for the Lean term simplifier.
+-/
+@[simp] def Term.denote : Term ctx ty → HList Ty.denote ctx → ty.denote
+  | var h,     env => env.get h
+  | const n,   _   => n
+  | plus a b,  env => a.denote env + b.denote env
+  | app f a,   env => f.denote env (a.denote env)
+  | lam b,     env => fun x => b.denote (x :: env)
+  | «let» a b, env => b.denote (a.denote env :: env)
+
+/-!
+You can show that the denotation of `three_the_hard_way` is indeed `3` using reflexivity.
+-/
+example : three_the_hard_way.denote [] = 3 :=
+  rfl
+
+/-!
+We now define the constant folding optimization that traverses a term if replaces subterms such as
+`plus (const m) (const n)` with `const (n+m)`.
+-/
+@[simp] def Term.constFold : Term ctx ty → Term ctx ty
+  | const n   => const n
+  | var h     => var h
+  | app f a   => app f.constFold a.constFold
+  | lam b     => lam b.constFold
+  | «let» a b => «let» a.constFold b.constFold
+  | plus a b  =>
+    match a.constFold, b.constFold with
+    | const n, const m => const (n+m)
+    | a',      b'      => plus a' b'
+
+/-!
+The correctness of the `Term.constFold` is proved using induction, case-analysis, and the term simplifier.
+We prove all cases but the one for `plus` using `simp [*]`. This tactic instructs the term simplifier to
+use hypotheses such as `a = b` as rewriting/simplications rules.
+We use the `split` to break the nested `match` expression in the `plus` case into two cases.
+The local variables `iha` and `ihb` are the induction hypotheses for `a` and `b`.
+The modifier `←` in a term simplifier argument instructs the term simplier to use the equation as a rewriting rule in
+the "reverse direction. That is, given `h : a = b`, `← h` instructs the term simplifier to rewrite `b` subterms to `a`.
+-/
+theorem Term.constFold_sound (e : Term ctx ty) : e.constFold.denote env = e.denote env := by
+  induction e with simp [*]
+  | plus a b iha ihb =>
+    split
+    next he₁ he₂ => simp [← iha, ← ihb, he₁, he₂]
+    next => simp [iha, ihb]

doc/examples/deBruijn.lean.md

@@ -0,0 +1,5 @@
+(this example is rendered by Alectryon in the CI)
+
+```lean
+{{#include deBruijn.lean}}
+```

doc/examples/interp.lean

@@ -0,0 +1,152 @@
+/-!
+# The Well-Typed Interpreter
+
+In this example, we build an interpreter for a simple functional programming language,
+with variables, function application, binary operators and an `if...then...else` construct.
+We will use the dependent type system to ensure that any programs which can be represented are well-typed.
+
+Remark: this example is based on an example found in the Idris manual.
+-/
+
+/-!
+Vectors
+--------
+
+A `Vector` is a list of size `n` whose elements belong to a type `α`.
+-/
+
+inductive Vector (α : Type u) : Nat → Type u
+  | nil : Vector α 0
+  | cons : α → Vector α n → Vector α (n+1)
+
+/-!
+We can overload the `List.cons` notation `::` and use it to create `Vector`s.
+-/
+infix:67 " :: " => Vector.cons
+
+/-!
+Now, we define the types of our simple functional language.
+We have integers, booleans, and functions, represented by `Ty`.
+-/
+inductive Ty where
+  | int
+  | bool
+  | fn (a r : Ty)
+
+/-!
+We can write a function to translate `Ty` values to a Lean type
+— remember that types are first class, so can be calculated just like any other value.
+We mark `Ty.interp` as `[reducible]` to make sure the typeclass resolution procedure can
+unfold/reduce it. For example, suppose Lean is trying to synthesize a value for the instance
+`Add (Ty.interp Ty.int)`. Since `Ty.interp` is marked as `[reducible]`,
+the typeclass resolution procedure can reduce `Ty.interp Ty.int` to `Int`, and use
+the builtin instance for `Add Int` as the solution.
+-/
+@[reducible] def Ty.interp : Ty → Type
+  | int    => Int
+  | bool   => Bool
+  | fn a r => a.interp → r.interp
+
+/-!
+Expressions are indexed by the types of the local variables, and the type of the expression itself.
+-/
+inductive HasType : Fin n → Vector Ty n → Ty → Type where
+  | stop : HasType 0 (ty :: ctx) ty
+  | pop  : HasType k ctx ty → HasType k.succ (u :: ctx) ty
+
+inductive Expr : Vector Ty n → Ty → Type where
+  | var   : HasType i ctx ty → Expr ctx ty
+  | val   : Int → Expr ctx Ty.int
+  | lam   : Expr (a :: ctx) ty → Expr ctx (Ty.fn a ty)
+  | app   : Expr ctx (Ty.fn a ty) → Expr ctx a → Expr ctx ty
+  | op    : (a.interp → b.interp → c.interp) → Expr ctx a → Expr ctx b → Expr ctx c
+  | ife   : Expr ctx Ty.bool → Expr ctx a → Expr ctx a → Expr ctx a
+  | delay : (Unit → Expr ctx a) → Expr ctx a
+
+/-!
+We use the command `open` to create the aliases `stop` and `pop` for `HasType.stop` and `HasType.pop` respectively.
+-/
+open HasType (stop pop)
+
+/-!
+Since expressions are indexed by their type, we can read the typing rules of the language from the definitions of the constructors.
+Let us look at each constructor in turn.
+
+We use a nameless representation for variables — they are de Bruijn indexed.
+Variables are represented by a proof of their membership in the context, `HasType i ctx ty`,
+which is a proof that variable `i` in context `ctx` has type `ty`.
+
+We can treat `stop` as a proof that the most recently defined variable is well-typed,
+and `pop n` as a proof that, if the `n`th most recently defined variable is well-typed, so is the `n+1`th.
+In practice, this means we use `stop` to refer to the most recently defined variable,
+`pop stop` to refer to the next, and so on, via the `Expr.var` constructor.
+
+A value `Expr.val` carries a concrete representation of an integer.
+
+A lambda `Expr.lam` creates a function. In the scope of a function ot type `Ty.fn a ty`, there is a
+new local variable of type `a`.
+
+A function application `Expr.app` produces a value of type `ty` given a function from `a` to `ty` and a value of type `a`.
+
+The constructor `Expr.op` allows us to use arbitrary binary operators, where the type of the operator informs what the types of the arguments must be.
+
+Finally, the constructor `Exp.ife` represents a `if-then-else` expression. The condition is a Boolean, and each branch must have the same type.
+
+The auxiliary constructor `Expr.delay` is used to delay evaluation.
+-/
+
+
+/-!
+When we evaluate an `Expr`, we’ll need to know the values in scope, as well as their types. `Env` is an environment,
+indexed over the types in scope. Since an environment is just another form of list, albeit with a strongly specified connection
+to the vector of local variable types, we overload again the notation `::` so that we can use the usual list syntax.
+Given a proof that a variable is defined in the context, we can then produce a value from the environment.
+-/
+inductive Env : Vector Ty n → Type where
+  | nil  : Env Vector.nil
+  | cons : Ty.interp a → Env ctx → Env (a :: ctx)
+
+infix:67 " :: " => Env.cons
+
+def Env.lookup : HasType i ctx ty → Env ctx → ty.interp
+  | stop,  x :: xs => x
+  | pop k, x :: xs => lookup k xs
+
+/-!
+Given this, an interpreter is a function which translates an `Expr` into a Lean value with respect to a specific environment.
+-/
+def Expr.interp (env : Env ctx) : Expr ctx ty → ty.interp
+  | var i     => env.lookup i
+  | val x     => x
+  | lam b     => fun x => b.interp (Env.cons x env)
+  | app f a   => f.interp env (a.interp env)
+  | op o x y  => o (x.interp env) (y.interp env)
+  | ife c t e => if c.interp env then t.interp env else e.interp env
+  | delay a   => (a ()).interp env
+
+open Expr
+
+/-!
+We can make some simple test functions. Firstly, adding two inputs `fun x y => y + x` is written as follows.
+-/
+
+def add : Expr ctx (Ty.fn Ty.int (Ty.fn Ty.int Ty.int)) :=
+  lam (lam (op (·+·) (var stop) (var (pop stop))))
+
+#eval add.interp Env.nil 10 20
+
+/-!
+More interestingly, a factorial function fact (e.g. `fun x => if (x == 0) then 1 else (fact (x-1) * x)`), can be written as.
+Note that this is a recursive (non-terminating) definition. For every input value, the interpreter terminates, but the
+definition itself is non-terminating. We use two tricks to make sure Lean accepts it. First, we use the auxiliary constructor
+`Expr.delay` to delay its unfolding. Second, we add the annotation `decreasing_by sorry` which can be viwed as
+"trust me, this recursive definition makes sense". Recall that `sorry` is an unsound axiom in Lean.
+-/
+
+def fact : Expr ctx (Ty.fn Ty.int Ty.int) :=
+  lam (ife (op (·==·) (var stop) (val 0))
+           (val 1)
+           (op (·*·) (delay fun _ => app fact (op (·-·) (var stop) (val 1))) (var stop)))
+  decreasing_by sorry
+
+#eval fact.interp Env.nil 10

doc/examples/interp.lean.md

@@ -0,0 +1,5 @@
+(this example is rendered by Alectryon in the CI)
+
+```lean
+{{#include interp.lean}}
+```

doc/examples/palindromes.lean

@@ -0,0 +1,122 @@
+/-!
+# Palindromes
+
+Palindromes are lists that read the same from left to right and from right to left.
+For example, `[a, b, b, a]` and `[a, h, a]` are palindromes.
+
+We use an inductive predicate to specify whether a list is a palindrome or not.
+Recall that inductive predicates, or inductively defined propositions, are a convenient
+way to specify functions of type `... → Prop`.
+
+This example is a based on an example from the book "The Hitchhiker's Guide to Logical Verification".
+-/
+
+inductive Palindrome : List α → Prop where
+  | nil      : Palindrome []
+  | single   : (a : α) → Palindrome [a]
+  | sandwich : (a : α) → Palindrome as → Palindrome ([a] ++ as ++ [a])
+
+/-!
+The definition distinguishes three cases: (1) `[]` is a palindrome; (2) for any element
+`a`, the singleton list `[a]` is a palindrome; (3) for any element `a` and any palindrome
+`[b₁, . . ., bₙ]`, the list `[a, b₁, . . ., bₙ, a]` is a palindrome.
+-/
+
+/-!
+We now prove that the reverse of a palindrome is a palindrome using induction on the inductive predicate `h : Palindrome as`.
+-/
+theorem palindrome_reverse (h : Palindrome as) : Palindrome as.reverse := by
+  induction h with
+  | nil => exact Palindrome.nil
+  | single a => exact Palindrome.single a
+  | sandwich a h ih => simp; exact Palindrome.sandwich _ ih
+
+/-! If a list `as` is a palindrome, then the reverse of `as` is equal to itself. -/
+theorem reverse_eq_of_palindrome (h : Palindrome as) : as.reverse = as := by
+  induction h with
+  | nil => rfl
+  | single a => rfl
+  | sandwich a h ih => simp [ih]
+
+/-! Note that you can also easily prove `palindrome_reverse` using `reverse_eq_of_palindrome`. -/
+example (h : Palindrome as) : Palindrome as.reverse := by
+  simp [reverse_eq_of_palindrome h, h]
+
+/-!
+Given a nonempty list, the function `List.last` returns its element.
+Note that we use `(by simp)` to prove that `a₂ :: as ≠ []` in the recursive application.
+-/
+def List.last : (as : List α) → as ≠ [] → α
+  | [a],         _ => a
+  | a₁::a₂:: as, _ => (a₂::as).last (by simp)
+
+/-!
+We use the function `List.last` to prove the following theorem that says that if a list `as` is not empty,
+then removing the last element from `as` and appending it back is equal to `as`.
+We use the attribute `@[simp]` to instruct the `simp` tactic to use this theorem as a simplification rule.
+-/
+@[simp] theorem List.dropLast_append_last (h : as ≠ []) : as.dropLast ++ [as.last h] = as := by
+  match as with
+  | [] => contradiction
+  | [a] => simp_all [last, dropLast]
+  | a₁ :: a₂ :: as =>
+    simp [last, dropLast]
+    exact dropLast_append_last (as := a₂ :: as) (by simp)
+
+/-!
+We now define the following auxiliary induction principle for lists using well-founded recursion on `as.length`.
+We can read it as follows, to prove `motive as`, it suffices to show that: (1) `motive []`; (2) `motive [a]` for any `a`;
+(3) if `motive as` holds, then `motive ([a] ++ as ++ [b])` also holds for any `a`, `b`, and `as`.
+Note that the structure of this induction principle is very similar to the `Palindrome` inductive predicate.
+-/
+theorem List.palindrome_ind (motive : List α → Prop)
+    (h₁ : motive [])
+    (h₂ : (a : α) → motive [a])
+    (h₃ : (a b : α) → (as : List α) → motive as → motive ([a] ++ as ++ [b]))
+    (as : List α)
+    : motive as :=
+  match as with
+  | []  => h₁
+  | [a] => h₂ a
+  | a₁::a₂::as' =>
+    have ih := palindrome_ind motive h₁ h₂ h₃ (a₂::as').dropLast
+    have : [a₁] ++ (a₂::as').dropLast ++ [(a₂::as').last (by simp)] = a₁::a₂::as' := by simp
+    this ▸ h₃ _ _ _ ih
+termination_by _ as => as.length
+
+/-!
+We use our new induction principle to prove that if `as.reverse = as`, then `Palindrome as` holds.
+Note that we use the `using` modifier to instruct the `induction` tactic to use this induction principle
+instead of the default one for lists.
+-/
+theorem List.palindrome_of_eq_reverse (h : as.reverse = as) : Palindrome as := by
+  induction as using palindrome_ind
+  next   => exact Palindrome.nil
+  next a => exact Palindrome.single a
+  next a b as ih =>
+    have : a = b := by simp_all
+    subst this
+    have : as.reverse = as := by simp_all
+    exact Palindrome.sandwich a (ih this)
+
+/-!
+We now define a function that returns `true` iff `as` is a palindrome.
+The function assumes that the type `α` has decidable equality. We need this assumption
+because we need to compare the list elements.
+-/
+def List.isPalindrome [DecidableEq α] (as : List α) : Bool :=
+    as.reverse = as
+
+/-!
+It is straightforward to prove that `isPalindrome` is correct using the previously proved theorems.
+-/
+theorem List.isPalindrome_correct [DecidableEq α] (as : List α) : as.isPalindrome ↔ Palindrome as := by
+  simp [isPalindrome]
+  exact Iff.intro (fun h => palindrome_of_eq_reverse h) (fun h => reverse_eq_of_palindrome h)
+
+#eval [1, 2, 1].isPalindrome
+#eval [1, 2, 3, 1].isPalindrome
+
+example : [1, 2, 1].isPalindrome := rfl
+example : [1, 2, 2, 1].isPalindrome := rfl
+example : ![1, 2, 3, 1].isPalindrome := rfl

doc/examples/palindromes.lean.md

@@ -0,0 +1,5 @@
+(this example is rendered by Alectryon in the CI)
+
+```lean
+{{#include palindromes.lean}}
+```

doc/examples/phoas.lean

@@ -0,0 +1,240 @@
+/-!
+# Parametric Higher-Order Abstract Syntax
+
+In contrast to first-order encodings, higher-order encodings avoid explicit modeling of variable identity.
+Instead, the binding constructs of an object language (the language being
+formalized) can be represented using the binding constructs of the meta language (the language in which the formalization is done).
+The best known higher-order encoding is called higher-order abstract syntax (HOAS),
+and we can start by attempting to apply it directly in Lean.
+
+Remark: this example is based on an example in the book [Certified Programming with Dependent Types](http://adam.chlipala.net/cpdt/) by Adam Chlipala.
+-/
+
+/-!
+Here is the definition of the simple type system for our programming language, a simply typed
+lambda calculus with natural numbers as the base type.
+-/
+inductive Ty where
+  | nat
+  | fn : Ty → Ty → Ty
+
+/-!
+We can write a function to translate `Ty` values to a Lean type
+— remember that types are first class, so can be calculated just like any other value.
+We mark `Ty.denote` as `[reducible]` to make sure the typeclass resolution procedure can
+unfold/reduce it. For example, suppose Lean is trying to synthesize a value for the instance
+`Add (Ty.denote Ty.nat)`. Since `Ty.denote` is marked as `[reducible],
+the typeclass resolution procedure can reduce `Ty.denote Ty.nat` to `Nat`, and use
+the builtin instance for `Add Nat` as the solution.
+
+Recall that the term `a.denote` is sugar for `denote a` where `denote` is the function being defined.
+We call it the "dot notation".
+-/
+@[reducible] def Ty.denote : Ty → Type
+  | nat    => Nat
+  | fn a b => a.denote → b.denote
+
+/-!
+With HOAS, each object language binding construct is represented with a function of
+the meta language. Here is what we get if we apply that idea within an inductive definition
+of term syntax. However a naive encondig in Lean fails to meet the strict positivity restrictions
+imposed by the Lean kernel. An alternate higher-order encoding is parametric HOAS, as introduced by Washburn
+and Weirich for Haskell and tweaked by Adam Chlipala for use in Coq. The key idea is to parameterize the
+declaration by a type family `rep` standing for a "representation of variables."
+-/
+inductive Term' (rep : Ty → Type) : Ty → Type
+  | var   : rep ty → Term' rep ty
+  | const : Nat → Term' rep .nat
+  | plus  : Term' rep .nat → Term' rep .nat → Term' rep .nat
+  | lam   : (rep dom → Term' rep ran) → Term' rep (.fn dom ran)
+  | app   : Term' rep (.fn dom ran) → Term' rep dom → Term' rep ran
+  | «let» : Term' rep ty₁ → (rep ty₁ → Term' rep ty₂) → Term' rep ty₂
+
+/-!
+Lean accepts this definition because our embedded functions now merely take variables as
+arguments, instead of arbitrary terms. One might wonder whether there is an easy loophole
+to exploit here, instantiating the parameter `rep` as term itself. However, to do that, we
+would need to choose a variable representation for this nested mention of term, and so on
+through an infinite descent into term arguments.
+
+We write the final type of a closed term using polymorphic quantification over all possible
+choices of `rep` type family
+-/
+
+open Ty (nat fn)
+open Term'
+
+namespace FirstTry
+
+def Term (ty : Ty) := (rep : Ty → Type) → Term' rep ty
+
+/-!
+In the next two example, note how each is written as a function over a `rep` choice,
+such that the specific choice has no impact on the structure of the term.
+-/
+def add : Term (fn nat (fn nat nat)) := fun rep =>
+  lam fun x => lam fun y => plus (var x) (var y)
+
+def three_the_hard_way : Term nat := fun rep =>
+  app (app (add rep) (const 1)) (const 2)
+
+end FirstTry
+
+/-!
+The argument `rep` does not even appear in the function body for `add`. How can that be?
+By giving our terms expressive types, we allow Lean to infer many arguments for us. In fact,
+we do not even need to name the `rep` argument! By using Lean implicit arguments and lambdas,
+we can completely hide `rep` in these examples.
+-/
+
+def Term (ty : Ty) := {rep : Ty → Type} → Term' rep ty
+
+def add : Term (fn nat (fn nat nat)) :=
+  lam fun x => lam fun y => plus (var x) (var y)
+
+def three_the_hard_way : Term nat :=
+  app (app add (const 1)) (const 2)
+
+/-!
+It may not be at all obvious that the PHOAS representation admits the crucial computable
+operations. The key to effective deconstruction of PHOAS terms is one principle: treat
+the `rep` parameter as an unconstrained choice of which data should be annotated on each
+variable. We will begin with a simple example, that of counting how many variable nodes
+appear in a PHOAS term. This operation requires no data annotated on variables, so we
+simply annotate variables with `Unit` values. Note that, when we go under binders in the
+cases for `lam` and `let`, we must provide the data value to annotate on the new variable we
+pass beneath. For our current choice of `Unit` data, we always pass `()`.
+-/
+
+def countVars : Term' (fun _ => Unit) ty → Nat
+  | var h     => 1
+  | const n   => 0
+  | plus a b  => countVars a + countVars b
+  | app f a   => countVars f + countVars a
+  | lam b     => countVars (b ())
+  | «let» a b => countVars a + countVars (b ())
+
+/-! We can now easily prove that `add` has two variables by using reflexivity -/
+
+example : countVars add = 2 :=
+  rfl
+
+/-!
+Here is another example, translating PHOAS terms into strings giving a first-order rendering.
+To implement this translation, the key insight is to tag variables with strings, giving their names.
+The function takes as an additional input `i` which is used to create variable names for binders.
+We also use the string interpolation available in Lean. For example, `s!"x_{i}"` is expanded to
+`"x_" ++ toString i`.
+-/
+def pretty (e : Term' (fun _ => String) ty) (i : Nat := 1) : String :=
+  match e with
+  | var s     => s
+  | const n   => toString n
+  | app f a   => s!"({pretty f i} {pretty a i})"
+  | plus a b  => s!"({pretty a i} + {pretty b i})"
+  | lam f     =>
+    let x := s!"x_{i}"
+    s!"(fun {x} => {pretty (f x) (i+1)})"
+  | «let» a b =>
+    let x := s!"x_{i}"
+    s!"(let {x} := {pretty a i}; => {pretty (b x) (i+1)}"
+
+#eval pretty three_the_hard_way
+
+/-!
+It is not necessary to convert to a different representation to support many common
+operations on terms. For instance, we can implement substitution of terms for variables.
+The key insight here is to tag variables with terms, so that, on encountering a variable, we
+can simply replace it by the term in its tag. We will call this function initially on a term
+with exactly one free variable, tagged with the appropriate substitute. During recursion,
+new variables are added, but they are only tagged with their own term equivalents. Note
+that this function squash is parameterized over a specific `rep` choice.
+-/
+def squash : Term' (Term' rep) ty → Term' rep ty
+ | var e     => e
+ | const n   => const n
+ | plus a b  => plus (squash a) (squash b)
+ | lam f     => lam fun x => squash (f (.var x))
+ | app f a   => app (squash f) (squash a)
+ | «let» a b => «let» (squash a) fun x => squash (b (.var x))
+
+/-!
+To define the final substitution function over terms with single free variables, we define
+`Term1`, an analogue to Term that we defined before for closed terms.
+-/
+def Term1 (ty1 ty2 : Ty) := {rep : Ty → Type} → rep ty1 → Term' rep ty2
+
+/-!
+Substitution is defined by (1) instantiating a `Term1` to tag variables with terms and (2)
+applying the result to a specific term to be substituted. Note how the parameter `rep` of
+`squash` is instantiated: the body of `subst` is itself a polymorphic quantification over `rep`,
+standing for a variable tag choice in the output term; and we use that input to compute a
+tag choice for the input term.
+-/
+
+def subst (e : Term1 ty1 ty2) (e' : Term ty1) : Term ty2 :=
+  squash (e e')
+
+/-!
+We can view `Term1` as a term with hole. In the following example,
+`(fun x => plus (var x) (const 5))` can be viewed as the term `plus _ (const 5)` where
+the hole `_` is instantiated by `subst` with `three_the_hard_way`
+-/
+
+#eval pretty <| subst (fun x => plus (var x) (const 5)) three_the_hard_way
+
+/-!
+One further development, which may seem surprising at first,
+is that we can also implement a usual term denotation function,
+when we tag variables with their denotations.
+
+The attribute `[simp]` instructs Lean to always try to unfold `denote` applications when one applies
+the `simp` tactic. We also say this is a hint for the Lean term simplifier.
+-/
+@[simp] def denote : Term' Ty.denote ty → ty.denote
+  | var x     => x
+  | const n   => n
+  | plus a b  => denote a + denote b
+  | app f a   => denote f (denote a)
+  | lam f     => fun x => denote (f x)
+  | «let» a b => denote (b (denote a))
+
+example : denote three_the_hard_way = 3 :=
+  rfl
+
+/-!
+To summarize, the PHOAS representation has all the expressive power of more
+standard encodings (e.g., using de Bruijn indices), and a variety of translations are actually much more pleasant to
+implement than usual, thanks to the novel ability to tag variables with data.
+-/
+
+/-!
+We now define the constant folding optimization that traverses a term if replaces subterms such as
+`plus (const m) (const n)` with `const (n+m)`.
+-/
+@[simp] def constFold : Term' rep ty → Term' rep ty
+  | var x     => var x
+  | const n   => const n
+  | app f a   => app (constFold f) (constFold a)
+  | lam f     => lam fun x => constFold (f x)
+  | «let» a b => «let» (constFold a) fun x => constFold (b x)
+  | plus a b  =>
+    match constFold a, constFold b with
+    | const n, const m => const (n+m)
+    | a',      b'      => plus a' b'
+
+/-!
+The correctness of the `constFold` is proved using induction, case-analysis, and the term simplifier.
+We prove all cases but the one for `plus` using `simp [*]`. This tactic instructs the term simplifier to
+use hypotheses such as `a = b` as rewriting/simplications rules.
+We use the `split` to break the nested `match` expression in the `plus` case into two cases.
+The local variables `iha` and `ihb` are the induction hypotheses for `a` and `b`.
+The modifier `←` in a term simplifier argument instructs the term simplier to use the equation as a rewriting rule in
+the "reverse direction. That is, given `h : a = b`, `← h` instructs the term simplifier to rewrite `b` subterms to `a`.
+-/
+theorem constFold_sound (e : Term' Ty.denote ty) : denote (constFold e) = denote e := by
+  induction e with simp [*]
+  | plus a b iha ihb =>
+    split
+    next he₁ he₂ => simp [← iha, ← ihb, he₁, he₂]
+    next => simp [iha, ihb]

doc/examples/phoas.lean.md

@@ -0,0 +1,5 @@
+(this example is rendered by Alectryon in the CI)
+
+```lean
+{{#include phoas.lean}}
+```

doc/examples/tc.lean

@@ -0,0 +1,119 @@
+/-!
+# A Certified Type Checker
+
+In this example, we build a certified type checker for a simple expression
+language.
+
+Remark: this example is based on an example in the book [Certified Programming with Dependent Types](http://adam.chlipala.net/cpdt/) by Adam Chlipala.
+-/
+inductive Expr where
+  | nat  : Nat → Expr
+  | plus : Expr → Expr → Expr
+  | bool : Bool → Expr
+  | and  : Expr → Expr → Expr
+
+/-!
+We define a simple language of types using the inductive datatype `Ty`, and
+its typing rules using the inductive predicate `HasType`.
+-/
+inductive Ty where
+  | nat
+  | bool
+  deriving DecidableEq
+
+inductive HasType : Expr → Ty → Prop
+  | nat  : HasType (.nat v) .nat
+  | plus : HasType a .nat → HasType b .nat → HasType (.plus a b) .nat
+  | bool : HasType (.bool v) .bool
+  | and  : HasType a .bool → HasType b .bool → HasType (.and a b) .bool
+
+/-!
+We can easily show that if `e` has type `t₁` and type `t₂`, then `t₁` and `t₂` must be equal
+by using the the `cases` tactic. This tactic creates a new subgoal for every constructor,
+and automatically discharges unreachable cases. The tactic combinator `tac₁ <;> tac₂` applies
+`tac₂` to each subgoal produced by `tac₁`. Then, the tactic `rfl` is used to close all produced
+goals using reflexivity.
+-/
+theorem HasType.det (h₁ : HasType e t₁) (h₂ : HasType e t₂) : t₁ = t₂ := by
+  cases h₁ <;> cases h₂ <;> rfl
+
+/-!
+The inductive type `Maybe p` has two contructors: `found a h` and `unknown`.
+The former contains an element `a : α` and a proof that `a` satisfies the predicate `p`.
+The constructor `unknown` is used to encode "failure".
+-/
+
+inductive Maybe (p : α → Prop) where
+  | found : (a : α) → p a → Maybe p
+  | unknown
+
+/-!
+We define a notation for `Maybe` that is similar to the builtin notation for the Lean builtin type `Subtype`.
+-/
+notation "{{ " x " | " p " }}" => Maybe (fun x => p)
+
+/-!
+The function `Expr.typeCheck e` returns a type `ty` and a proof that `e` has type `ty`,
+or `unknown`.
+Recall that, `def Expr.typeCheck ...` in Lean is notation for `namespace Expr def typeCheck ... end Expr`.
+The term `.found .nat .nat` is sugar for `Maybe.found Ty.nat HasType.nat`. Lean can infer the namespaces using
+the expected types.
+-/
+def Expr.typeCheck (e : Expr) : {{ ty | HasType e ty }} :=
+  match e with
+  | nat ..   => .found .nat .nat
+  | bool ..  => .found .bool .bool
+  | plus a b =>
+    match a.typeCheck, b.typeCheck with
+    | .found .nat h₁, .found .nat h₂ => .found .nat (.plus h₁ h₂)
+    | _, _ => .unknown
+  | and a b =>
+    match a.typeCheck, b.typeCheck with
+    | .found .bool h₁, .found .bool h₂ => .found .bool (.and h₁ h₂)
+    | _, _ => .unknown
+
+theorem Expr.typeCheck_correct (h₁ : HasType e ty) (h₂ : e.typeCheck ≠ .unknown)
+        : e.typeCheck = .found ty h := by
+  revert h₂
+  cases typeCheck e with
+  | found ty' h' => intro; have := HasType.det h₁ h'; subst this; rfl
+  | unknown => intros; contradiction
+
+/-!
+Now, we prove that if `Expr.typeCheck e` returns `Maybe.unknown`, then forall `ty`, `HasType e ty` does not hold.
+The notation `e.typeCheck` is sugar for `Expr.typeCheck e`. Lean can infer this because we explicitly said that `e` has type `Expr`.
+The proof is by induction on `e` and case analysis. The tactic `rename_i` is used to to rename "inaccessible" variables.
+We say a variable is inaccessible if it is introduced by a tactic (e.g., `cases`) or has been shadowed by another variable introduced
+by the user. Note that the tactic `simp [typeCheck]` is applied to all goal generated by the `induction` tactic, and closes
+the cases corresponding to the constructors `Expr.nat` and `Expr.bool`.
+-/
+theorem Expr.typeCheck_complete {e : Expr} : e.typeCheck = .unknown → ¬ HasType e ty := by
+  induction e with simp [typeCheck]
+  | plus a b iha ihb =>
+    split
+    next => intros; contradiction
+    next ra rb hnp =>
+      -- Recall that `hnp` is a hypothesis generated by the `split` tactic
+      -- that asserts the previous case was not taken
+      intro h ht
+      cases ht with
+      | plus h₁ h₂ => exact hnp h₁ h₂ (typeCheck_correct h₁ (iha · h₁)) (typeCheck_correct h₂ (ihb · h₂))
+  | and a b iha ihb =>
+    split
+    next => intros; contradiction
+    next ra rb hnp =>
+      intro h ht
+      cases ht with
+      | and h₁ h₂ =>  exact hnp h₁ h₂ (typeCheck_correct h₁ (iha · h₁)) (typeCheck_correct h₂ (ihb · h₂))
+
+/-!
+Finally, we show that type checking for `e` can be decided using `Expr.typeCheck`.
+-/
+instance (e : Expr) (t : Ty) : Decidable (HasType e t) :=
+  match h' : e.typeCheck with
+  | .found t' ht' =>
+    if heq : t = t' then
+      isTrue (heq ▸ ht')
+    else
+      isFalse fun ht => heq (HasType.det ht ht')
+  | .unknown => isFalse (Expr.typeCheck_complete h')

doc/examples/tc.lean.md

@@ -0,0 +1,5 @@
+(this example is rendered by Alectryon in the CI)
+
+```lean
+{{#include tc.lean}}
+```

doc/examples/test_single.sh

@@ -0,0 +1,4 @@
+#!/usr/bin/env bash
+source ../../tests/common.sh
+
+exec_check lean -j 0 -Dlinter.all=false "$f"

doc/expressions.md

@@ -219,7 +219,7 @@ def f2 (a b c : Bool) : Bool :=
 
 #eval (1, 2)
 
-def p : Nat × Bool := (1,
+def p : Nat × Bool := (1, false)
 
 section
 variables (a b c : Nat) (p : Nat × bool)
@@ -419,33 +419,31 @@ Every computable definition in Lean is compiled to bytecode at definition time.
 
 .. code-block:: lean
 
-    #reduce (λ x, x + 3) 5
-    #eval   (λ x, x + 3) 5
+    #reduce (fun x => x + 3) 5
+    #eval   (fun x => x + 3) 5
 
-    #reduce let x := 5 in x + 3
-    #eval   let x := 5 in x + 3
+    #reduce let x := 5; x + 3
+    #eval   let x := 5; x + 3
 
     def f x := x + 3
 
     #reduce f 5
     #eval   f 5
 
-    #reduce @nat.rec (λ n, Nat) (0 : Nat)
-                     (λ n recval : Nat, recval + n + 1) (5 : Nat)
-    #eval   @nat.rec (λ n, Nat) (0 : Nat)
-                     (λ n recval : Nat, recval + n + 1) (5 : Nat)
+    #reduce @Nat.rec (λ n => Nat) (0 : Nat)
+                     (λ n recval : Nat => recval + n + 1) (5 : Nat)
 
     def g : Nat → Nat
-    | 0     := 0
-    | (n+1) := g n + n + 1
+    | 0     => 0
+    | (n+1) => g n + n + 1
 
     #reduce g 5
     #eval   g 5
 
-    #eval   g 50000
+    #eval   g 5000
 
-    example : (λ x, x + 3) 5 = 8 := rfl
-    example : (λ x, f x) = f := rfl
+    example : (fun x => x + 3) 5 = 8 := rfl
+    example : (fun x => f x) = f := rfl
     example (p : Prop) (h₁ h₂ : p) : h₁ = h₂ := rfl
 
 Note: the combination of proof irrelevance and singleton ``Prop`` elimination in ι-reduction renders the ideal version of definitional equality, as described above, undecidable. Lean's procedure for checking definitional equality is only an approximation to the ideal. It is not transitive, as illustrated by the example below. Once again, this does not compromise the consistency or soundness of Lean; it only means that Lean is more conservative in the terms it recognizes as well typed, and this does not cause problems in practice. Singleton elimination will be discussed in greater detail in [Inductive Types](inductive.md).

doc/flake.lock

@@ -0,0 +1,214 @@
+{
+  "nodes": {
+    "alectryon": {
+      "flake": false,
+      "locked": {
+        "lastModified": 1654613606,
+        "narHash": "sha256-IGCn1PzTyw8rrwmyWUiw3Jo/dyZVGkMslnHYW7YB8yk=",
+        "owner": "Kha",
+        "repo": "alectryon",
+        "rev": "c3b16f650665745e1da4ddfcc048d3bd639f71d5",
+        "type": "github"
+      },
+      "original": {
+        "owner": "Kha",
+        "ref": "typeid",
+        "repo": "alectryon",
+        "type": "github"
+      }
+    },
+    "flake-utils": {
+      "locked": {
+        "lastModified": 1644229661,
+        "narHash": "sha256-1YdnJAsNy69bpcjuoKdOYQX0YxZBiCYZo4Twxerqv7k=",
+        "owner": "numtide",
+        "repo": "flake-utils",
+        "rev": "3cecb5b042f7f209c56ffd8371b2711a290ec797",
+        "type": "github"
+      },
+      "original": {
+        "owner": "numtide",
+        "repo": "flake-utils",
+        "type": "github"
+      }
+    },
+    "lean": {
+      "inputs": {
+        "flake-utils": "flake-utils",
+        "lean-stage0": "lean-stage0",
+        "lean4-mode": "lean4-mode",
+        "nix": "nix",
+        "nixpkgs": "nixpkgs_2"
+      },
+      "locked": {
+        "lastModified": 0,
+        "narHash": "sha256-AfBkKX6Ahb9YbZke+eWLmsUk1Z9BwdJ1CpIoPY8Msx8=",
+        "path": "../.",
+        "type": "path"
+      },
+      "original": {
+        "path": "../.",
+        "type": "path"
+      }
+    },
+    "lean-stage0": {
+      "locked": {
+        "lastModified": 0,
+        "narHash": "sha256-3K/43lSW4WIHNG+HHVKCD1odS63mHuaQ4ueHyTIkcls=",
+        "owner": "leanprover",
+        "repo": "lean4",
+        "rev": "0000000000000000000000000000000000000000",
+        "type": "github"
+      },
+      "original": {
+        "owner": "leanprover",
+        "repo": "lean4",
+        "type": "github"
+      }
+    },
+    "lean4-mode": {
+      "flake": false,
+      "locked": {
+        "lastModified": 1647694750,
+        "narHash": "sha256-0rV61KhevG9IAjZDN2Ts2VS65fiUAPAezbf282u7yy8=",
+        "owner": "leanprover",
+        "repo": "lean4-mode",
+        "rev": "c016c7aeee92564836355083664c49ed57024427",
+        "type": "github"
+      },
+      "original": {
+        "owner": "leanprover",
+        "repo": "lean4-mode",
+        "type": "github"
+      }
+    },
+    "leanInk": {
+      "flake": false,
+      "locked": {
+        "lastModified": 1655643380,
+        "narHash": "sha256-sVc2LNQ0/D2DsuRGWfsP/sVsi//jTsoWMVwTeYwS/wQ=",
+        "owner": "leanprover",
+        "repo": "LeanInk",
+        "rev": "0a160d91458c1873937449a7c78d25b34b8686df",
+        "type": "github"
+      },
+      "original": {
+        "owner": "leanprover",
+        "repo": "LeanInk",
+        "type": "github"
+      }
+    },
+    "lowdown-src": {
+      "flake": false,
+      "locked": {
+        "lastModified": 1633514407,
+        "narHash": "sha256-Dw32tiMjdK9t3ETl5fzGrutQTzh2rufgZV4A/BbxuD4=",
+        "owner": "kristapsdz",
+        "repo": "lowdown",
+        "rev": "d2c2b44ff6c27b936ec27358a2653caaef8f73b8",
+        "type": "github"
+      },
+      "original": {
+        "owner": "kristapsdz",
+        "repo": "lowdown",
+        "type": "github"
+      }
+    },
+    "mdBook": {
+      "flake": false,
+      "locked": {
+        "lastModified": 1644567966,
+        "narHash": "sha256-fqdb2AUAMmi54vfa2qOF7VMFvN3rNku8/kUh1YEW86g=",
+        "owner": "leanprover",
+        "repo": "mdBook",
+        "rev": "b7a9bc48e9881087cac684d0c6c2c0a3583417e8",
+        "type": "github"
+      },
+      "original": {
+        "owner": "leanprover",
+        "repo": "mdBook",
+        "type": "github"
+      }
+    },
+    "nix": {
+      "inputs": {
+        "lowdown-src": "lowdown-src",
+        "nixpkgs": "nixpkgs",
+        "nixpkgs-regression": "nixpkgs-regression"
+      },
+      "locked": {
+        "lastModified": 1648022028,
+        "narHash": "sha256-HtwmifW6STPcym+3uJ4YavgTKTYVIoiQHg3f0wXOm+Q=",
+        "owner": "NixOS",
+        "repo": "nix",
+        "rev": "98ce1a21b7d959c5575fac566c8699e91703a9f7",
+        "type": "github"
+      },
+      "original": {
+        "owner": "NixOS",
+        "repo": "nix",
+        "type": "github"
+      }
+    },
+    "nixpkgs": {
+      "locked": {
+        "lastModified": 1632864508,
+        "narHash": "sha256-d127FIvGR41XbVRDPVvozUPQ/uRHbHwvfyKHwEt5xFM=",
+        "owner": "NixOS",
+        "repo": "nixpkgs",
+        "rev": "82891b5e2c2359d7e58d08849e4c89511ab94234",
+        "type": "github"
+      },
+      "original": {
+        "id": "nixpkgs",
+        "ref": "nixos-21.05-small",
+        "type": "indirect"
+      }
+    },
+    "nixpkgs-regression": {
+      "locked": {
+        "lastModified": 1643052045,
+        "narHash": "sha256-uGJ0VXIhWKGXxkeNnq4TvV3CIOkUJ3PAoLZ3HMzNVMw=",
+        "owner": "NixOS",
+        "repo": "nixpkgs",
+        "rev": "215d4d0fd80ca5163643b03a33fde804a29cc1e2",
+        "type": "github"
+      },
+      "original": {
+        "id": "nixpkgs",
+        "rev": "215d4d0fd80ca5163643b03a33fde804a29cc1e2",
+        "type": "indirect"
+      }
+    },
+    "nixpkgs_2": {
+      "locked": {
+        "lastModified": 1648219316,
+        "narHash": "sha256-Ctij+dOi0ZZIfX5eMhgwugfvB+WZSrvVNAyAuANOsnQ=",
+        "owner": "NixOS",
+        "repo": "nixpkgs",
+        "rev": "30d3d79b7d3607d56546dd2a6b49e156ba0ec634",
+        "type": "github"
+      },
+      "original": {
+        "owner": "NixOS",
+        "ref": "nixpkgs-unstable",
+        "repo": "nixpkgs",
+        "type": "github"
+      }
+    },
+    "root": {
+      "inputs": {
+        "alectryon": "alectryon",
+        "flake-utils": [
+          "lean",
+          "flake-utils"
+        ],
+        "lean": "lean",
+        "leanInk": "leanInk",
+        "mdBook": "mdBook"
+      }
+    }
+  },
+  "root": "root",
+  "version": 7
+}

doc/flake.nix

@@ -0,0 +1,95 @@
+{
+  description = "Lean documentation";
+
+  inputs.lean.url = path:../.;
+  inputs.flake-utils.follows = "lean/flake-utils";
+  inputs.mdBook = {
+    url = github:leanprover/mdBook;
+    flake = false;
+  };
+  inputs.alectryon = {
+    url = github:Kha/alectryon/typeid;
+    flake = false;
+  };
+  inputs.leanInk = {
+    url = github:leanprover/LeanInk;
+    flake = false;
+  };
+
+  outputs = inputs@{ self, ... }: inputs.flake-utils.lib.eachDefaultSystem (system:
+    with inputs.lean.packages.${system}; with nixpkgs;
+    let
+      doc-src = lib.sourceByRegex ../. ["doc.*" "tests(/lean(/beginEndAsMacro.lean)?)?"];
+    in {
+    packages = rec {
+      lean-mdbook = mdbook.overrideAttrs (drv: rec {
+        name = "lean-${mdbook.name}";
+        src = inputs.mdBook;
+        cargoDeps = drv.cargoDeps.overrideAttrs (_: {
+          inherit src;
+          outputHash = "sha256-5cAV8tOU3R1cPubseetURDQOzKyoo4485wD5IgeJUhQ=";
+        });
+        doCheck = false;
+      });
+      book = stdenv.mkDerivation {
+        name ="lean-doc";
+        src = doc-src;
+        buildInputs = [ lean-mdbook ];
+        buildCommand = ''
+          mkdir $out
+          # necessary for `additional-css`...?
+          cp -r --no-preserve=mode $src/doc/* .
+          # overwrite stub .lean.md files
+          cp -r ${examples}/* .
+          mdbook build -d $out
+        '';
+      };
+      # We use a separate derivation instead of `checkPhase` so we can push it but not `doc` to the binary cache
+      test = stdenv.mkDerivation {
+        name ="lean-doc-test";
+        src = doc-src;
+        buildInputs = [ lean-mdbook stage1.Lean.lean-package strace ];
+        patchPhase = ''
+          cd doc
+          patchShebangs test
+        '';
+        buildPhase = ''
+          mdbook test
+          touch $out
+        '';
+        dontInstall = true;
+      };
+      leanInk = (buildLeanPackage {
+        name = "Main";
+        src = inputs.leanInk;
+        deps = [ (buildLeanPackage {
+          name = "LeanInk";
+          src = inputs.leanInk;
+        }) ];
+        executableName = "leanInk";
+        linkFlags = ["-rdynamic"];
+      }).executable;
+      alectryon = python3Packages.buildPythonApplication {
+        name = "alectryon";
+        src = inputs.alectryon;
+        propagatedBuildInputs =
+          [ leanInk lean-all ] ++
+          # https://github.com/cpitclaudel/alectryon/blob/master/setup.cfg
+          (with python3Packages; [ pygments dominate beautifulsoup4 docutils ]);
+        doCheck = false;
+      };
+      examples = let
+        renderLean = name: file: runCommandNoCC "${name}.md" { buildInputs = [ alectryon ]; } ''
+          mkdir -p $out/examples
+          alectryon --frontend lean4+markup ${file} --backend webpage -o $out/examples/${name}.md
+        '';
+        ents = builtins.readDir ./examples;
+        inputs = lib.filterAttrs (n: t: builtins.match ".*\.lean" n != null && t == "regular") ents;
+        outputs = lib.mapAttrs (n: _: renderLean n ./examples/${n}) inputs;
+      in
+        outputs // symlinkJoin { name = "examples"; paths = lib.attrValues outputs; };
+      doc = book;
+    };
+    defaultPackage = self.packages.${system}.doc;
+  });
+}

doc/fplean.md

@@ -0,0 +1,7 @@
+Functional Programming in Lean
+=======================
+
+The goal of [this book](https://leanprover.github.io/functional_programming_in_lean/) is to be an accessible introduction to using Lean 4 as a programming language.
+It should be useful both to people who want to use Lean as a general-purpose programming language and to mathematicians who want to develop larger-scale proof automation but do not have a background in functional programming.
+It does not assume any background with functional programming, though it's probably not a good first book on programming in general.
+New content will be added once per month until it's done.

doc/functions.md

@@ -46,6 +46,25 @@ partial def g (x : Nat) (p : Nat -> Bool) : Nat :=
 In the previous example, `g x p` only terminates if there is a `y >= x` such that `p y` returns `true`.
 Of course, `g 0 (fun x => false)` never terminates.
 
+However, the use of `partial` is restricted to functions whose return type is not empty so the soundness
+of the system is not compromised.
+
+```lean,ignore
+partial def loop? : α := -- failed to compile partial definition 'loop?', failed to
+  loop?                  -- show that type is inhabited and non empty
+
+partial def loop [Inhabited α] : α := -- compiles
+  loop
+
+example : True := -- accepted
+  loop
+
+example : False :=
+  loop -- failed to synthesize instance Inhabited False
+```
+
+If we were able to partially define `loop?`, we could prove `False` with it.
+
 # Lambda expressions
 
 A lambda expression is an unnamed function.
@@ -70,28 +89,25 @@ def twice (f : Nat -> Nat) (x : Nat) : Nat :=
 
 # Syntax sugar for simple lambda expressions
 
-Simple functions can be defined using parentheses and `.` (or `·`) as a placeholder.
+Simple functions can be defined using parentheses and `·` as a placeholder.
 ```lean
-#check (. + 1)
--- fun a => a + 1
 #check (· + 1)
 -- fun a => a + 1
-#check (2 - .)
+#check (2 - ·)
 -- fun a => 2 - a
-#eval [1, 2, 3, 4, 5].foldl (. * .) 1
+#eval [1, 2, 3, 4, 5].foldl (· * ·) 1
 -- 120
 
 def h (x y z : Nat) :=
   x + y + z
 
-#check (h . 1 .)
+#check (h · 1 ·)
 -- fun a b => h a 1 b
 
 #eval [(1, 2), (3, 4), (5, 6)].map (·.1)
 -- [1, 3, 5]
 ```
-In the previous example, the term `(·.1)` is syntax sugar for `fun x => x.1`. Note that, the ASCII version `(..1)`
-is not supported because `..` is a reserved symbol.
+In the previous example, the term `(·.1)` is syntax sugar for `fun x => x.1`.
 
 # Pipelining
 
@@ -111,14 +127,14 @@ In contrast, the backward pipeline `<|` operator takes an argument and a functio
 These operators are useful for minimizing the number of parentheses.
 ```lean
 def add1Times3FilterEven (xs : List Nat) :=
-  List.filter (. % 2 == 0) (List.map (. * 3) (List.map (. + 1) xs))
+  List.filter (· % 2 == 0) (List.map (· * 3) (List.map (· + 1) xs))
 
 #eval add1Times3FilterEven [1, 2, 3, 4]
 -- [6, 12]
 
 -- Define the same function using pipes
 def add1Times3FilterEven' (xs : List Nat) :=
-  xs |> List.map (. + 1) |> List.map (. * 3) |> List.filter (. % 2 == 0)
+  xs |> List.map (· + 1) |> List.map (· * 3) |> List.filter (· % 2 == 0)
 
 #eval add1Times3FilterEven' [1, 2, 3, 4]
 -- [6, 12]
@@ -127,7 +143,7 @@ Lean also supports the operator `|>.` which combines forward pipeline `|>` opera
 ```lean
 -- Define the same function using pipes
 def add1Times3FilterEven'' (xs : List Nat) :=
-  xs.map (. + 1) |>.map (. * 3) |>.filter (. % 2 == 0)
+  xs.map (· + 1) |>.map (· * 3) |>.filter (· % 2 == 0)
 
 #eval add1Times3FilterEven'' [1, 2, 3, 4]
 -- [6, 12]

doc/inductive.md

@@ -1,3 +1,3 @@
 # Inductive Types
 
-TODO
+[Theorem Proving in Lean](https://leanprover.github.io/theorem_proving_in_lean4/inductive_types.html) has a chapter about inductive datatypes.

doc/lean3changes.md

@@ -14,7 +14,7 @@ to separate the elements of a list, and in the lambda expression itself. We now
 as an example, `fun x => x` is the identity function. One may still use the symbol `λ` as a shorthand for `fun`.
 The lambda expression notation has many new features that are not supported in Lean 3.
 
-* Pattern matching
+## Pattern matching
 
 In Lean 4, one can easily create new notation that abbreviates commonly used idioms. One of them is a
 `fun` followed by a `match`. In the following examples, we define a few functions using `fun`+`match` notation.
@@ -39,7 +39,7 @@ def Sum.str : Option Nat → String :=
 # end ex1
 ```
 
-* Implicit lambdas
+## Implicit lambdas
 
 In Lean 3 stdlib, we find many [instances](https://github.com/leanprover/lean/blob/master/library/init/category/reader.lean#L39) of the dreadful `@`+`_` idiom.
 It is often used when we the expected type is a function type with implicit arguments,
@@ -83,7 +83,7 @@ def id5 : {α : Type} → α → α :=
 # end ex2
 ```
 
-* Sugar for simple functions
+## Sugar for simple functions
 
 In Lean 3, we can create simple functions from infix operators by using parentheses. For example, `(+1)` is sugar for `fun x, x + 1`. In Lean 4, we generalize this notation using `·` As a placeholder. Here are a few examples:
 
@@ -230,11 +230,10 @@ restriction imposed by ordinary type theory. Metadefinitions may also use unsafe
 The keyword `meta` has been currently removed from Lean 4. However, we may re-introduce it in the future,
 but with a much more limited purpose: marking meta code that should not be included in the executables produced by Lean.
 
-The keywords `axiom` and `constant` are not equivalent in Lean 4. In Lean 4, `constant` is used to define
-an opaque definition. Here are two simple examples:
+The keyword `constant` has been deleted in Lean 4, and `axiom` should be used instead. In Lean 4, the new command `opaque` is used to define an opaque definition. Here are two simple examples:
 ```lean
 # namespace meta1
-constant x : Nat := 1
+opaque x : Nat := 1
 -- The following example will not type check since `x` is opaque
 -- example : x = 1 := rfl
 
@@ -244,11 +243,11 @@ constant x : Nat := 1
 
 -- When no value is provided, the elaborator tries to build one automatically for us
 -- using the `Inhabited` type class
-constant y : Nat
+opaque y : Nat
 # end meta1
 ```
 
-We can instruct Lean to use a foreign function as the implementation for any constant or definition
+We can instruct Lean to use a foreign function as the implementation for any definition
 using the attribute `@[extern "foreign_function"]`. It is the user's responsibility to ensure the
 foreign implementation is correct.
 However, a user mistake here will only impact the code generated by Lean, and
@@ -336,3 +335,34 @@ partial def f (x : Nat) : IO Unit := do
 #eval f 98
 # end partial1
 ```
+
+## Library changes
+
+These are changes to the library which may trip up Lean 3 users:
+
+- `Option` and `List` are no longer monads. Instead there is `OptionM`. This was done to avoid some performance traps. For example `o₁ <|> o₂` where `o₁ o₂ : Option α` will evaluate both `o₁` and `o₂` even if `o₁` evaluates to `some x`. This can be a problem if `o₂` requires a lot of compute to evaluate. A zulip discussion on this design choice is [here](https://leanprover.zulipchat.com/#narrow/stream/270676-lean4/topic/Option.20do.20notation.20regression.3F).
+
+
+## Style changes
+
+Coding style changes have also been made:
+
+- Term constants and variables are now `lowerCamelCase` rather than `snake_case`
+- Type constants are now `UpperCamelCase`, eg `Nat`, `List`. Type variables are still lower case greek letters. Functors are still lower case latin `(m : Type → Type) [Monad m]`.
+- When defining typeclasses, prefer not to use "has". Eg `ToString` or `Add` instead of `HasToString` or `HasAdd`.
+- Prefer `return` to `pure` in monad expressions.
+- Pipes `<|` are preferred to dollars `$` for function application.
+- Declaration bodies should always be indented:
+  ```lean
+  inductive Hello where
+    | foo
+    | bar
+
+  structure Point where
+    x : Nat
+    y : Nat
+
+  def Point.addX : Point → Point → Nat :=
+    fun { x := a, .. } { x := b, .. } => a + b
+  ```
+- In structures and typeclass definitions, prefer `where` to `:=` and don't surround fields with parentheses. (Shown in `Point` above)

doc/macro_overview.md

@@ -158,7 +158,7 @@ Output:
 [Elab.definition.body] binderterm.quot : Lean.ParserDescr :=
 Lean.ParserDescr.node `Lean.Parser.Term.quot 1024
   (Lean.ParserDescr.binary `andthen (Lean.ParserDescr.symbol "`(binderterm|")
-    (Lean.ParserDescr.binary `andthen (Lean.ParserDescr.unary `incQuotDepth (Lean.ParserDescr.cat `binderterm 0))
+    (Lean.ParserDescr.binary `andthen (Lean.ParserDescr.cat `binderterm 0)
       (Lean.ParserDescr.symbol ")")))
 -/
 ```

doc/make/index.md

@@ -46,9 +46,8 @@ For example, on an AMD Ryzen 9 `make` takes 00:04:55, whereas `make -j 10`
 takes 00:01:38.  Your results may vary depending on the speed of your hard
 drive.
 
-To install the build, see [Dev setup using
-elan](../dev/index.md#dev-setup-using-elan).
-
+You should not usually run `make install` after a successful build.
+See [Dev setup using elan](../dev/index.md#dev-setup-using-elan) on how to properly set up your editor to use the correct stage depending on the source directory.
 
 Useful CMake Configuration Settings
 -----------------------------------

doc/make/msys2.md

@@ -18,8 +18,7 @@ the stdlib.
 ## Installing dependencies
 
 [The official webpage of MSYS2][msys2] provides one-click installers.
-Once installed, you should run the "MSYS2 MinGW 64-bit shell" from the start menu.
-(The one that runs `mingw64.exe`)
+Once installed, you should run the "MSYS2 MinGW 64-bit shell" from the start menu (the one that runs `mingw64.exe`).
 Do not run "MSYS2 MSYS" instead!
 MSYS2 has a package management system, [pacman][pacman], which is used in Arch Linux.
 
@@ -74,6 +73,11 @@ The following linux command will do that:
 cp $(ldd lean.exe | cut -f3 -d' ' | grep mingw) .
 ```
 
+However, if you plan to use this build to compile lean programs
+to executable binaries using `lake build` in normal Windows command
+prompt outside of msys2 environment you will also need to add a windows
+version clang to your path.
+
 ## Trouble shooting
 
 **-bash: gcc: command not found**

doc/make/nix.md

@@ -10,7 +10,7 @@ Follow the setup in the link above; to open the Lean shell inside a Lean checkou
 $ nix-shell -A nix
 ```
 
-On top of the local and remote Nix cache, it helps to we do still rely on CCache as well to make C/C++ build steps incremental, which are atomic steps from Nix's point of view.
+On top of the local and remote Nix cache, we do still rely on CCache as well to make C/C++ build steps incremental, which are atomic steps from Nix's point of view.
 To enable CCache, add the following line to the config file mentioned in the setup:
 ```bash
 extra-sandbox-paths = /nix/var/cache/ccache
@@ -35,7 +35,7 @@ The `stage1.` part in each command is optional:
 ```bash
 nix build .#test  # run tests for stage 1
 nix build .  # build stage 1
-nix build  # dito
+nix build  # ditto
 ```
 
 ## Build Process Description
@@ -52,11 +52,14 @@ This is because modules are discovered not from a directory listing anymore but
 As in the standard Nix setup.
 After adding `src/` as an LSP workspace, it should automatically fall back to using stage 0 in there.
 
-Note that the UX of `emacs/vscode-dev` is quite different from the Make-based setup regarding the compilation of dependencies:
+Note that the UX of `{emacs,vscode}-dev` is quite different from the Make-based setup regarding the compilation of dependencies:
 there is no mutable directory incrementally filled by the build that we could point the editor at for .olean files.
 Instead, `emacs-dev` will gather the individual dependency outputs from the Nix store when checking a file -- and build them on the fly when necessary.
 However, it will only ever load changes saved to disk, not ones opened in other buffers.
 
+The absence of a mutable output directory also means that the Lean server will not automatically pick up `.ilean` metadata from newly compiled files.
+Instead, you can run `nix run .#link-ilean` to symlink the `.ilean` tree of the stdlib state at that point in time to `src/build/lib`, where the server should automatically find them.
+
 ## Other Fun Stuff to Do with Nix
 
 Open Emacs with Lean set up from an arbitrary commit (without even cloning Lean beforehand... if your Nix is new enough):
@@ -86,7 +89,7 @@ nix run .#HEAD-as-stage0.emacs-dev&
 ```
 To run `nix build` on the second stage outside of the second editor, use
 ```bash
-nix build .#stage0-from-input
+nix build .#stage0-from-input --override-input lean-stage0 .\?rev=$(git rev-parse HEAD)
 ```
 This setup will inadvertently change your `flake.lock` file, which you can revert when you are done.
 

doc/metaprogramming-arith.lean

@@ -0,0 +1,58 @@
+inductive Arith : Type
+  | add : Arith → Arith → Arith  -- e + f
+  | mul : Arith → Arith → Arith  -- e * f
+  | int : Int → Arith  -- constant
+  | symbol : String → Arith  -- variable
+
+declare_syntax_cat arith
+
+syntax num : arith  -- int for Arith.int
+syntax str : arith  -- strings for Arith.symbol
+syntax:60  arith:60 "+" arith:61 : arith  -- Arith.add
+syntax:70 arith:70 "*" arith:71 : arith  -- Arith.mul
+syntax "(" arith ")" : arith  -- parenthesized expressions
+
+-- auxiliary notation for translating `arith` into `term`
+syntax "`[Arith| " arith "]" : term
+
+macro_rules
+  | `(`[Arith| $s:str]) => `(Arith.symbol $s)
+  | `(`[Arith| $num:num]) => `(Arith.int $num)
+  | `(`[Arith| $x:arith + $y:arith]) => `(Arith.add `[Arith| $x] `[Arith| $y])
+  | `(`[Arith| $x:arith * $y:arith]) => `(Arith.mul `[Arith| $x] `[Arith| $y])
+  | `(`[Arith| ($x:arith)]) => `(`[Arith| $x])
+
+#check `[Arith| "x" * "y"]  -- mul
+-- Arith.mul (Arith.symbol "x") (Arith.symbol "y")
+
+#check `[Arith| "x" + "y"]  -- add
+-- Arith.add (Arith.symbol "x") (Arith.symbol "y")
+
+#check `[Arith| "x" + 20]  -- symbol + int
+-- Arith.add (Arith.symbol "x") (Arith.int 20)
+
+#check `[Arith| "x" + "y" * "z"]  -- precedence
+-- Arith.add (Arith.symbol "x") (Arith.mul (Arith.symbol "y") (Arith.symbol "z"))
+
+#check `[Arith| "x" * "y" + "z"]  -- precedence
+-- Arith.add (Arith.mul (Arith.symbol "x") (Arith.symbol "y")) (Arith.symbol "z")
+
+#check `[Arith| ("x" + "y") * "z"]  -- parentheses
+-- Arith.mul (Arith.add (Arith.symbol "x") (Arith.symbol "y")) (Arith.symbol "z")
+
+syntax ident : arith
+
+macro_rules
+  | `(`[Arith| $x:ident]) => `(Arith.symbol $(Lean.quote (toString x.getId)))
+
+#check `[Arith| x]  -- Arith.symbol "x"
+
+def xPlusY := `[Arith| x + y]
+#print xPlusY  -- def xPlusY : Arith := Arith.add (Arith.symbol "x") (Arith.symbol "y")
+
+syntax "<[" term "]>" : arith  -- escape for embedding terms into `Arith`
+
+macro_rules
+  | `(`[Arith| <[ $e:term ]>]) => pure e
+
+#check `[Arith| <[ xPlusY ]> + z]  -- Arith.add xPlusY (Arith.symbol "z")

doc/metaprogramming-arith.md

@@ -0,0 +1,134 @@
+# Arithmetic as an embedded domain-specific language
+
+Let's parse another classic grammar, the grammar of arithmetic expressions with
+addition, multiplication, integers, and variables.  In the process, we'll learn
+how to:
+
+- Convert identifiers such as `x` into strings within a macro.
+- add the ability to "escape" the macro context from within the macro. This is useful to interpret identifiers with their _original_ meaning (predefined values)
+  instead of their new meaning within a macro (treat as a symbol).
+
+Let's begin with the simplest thing possible. We'll define an AST, and use operators `+` and `*` to denote
+building an arithmetic AST.
+
+
+Here's the AST that we will be parsing:
+
+```lean,ignore
+{{#include metaprogramming-arith.lean:1:5}}
+```
+
+We declare a syntax category to describe the grammar that we will be parsing.
+See that we control the precedence of `+` and `*` by writing `syntax:50` for addition and `syntax:60` for multiplication,
+indicating that multiplication binds tighter than addition (higher the number, tighter the binding).
+This allows us to declare _precedence_ when defining new syntax.
+
+```lean,ignore
+{{#include metaprogramming-arith.lean:7:13}}
+```
+
+Further, if we look at `syntax:60  arith:60 "+" arith:61 : arith`, the
+precedence declarations at `arith:60 "+" arith:61` conveys that the left
+argument must have precedence at least `60` or greater, and the right argument
+must have precedence at least`61` or greater.  Note that this forces left
+associativity. To understand this, let's compare two hypothetical parses:
+
+```
+-- syntax:60  arith:60 "+" arith:61 : arith -- Arith.add
+-- a + b + c
+(a:60 + b:61):60 + c
+a + (b:60 + c:61):60
+```
+
+In the parse tree of `a + (b:60 + c:61):60`, we see that the right argument `(b + c)` is given the precedence `60`. However,
+the rule for addition expects the right argument to have a precedence of **at least** 61, as witnessed by the `arith:61` at
+the right-hand-side of `syntax:60 arith:60 "+" arith:61 : arith`. Thus, the rule `syntax:60  arith:60 "+" arith:61 : arith`
+ensures that addition is left associative.
+
+Since addition is declared arguments of precedence `60/61` and multiplication with `70/71`, this causes multiplication to bind
+tighter than addition. Once again, let's compare two hypothetical parses:
+
+```
+-- syntax:60  arith:60 "+" arith:61 : arith -- Arith.add
+-- syntax:70 arith:70 "*" arith:71 : arith -- Arith.mul
+-- a * b + c
+a * (b:60 + c:61):60
+(a:70 * b:71):70 + c
+```
+
+While parsing `a * (b + c)`, `(b + c)` is assigned a precedence `60` by the addition rule. However, multiplication expects
+the right argument to have precedence **at least** 71. Thus, this parse is invalid. In contrast, `(a * b) + c` assigns
+a precedence of `70` to `(a * b)`. This is compatible with addition which expects the left argument to have precedence
+**at least `60` ** (`70` is greater than `60`). Thus, the string `a * b + c` is parsed as `(a * b) + c`.
+For more details, please look at the [Lean manual on syntax extensions](../syntax.md#notations-and-precedence).
+
+To go from strings into `Arith`, we define a macro to
+translate the syntax category `arith` into an `Arith` inductive value that
+lives in `term`:
+
+
+```lean,ignore
+{{#include metaprogramming-arith.lean:15:16}}
+```
+
+Our macro rules perform the "obvious" translation:
+
+```lean,ignore
+{{#include metaprogramming-arith.lean:18:23}}
+```
+
+And some examples:
+
+```lean,ignore
+{{#include metaprogramming-arith.lean:25:41}}
+```
+
+Writing variables as strings, such as `"x"`  gets old; wouldn't it be so much
+prettier if we could write `x * y`, and have the macro translate this into `Arith.mul (Arith.Symbol "x") (Arith.mul "y")`?
+We can do this, and this will be our first taste of manipulating macro variables --- we'll use `x.getId` instead of directly evaluating `$x`.
+We also write a macro rule for `Arith|` that translates an identifier into
+a string, using `$(Lean.quote (toString x.getId))`:
+
+```lean,ignore
+{{#include metaprogramming-arith.lean:43:46}}
+```
+
+Let's test and see that we can now write expressions such as `x * y` directly instead of having to write `"x" * "y"`:
+
+```lean,ignore
+{{#include metaprogramming-arith.lean:48:51}}
+```
+
+We now show an unfortunate consequence of the above definitions. Suppose we want to build `(x + y) + z`.
+Since we already have defined `xPlusY` as `x + y`, perhaps we should reuse it! Let's try:
+
+```lean,ignore
+#check `[Arith| xPlusY + z]  -- Arith.add (Arith.symbol "xPlusY") (Arith.symbol "z")
+```
+
+Whoops, that didn't work! What happened? Lean treats `xPlusY` _itself_ as an identifier! So we need to add some syntax
+to be able to "escape" the `Arith|` context. Let's use the syntax `<[ $e:term ]>` to mean: evaluate `$e` as a real term,
+not an identifier. The macro looks like follows:
+
+```lean,ignore
+{{#include metaprogramming-arith.lean:53:56}}
+```
+
+Let's try our previous example:
+
+```lean,ignore
+{{#include metaprogramming-arith.lean:58:58}}
+```
+
+Perfect!
+
+In this tutorial, we expanded on the previous tutorial to parse a more
+realistic grammar with multiple levels of precedence, how to parse identifiers directly
+within a macro, and how to provide an escape from within the macro context.
+
+#### Full code listing
+
+```lean
+{{#include metaprogramming-arith.lean}}
+```
+

doc/metaprogramming.md

@@ -1,10 +0,0 @@
-# Metaprogramming
-
-Macros are a language feature that allows writing code that writes other code (metaprogramming).
-
-In Lean 4, macros are used pervasively. So much so that core language features such as `do` notation
-is implemented via macros! As a language user, macros are useful to easily
-embed domain-specific languages and to generate code at compile-time, to name a few uses.
-
-## References
-- [Hygenic Macro Expansion for Theorem Proving Languages](https://arxiv.org/abs/2001.10490)

doc/notation.md

@@ -20,7 +20,7 @@ this operator should be translated to after the arrow `=>`.
 
 The precedence is a natural number describing how "tightly" an
 operator binds to its arguments, encoding the order of operations. We
-can make this more precise by looking at the commands above unfold to:
+can make this more precise by looking at what the commands above unfold to:
 
 ```lean
 notation:65 lhs:65 " + " rhs:66 => HAdd.hAdd lhs rhs

doc/pygments.css

@@ -0,0 +1,81 @@
+/* Pygments stylesheet generated by Alectryon (style=None) */
+td.linenos .normal { color: inherit; background-color: transparent; padding-left: 5px; padding-right: 5px; }
+span.linenos { color: inherit; background-color: transparent; padding-left: 5px; padding-right: 5px; }
+td.linenos .special { color: #000000; background-color: #ffffc0; padding-left: 5px; padding-right: 5px; }
+span.linenos.special { color: #000000; background-color: #ffffc0; padding-left: 5px; padding-right: 5px; }
+.highlight .hll, .code .hll { background-color: #ffffcc }
+.highlight .c, .code .c { color: #555753; font-style: italic } /* Comment */
+.highlight .err, .code .err { color: #a40000; border: 1px solid #cc0000 } /* Error */
+.highlight .g, .code .g { color: #000000 } /* Generic */
+.highlight .k, .code .k { color: #8f5902 } /* Keyword */
+.highlight .l, .code .l { color: #2e3436 } /* Literal */
+.highlight .n, .code .n { color: #000000 } /* Name */
+.highlight .o, .code .o { color: #000000 } /* Operator */
+.highlight .x, .code .x { color: #2e3436 } /* Other */
+.highlight .p, .code .p { color: #000000 } /* Punctuation */
+.highlight .ch, .code .ch { color: #555753; font-weight: bold; font-style: italic } /* Comment.Hashbang */
+.highlight .cm, .code .cm { color: #555753; font-style: italic } /* Comment.Multiline */
+.highlight .cp, .code .cp { color: #3465a4; font-style: italic } /* Comment.Preproc */
+.highlight .cpf, .code .cpf { color: #555753; font-style: italic } /* Comment.PreprocFile */
+.highlight .c1, .code .c1 { color: #555753; font-style: italic } /* Comment.Single */
+.highlight .cs, .code .cs { color: #3465a4; font-weight: bold; font-style: italic } /* Comment.Special */
+.highlight .gd, .code .gd { color: #a40000 } /* Generic.Deleted */
+.highlight .ge, .code .ge { color: #000000; font-style: italic } /* Generic.Emph */
+.highlight .gr, .code .gr { color: #a40000 } /* Generic.Error */
+.highlight .gh, .code .gh { color: #a40000; font-weight: bold } /* Generic.Heading */
+.highlight .gi, .code .gi { color: #4e9a06 } /* Generic.Inserted */
+.highlight .go, .code .go { color: #000000; font-style: italic } /* Generic.Output */
+.highlight .gp, .code .gp { color: #8f5902 } /* Generic.Prompt */
+.highlight .gs, .code .gs { color: #000000; font-weight: bold } /* Generic.Strong */
+.highlight .gu, .code .gu { color: #000000; font-weight: bold } /* Generic.Subheading */
+.highlight .gt, .code .gt { color: #000000; font-style: italic } /* Generic.Traceback */
+.highlight .kc, .code .kc { color: #204a87; font-weight: bold } /* Keyword.Constant */
+.highlight .kd, .code .kd { color: #4e9a06; font-weight: bold } /* Keyword.Declaration */
+.highlight .kn, .code .kn { color: #4e9a06; font-weight: bold } /* Keyword.Namespace */
+.highlight .kp, .code .kp { color: #204a87 } /* Keyword.Pseudo */
+.highlight .kr, .code .kr { color: #8f5902 } /* Keyword.Reserved */
+.highlight .kt, .code .kt { color: #204a87 } /* Keyword.Type */
+.highlight .ld, .code .ld { color: #2e3436 } /* Literal.Date */
+.highlight .m, .code .m { color: #2e3436 } /* Literal.Number */
+.highlight .s, .code .s { color: #ad7fa8 } /* Literal.String */
+.highlight .na, .code .na { color: #c4a000 } /* Name.Attribute */
+.highlight .nb, .code .nb { color: #75507b } /* Name.Builtin */
+.highlight .nc, .code .nc { color: #204a87 } /* Name.Class */
+.highlight .no, .code .no { color: #ce5c00 } /* Name.Constant */
+.highlight .nd, .code .nd { color: #3465a4; font-weight: bold } /* Name.Decorator */
+.highlight .ni, .code .ni { color: #c4a000; text-decoration: underline } /* Name.Entity */
+.highlight .ne, .code .ne { color: #cc0000 } /* Name.Exception */
+.highlight .nf, .code .nf { color: #a40000 } /* Name.Function */
+.highlight .nl, .code .nl { color: #3465a4; font-weight: bold } /* Name.Label */
+.highlight .nn, .code .nn { color: #000000 } /* Name.Namespace */
+.highlight .nx, .code .nx { color: #000000 } /* Name.Other */
+.highlight .py, .code .py { color: #000000 } /* Name.Property */
+.highlight .nt, .code .nt { color: #a40000 } /* Name.Tag */
+.highlight .nv, .code .nv { color: #ce5c00 } /* Name.Variable */
+.highlight .ow, .code .ow { color: #8f5902 } /* Operator.Word */
+.highlight .w, .code .w { color: #d3d7cf; text-decoration: underline } /* Text.Whitespace */
+.highlight .mb, .code .mb { color: #2e3436 } /* Literal.Number.Bin */
+.highlight .mf, .code .mf { color: #2e3436 } /* Literal.Number.Float */
+.highlight .mh, .code .mh { color: #2e3436 } /* Literal.Number.Hex */
+.highlight .mi, .code .mi { color: #2e3436 } /* Literal.Number.Integer */
+.highlight .mo, .code .mo { color: #2e3436 } /* Literal.Number.Oct */
+.highlight .sa, .code .sa { color: #ad7fa8 } /* Literal.String.Affix */
+.highlight .sb, .code .sb { color: #ad7fa8 } /* Literal.String.Backtick */
+.highlight .sc, .code .sc { color: #ad7fa8; font-weight: bold } /* Literal.String.Char */
+.highlight .dl, .code .dl { color: #ad7fa8 } /* Literal.String.Delimiter */
+.highlight .sd, .code .sd { color: #ad7fa8 } /* Literal.String.Doc */
+.highlight .s2, .code .s2 { color: #ad7fa8 } /* Literal.String.Double */
+.highlight .se, .code .se { color: #ad7fa8; font-weight: bold } /* Literal.String.Escape */
+.highlight .sh, .code .sh { color: #ad7fa8; text-decoration: underline } /* Literal.String.Heredoc */
+.highlight .si, .code .si { color: #ce5c00 } /* Literal.String.Interpol */
+.highlight .sx, .code .sx { color: #ad7fa8 } /* Literal.String.Other */
+.highlight .sr, .code .sr { color: #ad7fa8 } /* Literal.String.Regex */
+.highlight .s1, .code .s1 { color: #ad7fa8 } /* Literal.String.Single */
+.highlight .ss, .code .ss { color: #8f5902 } /* Literal.String.Symbol */
+.highlight .bp, .code .bp { color: #5c35cc } /* Name.Builtin.Pseudo */
+.highlight .fm, .code .fm { color: #a40000 } /* Name.Function.Magic */
+.highlight .vc, .code .vc { color: #ce5c00 } /* Name.Variable.Class */
+.highlight .vg, .code .vg { color: #ce5c00; text-decoration: underline } /* Name.Variable.Global */
+.highlight .vi, .code .vi { color: #ce5c00 } /* Name.Variable.Instance */
+.highlight .vm, .code .vm { color: #ce5c00 } /* Name.Variable.Magic */
+.highlight .il, .code .il { color: #2e3436 } /* Literal.Number.Integer.Long */

doc/quickstart.md

@@ -1,36 +1,51 @@
 # Quickstart
 
 These instructions will walk you through setting up Lean using the "basic" setup and VS Code as the editor.
-See [Setup](./setup.md) for other ways and more details on setting up Lean.
+See [Setup](./setup.md) for other ways, supported platforms, and more details on setting up Lean.
+
+See quick [walkthrough demo video](https://www.youtube.com/watch?v=yZo6k48L0VY).
 
-1. Install the latest Lean 4 nightly through [`elan`](https://github.com/leanprover/elan): in any bash-compatible shell, run
-    ```sh
-    curl https://raw.githubusercontent.com/leanprover/elan/master/elan-init.sh -sSf | sh -s -- --default-toolchain leanprover/lean4:nightly
-    ```
-    On Windows, instead run in `cmd`
-    ```sh
-    curl -O --location https://raw.githubusercontent.com/leanprover/elan/master/elan-init.ps1
-    powershell -f elan-init.ps1 --default-toolchain leanprover/lean4:nightly
-    del elan-init.ps1
-    ```
-    See the [elan repo](https://github.com/leanprover/elan) for other installation options and details.
-    
 1. Install [VS Code](https://code.visualstudio.com/).
 
-1. Open VS Code and install the `lean4` extension.
+1. Launch VS Code and install the `lean4` extension.
 
     ![installing the vscode-lean4 extension](images/code-ext.png)
 
-1. Create a new file with the extension `.lean` and add the following code:
-    ```lean
-    import Leanpkg
+1. Create a new file using "File > New Text File" (`Ctrl+N`). Click the `Select a language` prompt, type in `lean4`, and hit ENTER.  You should see the following popup:
+    ![elan](images/install_elan.png)
+
+    Click the "Install Lean using Elan" button. You should see some progress output like this:
 
-    #eval Leanpkg.leanVersionString
     ```
-    You should get a syntax-highlighted file with a "Lean Infoview" on the right that tells you the installed Lean version when placing your cursor on the last line.
+    info: syncing channel updates for 'nightly'
+    info: latest update on nightly, lean version nightly-2021-12-05
+    info: downloading component 'lean'
+    ```
+
+1. While it is installing, you can paste the following Lean program into the new file:
+
+    ```lean
+    #eval Lean.versionString
+    ```
+
+    When the installation has finished, the Lean Language Server should start automatically and you should get syntax-highlighting and a "Lean Infoview" popping up on the right.  You will see the output of the `#eval` statement when
+    you place your cursor at the end of the statement.
 
     ![successful setup](images/code-success.png)
 
-1. You are set up! Try opening a Lean folder containing a package file `leanpkg.toml`. You can create your own packages using `leanpkg init` on the command line.
-   Packages **have** to be opened using "File > Open Folder..." for imports to work.
-   Saved changes are visible in other files after running "Lean 4: Refresh File Dependencies" (`Ctrl+Shift+X`).
+You are set up!
+
+## Create a Lean Project
+
+You can now create a Lean project in a new folder. Run `lake init foo` from "View > Terminal" to create a package, followed by `lake build` to get an executable version of your Lean program.
+On Linux/macOS, you first have to follow the instructions printed by the Lean installation or log out and in again for the Lean executables to be available in you terminal.
+
+Note: Packages **have** to be opened using "File > Open Folder..." for imports to work.
+Saved changes are visible in other files after running "Lean 4: Refresh File Dependencies" (`Ctrl+Shift+X`).
+
+## Troubleshooting
+
+**The InfoView says "Waiting for Lean server to start..." forever.**
+
+Check that the VS Code Terminal is not showing some installation errors from `elan`.
+If that doesn't work, try also running the VS Code command `Developer: Reload Window`.

doc/setup.md

@@ -1,3 +1,29 @@
+# Supported Platforms
+
+### Tier 1
+
+Platforms built & tested by our CI, available as nightly & stable releases via elan (see above)
+
+* x86-64 Linux with glibc 2.27+
+* x86-64 macOS 10.15+
+* x86-64 Windows 10+
+
+### Tier 2
+
+Platforms cross-compiled but not tested by our CI, available as nightly & stable releases
+
+Releases may be silently broken due to the lack of automated testing.
+Issue reports and fixes are welcome.
+
+* aarch64 Linux with glibc 2.27+
+* aarch64 (M1) macOS
+
+<!--
+### Tier 3
+
+Platforms that are known to work from manual testing, but do not come with CI or official releases
+-->
+
 # Setting Up Lean
 
 There are currently two ways to set up a Lean 4 development environment:
@@ -21,25 +47,29 @@ $ elan default leanprover/lean4:nightly
 $ elan override set leanprover/lean4:stable
 ```
 
-### `leanpkg`
+### `lake`
 
-Lean 4 comes with a basic package manager, `leanpkg`.
-Use `leanpkg init Foo` to initialize a Lean package `Foo` in the current directory, and `leanpkg build` to typecheck and build it as well as all its dependencies; call `leanpkg help` to learn about further commands.
-The general directory structure of a package `Foo` is
+Lean 4 comes with a package manager named `lake`.
+Use `lake init foo` to initialize a Lean package `foo` in the current directory, and `lake build` to typecheck and build it as well as all its dependencies. Use `lake help` to learn about further commands.
+The general directory structure of a package `foo` is
 ```sh
-leanpkg.toml  # package configuration
-Foo.lean  # main file, import via `import Foo`
+lakefile.lean  # package configuration
+lean-toolchain # specifies the lean version to use
+Foo.lean       # main file, import via `import Foo`
 Foo/
-  A.lean  # further files, import via e.g. `import Foo.A`
-  A/...   # further nesting
-build/  # `leanpkg` output directory
+  A.lean       # further files, import via e.g. `import Foo.A`
+  A/...        # further nesting
+build/         # `lake` build output directory
+```
+
+After running `lake build` you will see a binary named `./build/bin/foo` and when you run it you should see the output:
+```
+Hello, world!
 ```
-Note however that producing native binaries and libraries (`leanpkg build bin/lb`) currently depends on `make` and an external C compiler for recursive compilation.
-It has been tested on Windows by installing these tools using [MSYS2](https://www.msys2.org/), but [MinGW](http://www.mingw.org/) or WSL should work, too.
 
 ### Editing
 
-Lean implements the [Language Server Protocol](https://microsoft.github.io/language-server-protocol/) that can be used for interactive development in [Emacs](https://github.com/leanprover/lean4/tree/master/lean4-mode/README.md), [VS Code](https://github.com/leanprover-community/vscode-lean4), and possibly other editors.
+Lean implements the [Language Server Protocol](https://microsoft.github.io/language-server-protocol/) that can be used for interactive development in [Emacs](https://github.com/leanprover/lean4-mode), [VS Code](https://github.com/leanprover-community/vscode-lean4), and possibly other editors.
 
 Changes must be saved to be visible in other files, which must then be invalidated using an editor command (see links above).
 
@@ -77,7 +107,7 @@ From a Lean shell, run
 $ nix flake new mypkg -t github:leanprover/lean4
 ```
 to create a new Lean package in directory `mypkg` using the latest commit of Lean 4.
-Such packages follow the same directory layout as described in the basic setup above, except for a `leanpkg.toml`/`lakefile.lean` replaced by a `flake.nix` file set up so you can run Nix commands on it, for example:
+Such packages follow the same directory layout as described in the basic setup above, except for a `lakefile.lean` replaced by a `flake.nix` file set up so you can run Nix commands on it, for example:
 ```bash
 $ nix build  # build package and all dependencies
 $ nix build .#executable  # compile `main` definition into executable (after you've added one)
@@ -112,5 +142,5 @@ nix-collect-garbage
 ```
 This will remove everything not reachable from "GC roots" such as the `./result` symlink created by `nix build`.
 
-Note that the package information in `flake.nix` is currently completely independent from `leanpkg.toml` used in the basic setup.
+Note that the package information in `flake.nix` is currently completely independent from `lakefile.lean` used in the basic setup.
 Unifying the two formats is TBD.

doc/struct.md

@@ -217,4 +217,11 @@ def msg2 : MessageExt where
 
 ## Updating structure fields
 
-TODO
+Structure fields can be updated using `{ <struct-val> with <field> := <new-value>, ... }`:
+
+```lean
+# structure Point (α : Type u) where
+#  x : α
+#  y : α
+def incrementX (p : Point Nat) : Point Nat := { p with x := p.x + 1 }
+```

doc/syntax.md

@@ -1,14 +1,15 @@
 # Syntax Extensions
 
-[Lean's syntax](lexical_structure.md) can be extended and customized
-by users at every level, ranging from basic "mixfix" notations to
-custom elaborators. In fact, all builtin syntax is parsed and
+Lean's syntax can be extended and customized
+by users at every level, ranging from [basic "mixfix" notations](./notation.md)
+over [macro transformers](./macro_overview.md) to
+[type-aware elaborators](./elaborators.md). In fact, all builtin syntax is parsed and
 processed using the same mechanisms and APIs open to users. In this
 section, we will describe and explain the various extension points.
 Significant syntax extensions already builtin into Lean such as the
 [`do` notation](./do.md) are described in subsections.
 
-While [introducing new notations](./notation.md) is a relatively rare feature in
+While introducing new syntax is a relatively rare feature in
 programming languages and sometimes even frowned upon because of its
 potential to obscure code, it is an invaluable tool in formalization
 for expressing established conventions and notations of the respective
@@ -17,14 +18,3 @@ to factor out common boilerplate code into (well-behaved) macros and
 to embed entire custom domain specific languages (DSLs) to textually
 encode subproblems efficiently and readably can be of great benefit to
 both programmers and proof engineers alike.
-
-## Syntax and Macros
-
-## Elaborators
-
-TODO. See [Lean Together 2021: Metaprogramming in Lean
-4](https://youtu.be/hxQ1vvhYN_U) for an overview as well [the
-continuation](https://youtu.be/hxQ1vvhYN_U) about tactic programming.
-For more information on antiquotations, see also §4.1 of [Beyond
-Notations: Hygienic Macro Expansion for Theorem Proving
-Languages](https://arxiv.org/pdf/2001.10490.pdf#page=11).

doc/syntax_example.lean

@@ -0,0 +1,23 @@
+inductive Dyck : Type where
+  | round : Dyck → Dyck  -- ( <inner> )
+  | curly : Dyck → Dyck  -- { <inner> }
+  | leaf : Dyck
+
+-- declare Dyck grammar parse trees
+declare_syntax_cat brack
+syntax "(" brack ")" : brack
+syntax "{" brack "}" : brack
+syntax "end" : brack
+
+-- notation for translating `brack` into `term`
+syntax "`[Dyck| " brack "]" : term
+
+-- rules to translate Dyck grammar into inductive value of type Dyck
+macro_rules
+  | `(`[Dyck| end])    => `(Dyck.leaf)
+  | `(`[Dyck| ($b)]) => `(Dyck.round `[Dyck| $b])  -- recurse
+  | `(`[Dyck| {$b}]) => `(Dyck.curly `[Dyck| $b])  -- recurse
+
+-- tests
+#check `[Dyck| end]      -- Dyck.leaf
+#check `[Dyck| {(end)}]  -- Dyck.curl (Dyck.round Dyck.leaf)

doc/syntax_example.md

@@ -4,19 +4,19 @@ Let's look at how to use macros to extend the Lean 4 parser and embed a language
 This language accepts strings given by the [BNF grammar](https://en.wikipedia.org/wiki/Backus%E2%80%93Naur_form)
 
 ```
-Dyck :=
+Dyck ::=
   "(" Dyck ")"
-  | "{" Dyck '}'
-  | "End"
+  | "{" Dyck "}"
+  | end
 ```
 
 We begin by defining an inductive data type of the grammar we wish to parse:
 
 ```lean,ignore
-inductive Dyck: Type :=
-   | Round : Dyck -> Dyck -- ( <inner> )
-   | Flower : Dyck -> Dyck -- { <inner> }
-   | End : Dyck
+inductive Dyck : Type where
+  | round : Dyck → Dyck  -- ( <inner> )
+  | curly : Dyck → Dyck  -- { <inner> }
+  | leaf : Dyck
 ```
 
 We begin by declaring a _syntax category_ using the `declare_syntax_cat <category>` command.
@@ -29,10 +29,10 @@ declare_syntax_cat brack
 Next, we specify the grammar using the `syntax <parse rule>` command:
 
 ```lean,ignore
-syntax "End" : brack
+syntax "end" : brack
 ```
 
-The above means that the string "End" lives in syntax category `brack`.
+The above means that the token "end" lives in syntax category `brack`.
 
 Similarly, we declare the rules `"(" Dyck ")"` and `"{" Dyck "}"` using the rules:
 
@@ -42,44 +42,32 @@ syntax "{" brack "}" : brack
 ```
 
 Finally, we need a way to build _Lean 4 terms_ from this grammar -- that is, we must translate out of this
-grammar into a `Dyck` value, which is a Lean 4 term. For this, we create a piece of syntax,
-called `fromBrack% brack : term`, which receives a `brack` and produces a `term`.
+grammar into a `Dyck` value, which is a Lean 4 term. For this, we create a new kind of "quotation" that
+consumes syntax in `brack` and produces a `term`.
 
 ```lean,ignore
--- auxiliary notation for translating `brack` into `term`
-syntax "fromBrack% " brack : term
+syntax "`[Dyck| " brack "]" : term
 ```
 
-To specify the transformation rules, we use `macro_rules` to declare how the syntax `fromBrack% <brack>`
+To specify the transformation rules, we use `macro_rules` to declare how the syntax `` `[Dyck| <brack>] ``
 produces terms. This is written using a pattern-matching style syntax, where the left-hand side
-declares the pattern to be matched, and the right-hand side declares the production. Syntax placeholders (antiquotations)
+declares the syntax pattern to be matched, and the right-hand side declares the production. Syntax placeholders (antiquotations)
 are introduced via the `$<var-name>` syntax. The right-hand side is
 an arbitrary Lean term that we are producing.
 
 ```lean,ignore
 macro_rules
-  | `(fromBrack% End) => `(Dyck.End)
-  | `(fromBrack% ( $b )) => `(Dyck.Round (fromBrack% $b)) -- recurse
-  | `(fromBrack% { $b }) => `(Dyck.Flower (fromBrack% $b)) -- recurse
+  | `(`[Dyck| end])    => `(Dyck.leaf)
+  | `(`[Dyck| ($b)]) => `(Dyck.round `[Dyck| $b])  -- recurse
+  | `(`[Dyck| {$b}]) => `(Dyck.curly `[Dyck| $b])  -- recurse
 ```
 
 
 ```lean,ignore
-def bar : Dyck := fromBrack% End
-#print bar
-/-
-def bar : Dyck :=
-Dyck.End
--/
-
-def foo : Dyck := fromBrack% {(End)}
-#print foo
-/-
-Dyck.Flower (Dyck.Round (Dyck.End))
--/
+#check `[Dyck| end]      -- Dyck.leaf
+#check `[Dyck| {(end)}]  -- Dyck.curl (Dyck.round Dyck.leaf)
 ```
 
-
 In summary, we've seen:
 - How to declare a syntax category for the Dyck grammar.
 - How to specify parse trees of this grammar using `syntax`
@@ -87,41 +75,6 @@ In summary, we've seen:
 
 The full program listing is given below:
 
-
 ```lean
-inductive Dyck: Type :=
-   | Round : Dyck -> Dyck -- ( <inner> )
-   | Flower : Dyck -> Dyck -- { <inner> }
-   | End : Dyck
-
-
--- | declare Dyck grammar parse trees
-declare_syntax_cat brack
-syntax "End" : brack
-syntax "(" brack ")" : brack
-syntax "{" brack "}" : brack
-
-
--- auxiliary notation for translating `brack` into `term`
-syntax "fromBrack% " brack : term
-
--- | rules to translate dyck grammar into inductive value of type Dyck.
-macro_rules
-  | `(fromBrack% End) => `(Dyck.End)
-  | `(fromBrack% ( $b )) => `(Dyck.Round (fromBrack% $b)) -- recurse
-  | `(fromBrack% { $b }) => `(Dyck.Flower (fromBrack% $b)) -- recurse
-
--- | tests
-def bar : Dyck := fromBrack% End
-#print bar
-/-
-def bar : Dyck :=
-Dyck.End
--/
-
-def foo : Dyck := fromBrack% {(End)}
-#print foo
-/-
-Dyck.Flower (Dyck.Round Dyck.End)
--/
+{{#include syntax_example.lean}}
 ```

doc/syntax_examples.md

@@ -0,0 +1,4 @@
+# Syntax Metaprogramming Examples
+
+- [Balanced Parentheses](./syntax_example.md)
+- [Arithmetic DSL](./metaprogramming-arith.md)

doc/syntax_highlight_in_latex.md

@@ -10,6 +10,7 @@ Save [`lstlean.tex`](https://raw.githubusercontent.com/leanprover/lean4/master/d
 \usepackage[T1]{fontenc}
 \usepackage[utf8]{inputenc}
 \usepackage{listings}
+\usepackage{amssymb}
 
 \usepackage{color}
 \definecolor{keywordcolor}{rgb}{0.7, 0.1, 0.1}   % red

doc/tactics.md

@@ -193,6 +193,50 @@ TODO
 
 TODO
 
+## Split
+
+The `split` tactic can be used to split the cases of an if-then-else or
+match into new subgoals, which can then be discharged individually.
+
+```lean
+def addMoreIfOdd (n : Nat) := if n % 2 = 0 then n + 1 else n + 2
+
+/- Examine each branch of the conditional to show that the result
+   is always positive -/
+example (n : Nat) : 0 < addMoreIfOdd n := by
+  simp only [addMoreIfOdd]
+  split
+  next => exact Nat.zero_lt_succ _
+  next => exact Nat.zero_lt_succ _
+```
+
+```lean
+def binToChar (n : Nat) : Option Char :=
+  match n with
+  | 0 => some '0'
+  | 1 => some '1'
+  | _ => none
+
+example (n : Nat) : (binToChar n).isSome -> n = 0 ∨ n = 1 := by
+  simp only [binToChar]
+  split
+  next => exact fun _ => Or.inl rfl
+  next => exact fun _ => Or.inr rfl
+  next => intro h; cases h
+
+/- Hypotheses about previous cases can be accessesd by assigning them a
+   name, like `ne_zero` below. Information about the matched term can also
+   be preserved using the `generalizing` tactic: -/
+example (n : Nat) : (n = 0) -> (binToChar n = some '0') := by
+  simp only [binToChar]
+  split
+  case h_1 => intro _; rfl
+  case h_2 => intro h; cases h
+  /- Here, we can introduce `n ≠ 0` and `n ≠ 1` this case assumes
+     neither of the previous cases matched. -/
+  case h_3 ne_zero _  => intro eq_zero; exact absurd eq_zero ne_zero
+```
+
 ## Dependent pattern matching
 
 The `match-with` expression implements dependent pattern matching. You can use it to create concise proofs.
@@ -202,7 +246,7 @@ inductive Mem : α → List α → Prop where
   | head (a : α) (as : List α)   : Mem a (a::as)
   | tail (a b : α) (bs : List α) : Mem a bs → Mem a (b::bs)
 
-infix:50 "∈" => Mem
+infix:50 (priority := high) "∈" => Mem
 
 theorem mem_split {a : α} {as : List α} (h : a ∈ as) : ∃ s t, as = s ++ a :: t :=
   match a, as, h with
@@ -219,7 +263,7 @@ Here is a similar proof using the tactic DSL.
 # inductive Mem : α → List α → Prop where
 #  | head (a : α) (as : List α)   : Mem a (a::as)
 #  | tail (a b : α) (bs : List α) : Mem a bs → Mem a (b::bs)
-# infix:50 "∈" => Mem
+# infix:50 (priority := high) "∈" => Mem
 theorem mem_split {a : α} {as : List α} (h : a ∈ as) : ∃ s t, as = s ++ a :: t := by
   match a, as, h with
   | _, _, Mem.head a bs     => exists []; exists bs; rfl
@@ -237,7 +281,7 @@ Here is a similar proof that uses the `induction` tactic instead of recursion.
 # inductive Mem : α → List α → Prop where
 #  | head (a : α) (as : List α)   : Mem a (a::as)
 #  | tail (a b : α) (bs : List α) : Mem a bs → Mem a (b::bs)
-# infix:50 "∈" => Mem
+# infix:50 (priority := high) "∈" => Mem
 theorem mem_split {a : α} {as : List α} (h : a ∈ as) : ∃ s t, as = s ++ a :: t := by
   induction as with
   | nil          => cases h
@@ -258,7 +302,7 @@ discriminant. Later, we show how to create more complex automation using macros.
 # inductive Mem : α → List α → Prop where
 #  | head (a : α) (as : List α)   : Mem a (a::as)
 #  | tail (a b : α) (bs : List α) : Mem a bs → Mem a (b::bs)
-# infix:50 "∈" => Mem
+# infix:50 (priority := high) "∈" => Mem
 macro "obtain " p:term " from " d:term : tactic =>
   `(tactic| match $d:term with | $p:term => ?_)
 
@@ -313,13 +357,13 @@ You can use `let rec` to write local recursive functions. We lifted it to the ta
 and you can use it to create proofs by induction.
 
 ```lean
-theorem length_replicate {α} (n : Nat) (a : α) : (List.replicate n a).length = n := by
+theorem length_replicateTR {α} (n : Nat) (a : α) : (List.replicateTR n a).length = n := by
   let rec aux (n : Nat) (as : List α)
-      : (List.replicate.loop a n as).length = n + as.length := by
+      : (List.replicateTR.loop a n as).length = n + as.length := by
     match n with
     | 0   => rw [Nat.zero_add]; rfl
     | n+1 =>
-      show List.length (List.replicate.loop a n (a::as)) = Nat.succ n + as.length
+      show List.length (List.replicateTR.loop a n (a::as)) = Nat.succ n + as.length
       rw [aux n, List.length_cons, Nat.add_succ, Nat.succ_add]
   exact aux n []
 ```
@@ -328,14 +372,14 @@ You can also introduce auxiliary recursive declarations using `where` clause aft
 Lean converts them into a `let rec`.
 
 ```lean
-theorem length_replicate {α} (n : Nat) (a : α) : (List.replicate n a).length = n :=
+theorem length_replicateTR {α} (n : Nat) (a : α) : (List.replicateTR n a).length = n :=
   loop n []
 where
-  loop n as : (List.replicate.loop a n as).length = n + as.length := by
+  loop n as : (List.replicateTR.loop a n as).length = n + as.length := by
     match n with
     | 0   => rw [Nat.zero_add]; rfl
     | n+1 =>
-      show List.length (List.replicate.loop a n (a::as)) = Nat.succ n + as.length
+      show List.length (List.replicateTR.loop a n (a::as)) = Nat.succ n + as.length
       rw [loop n, List.length_cons, Nat.add_succ, Nat.succ_add]
 ```
 

doc/thunk.md

@@ -54,7 +54,7 @@ def g (c : Bool) (x : Nat) : Nat :=
 ```
 In the following example, we use the macro `dbg_trace` to demonstrate
 that the Lean runtime caches the value computed by a `Thunk`.
-We remark that the macro `dbg_trace` should be use for debugging purposes
+We remark that the macro `dbg_trace` should be used for debugging purposes
 only.
 ```lean
 def add1 (x : Nat) : Nat :=

doc/tour.md

@@ -77,9 +77,9 @@ theorem twiceAdd2 (a : Nat) : twice (fun x => x + 2) a = a + 4 :=
   -- until they are identical.
   rfl
 
--- `(. + 2)` is syntax sugar for `(fun x => x + 2)`. The parentheses + `.` notation
+-- `(· + 2)` is syntax sugar for `(fun x => x + 2)`. The parentheses + `·` notation
 -- is useful for defining simple anonymous functions.
-#eval twice (. + 2) 10
+#eval twice (· + 2) 10
 
 -- Enumerated types are a special case of inductive types in Lean,
 -- which we will learn about later.

doc/tpil.md

@@ -0,0 +1,5 @@
+Theorem Proving in Lean
+=======================
+
+We strongly encourage you to read the book [Theorem Proving in Lean](https://leanprover.github.io/theorem_proving_in_lean4/title_page.html).
+Many Lean users consider it to be the Lean Bible.

doc/tutorial/metaprogramming-arith.md

@@ -1,245 +0,0 @@
-## Arithmetic as an embedded domain-specific language
-
-Let's parse another classic grammar, the grammar of arithmetic expressions with
-addition, multiplication, integers, and variables.  In the process, we'll learn
-how to:
-
-- Convert identifiers such as `x` into strings within a macro.
-- add the ability to "escape" the macro context from within the macro. This is useful to interpret identifiers with their _original_ meaning (predefined values)
-  instead of their new meaning within a macro (treat as a symbol).
-
-Let's begin with the simplest thing possible. We'll define an AST, and use operators `+` and `*` to denote
-building an arithmetic AST.
-
-
-Here's the AST that we will be parsing:
-
-```lean,ignore
--- example on parsing arith language via macros
-inductive Arith : Type where
-  | add : Arith → Arith → Arith -- e + f
-  | mul : Arith → Arith → Arith -- e * f
-  | int : Int → Arith -- constant
-  | symbol : String → Arith -- variable
-```
-
-We declare a syntax category to describe the grammar that we will be parsing.
-See that we control the precedence of `+` and `*` by writing `syntax:50` for addition and `syntax:60` for multiplication,
-indicating that multiplication binds tighter than addition (higher the number, tighter the binding).
-This allows us to declare _precedence_ when defining new syntax.
-
-```lean,ignore
-declare_syntax_cat arith
-syntax num : arith -- int for Arith.int
-syntax str : arith -- strings for Arith.symbol
-syntax:60  arith:60 "+" arith:61 : arith -- Arith.add
-syntax:70 arith:70 "*" arith:71 : arith -- Arith.mul
-syntax "(" arith ")" : arith -- bracketed expressions
-```
-
-Further, if we look at `syntax:60  arith:60 "+" arith:61 : arith`, the
-precedence declarations at `arith:60 "+" arith:61` conveys that the left
-argument must have precedence at least `60` or greater, and the right argument
-must have precedence at least`61` or greater.  Note that this forces left
-associativity. To understand this, let's compare two hypothetical parses:
-
-```
--- syntax:60  arith:60 "+" arith:61 : arith -- Arith.add
--- a + b + c
-(a:60 + b:61):60 + c
-a + (b:60 + c:61):60
-```
-
-In the parse tree of `a + (b:60 + c:61):60`, we see that the right argument `(b + c)` is given the precedence `60`. However,
-the rule for addition expects the right argument to have a precedence of **at least** 61, as witnessed by the `arith:61` at
-the right-hand-side of `syntax:60 arith:60 "+" arith:61 : arith`. Thus, the rule `syntax:60  arith:60 "+" arith:61 : arith`
-ensures that addition is left associative.
-
-Since addition is declared arguments of precedence `60/61` and multiplication with `70/71`, this causes multiplication to bind
-tighter than addition. Once again, let's compare two hypothetical parses:
-
-```
--- syntax:60  arith:60 "+" arith:61 : arith -- Arith.add
--- syntax:70 arith:70 "*" arith:71 : arith -- Arith.mul
--- a * b + c
-a * (b:60 + c:61):60
-(a:70 * b:71):70 + c
-```
-
-While parsing `a * (b + c)`, `(b + c)` is assigned a precedence `60` by the addition rule. However, multiplication expects
-the right argument to have precedence **at least** 71. Thus, this parse is invalid. In contrast, `(a * b) + c` assigns
-a precedence of `70` to `(a * b)`. This is compatible with addition which expects the left argument to have precedence
-**at least `60` ** (`70` is greater than `60`). Thus, the string `a * b + c` is parsed as `(a * b) + c`.
-For more details, please look at the [Lean manual on syntax extensions](../syntax.md#notations-and-precedence).
-
-
-
-
-To go from strings into `Arith`, We define a macro to
-translate the syntax category `arith` into an `Arith` inductive value that
-lives in `term`:
-
-
-```lean,ignore
--- auxiliary notation for translating `arith` into `term`
-syntax "`[Arith| " arith "]" : term
-```
-
-Our macro rules perform the "obvious" translation:
-
-```lean,ignore
-macro_rules
-  | `(`[Arith| $s:strLit ]) => `(Arith.symbol $s)
-  | `(`[Arith| $num:numLit ]) => `(Arith.int $num)
-  | `(`[Arith| $x:arith + $y:arith ]) => `(Arith.add `[Arith| $x] `[Arith| $y])
-  | `(`[Arith| $x:arith * $y:arith ]) => `(Arith.mul `[Arith| $x] `[Arith| $y])
-  | `(`[Arith| ($x:arith) ]) => `(`[Arith| $x ])
-```
-And some examples:
-
-```lean,ignore
-#check `[Arith| "x" * "y"] -- Arith.mul (Arith.symbol "x") (Arith.symbol "y") : Arith
-
-#check `[Arith| "x" + "y"] -- add
--- Arith.add (Arith.symbol "x") (Arith.symbol "y") 
-
-#check  `[Arith| "x" + 20] -- symbol + int
--- Arith.add (Arith.symbol "x") (Arith.int 20)
-
-
-#check `[Arith| "x" + "y" * "z" ] -- precedence
-Arith.add (Arith.symbol "x") (Arith.mul (Arith.symbol "y") (Arith.symbol "z"))
--- 
-#check `[Arith| "x" * "y" + "z"] -- precedence
--- Arith.add (Arith.mul (Arith.symbol "x") (Arith.symbol "y")) (Arith.symbol "z")
-
-
-#check `[Arith| ("x" + "y") * "z"] -- brackets
--- Arith.mul (Arith.add (Arith.symbol "x") (Arith.symbol "y")) (Arith.symbol "z")
-```
-
-
-Writing variables as strings, such as `"x"`  gets old; Wouldn't it be so much
-prettier if we could write `x * y`, and have the macro translate this into `Arith.mul (Arith.Symbol "x") (Arith.mul "y")`?
-We can do this, and this will be our first taste of manipulating macro variables --- we'll use `x.getId` instead of directly evaluating `$x`.
-We also write a macro rule for `Arith|` that translates an identifier into
-a string, using `$(Lean.quote (toString x.getId))`.  (TODO: explain what
-`Lean.quote` does):
-
-```lean,ignore
-syntax ident : arith
-
-macro_rules
-  | `(`[Arith| $x:ident]) => `(Arith.symbol $(Lean.quote (toString x.getId)))
-```
-
-
-Let's test and see that we can now write expressions such as `x * y` directly instead of having to write `"x" * "y"`:
-
-```lean,ignore
-#check `[Arith| x ] -- Arith.symbol "x"
-
-#check `[Arith| x + y] -- Arith.add (Arith.symbol "x") (Arith.symbol "y")
-```
-
-We now show an unfortunate consequence of the above definitions. Suppose we want to build `(x + y) + z)`.
-Since we already have defined `x_plus_y` as `x + y`, perhaps we should reuse it! Let's try:
-
-```lean,ignore
-#check `[Arith| x_plus_y + z] --Arith.add (Arith.symbol "x_plus_y") (Arith.symbol "z")
-```
-
-Whoops, that didn't work! What happened? Lean treats `x_plus_y` _itself_ as an identifier! So we need to add some syntax
-to be able to "escape" the `Arith|` context. Let's use the syntax `<[ $e:term ]>` to mean: evaluate `$e` as a real term,
-not an identifier. The macro looks like follows:
-
-```lean,ignore
-syntax "<[" term "]>" : arith -- escape for embedding terms into `Arith`
-macro_rules
-  | `(`[Arith| <[ $e:term ]> ]) => e
-
-```
-
-Let's try our previous example:
-
-```lean,ignore
-#check `[Arith| <[ x_plus_y ]>] -- x_plus_y
-```
-
-Perfect!
-
-In this tutorial, we expanded on the previous tutorial to parse a more
-realistic grammar with multiple levels of precedence, how to parse identifiers directly
-within a macro, and how to provide an escape from within the macro context.
-
-#### Full code listing
-
-```lean
--- example on parsing arith language via macros
-inductive Arith: Type
-  | add : Arith → Arith → Arith -- e + f
-  | mul : Arith → Arith → Arith -- e * f
-  | int : Int → Arith -- constant
-  | symbol : String → Arith -- variable
-
-declare_syntax_cat arith
-
-syntax num : arith -- int for Arith.int
-syntax str : arith -- strings for Arith.symbol
-syntax:60  arith:60 "+" arith:61 : arith -- Arith.add
-syntax:70 arith:70 "*" arith:71 : arith -- Arith.mul
-syntax "(" arith ")" : arith -- bracketed expressions
-
--- auxiliary notation for translating `arith` into `term`
-syntax "`[Arith| " arith "]" : term
-
-macro_rules
-  | `(`[Arith| $s:strLit ]) => `(Arith.symbol $s )
-  | `(`[Arith| $num:numLit ]) => `(Arith.int $num )
-  | `(`[Arith| $x:arith + $y:arith ]) => `(Arith.add `[Arith| $x] `[Arith| $y] )
-  | `(`[Arith| $x:arith * $y:arith ]) => `(Arith.mul `[Arith| $x] `[Arith| $y] )
-  | `(`[Arith| ($x:arith) ]) => `(`[Arith| $x ])
-
-def foo := 
-#check `[Arith| "x" * "y" ] -- mul
--- Arith.mul (Arith.symbol "x") (Arith.symbol "y")
-
-def bar := 
-#check `[Arith| "x" + "y"] -- add
--- Arith.add (Arith.symbol "x") (Arith.symbol "y")
-
-def baz := 
-#check `[Arith| "x" + 20] -- symbol + int
--- Arith.add (Arith.symbol "x") (Arith.int 20)
-
-def quux_left := 
-#check `[Arith| "x" + "y" * "z" ] -- precedence
--- Arith.add (Arith.symbol "x") (Arith.mul (Arith.symbol "y") (Arith.symbol "z"))
-
-def quux_right := 
-#check `[Arith| "x" * "y" + "z"] -- precedence
--- Arith.add (Arith.mul (Arith.symbol "x") (Arith.symbol "y")) (Arith.symbol "z")
-
-
-def quuz := 
-#check `[Arith| ("x" + "y") * "z"] -- brackets
--- Arith.mul (Arith.add (Arith.symbol "x") (Arith.symbol "y")) (Arith.symbol "z")
-
-syntax ident : arith
-
-macro_rules
-  | `(`[Arith| $x:ident]) => `(Arith.symbol $(Lean.quote (toString x.getId)))
-
-#check `[Arith| x ] -- Arith.symbol "x"
-#check `[Arith| x + y] -- Arith.add (Arith.symbol "x") (Arith.symbol "y")
-#check `[Arith| x_plus_y + z] -- Arith.add (Arith.symbol "x_plus_y") (Arith.symbol "z")
-
-syntax "<[" term "]>" : arith -- escape for embedding terms into `Arith`
- 
-macro_rules
-  | `(`[Arith| <[ $e:term ]> ]) => e
-  
-
-#check `[Arith| <[ x_plus_y ]>] -- x_plus_y
-```
-

doc/typeclass.md

@@ -76,7 +76,7 @@ you can declare an (anonymous) instance stating that if `a` has addition, then `
 has addition:
 ```lean
 instance [Add a] : Add (Array a) where
-  add x y := Array.zipWith x y (. + .)
+  add x y := Array.zipWith x y (· + ·)
 
 #eval Add.add #[1, 2] #[3, 4]
 -- #[4, 6]
@@ -157,31 +157,6 @@ export Inhabited (default)
 -- true
 # end Ex
 ```
-Sometimes we want to think of the default element of a type as being an *arbitrary* element, whose specific value should not play a role in our proofs.
-For that purpose, we can write ``arbitrary`` instead of ``default``. We define ``arbitrary`` as an *opaque* constant.
-Opaque constants are never unfolded by the type checker.
-```lean
-# namespace Ex
-# export Inhabited (default)
-theorem defNatEq0 : (default : Nat) = 0 :=
-  rfl
-
-constant arbitrary [Inhabited a] : a :=
-  Inhabited.default
-
--- theorem arbitraryNatEq0 : (arbitrary : Nat) = 0 :=
---   rfl
-/-
-error: type mismatch
-  rfl
-has type
-  arbitrary = arbitrary
-but is expected to have type
-  arbitrary = 0
--/
-# end Ex
-```
-The theorem `defNatEq0` type checks because the type checker can unfold `(default : Nat)` and reduce it to `0`. This is not the case in the theorem `arbitraryNatEq0` because `arbitrary` is an opaque constant.
 
 ## Chaining Instances
 
@@ -194,7 +169,7 @@ This causes class inference to chain through instances recursively, backtracking
 For example, the following definition shows that if two types ``a`` and ``b`` are inhabited, then so is their product:
 ```lean
 instance [Inhabited a] [Inhabited b] : Inhabited (a × b) where
-  default := (arbitrary, arbitrary)
+  default := (default, default)
 ```
 With this added to the earlier instance declarations, type class instance can infer, for example, a default element of ``Nat × Bool``:
 ```lean
@@ -205,19 +180,19 @@ With this added to the earlier instance declarations, type class instance can in
 #  default := true
 # instance : Inhabited Nat where
 #  default := 0
-# constant arbitrary [Inhabited a] : a :=
+# opaque default [Inhabited a] : a :=
 #  Inhabited.default
 instance [Inhabited a] [Inhabited b] : Inhabited (a × b) where
-  default := (arbitrary, arbitrary)
+  default := (default, default)
 
-#eval (arbitrary : Nat × Bool)
+#eval (default : Nat × Bool)
 -- (0, true)
 # end Ex
 ```
 Similarly, we can inhabit type function with suitable constant functions:
 ```lean
 instance [Inhabited b] : Inhabited (a -> b) where
-  default := fun _ => arbitrary
+  default := fun _ => default
 ```
 As an exercise, try defining default instances for other types, such as `List` and `Sum` types.
 
@@ -229,7 +204,7 @@ and is useful for triggering the type class resolution procedure when the expect
 def foo : Inhabited (Nat × Nat) :=
   inferInstance
 
-theorem ex : foo.default = (arbitrary, arbitrary) :=
+theorem ex : foo.default = (default, default) :=
   rfl
 ```
 You can use the command `#print` to inspect how simple `inferInstance` is.

doc/whatIsLean.md

@@ -32,10 +32,10 @@ Lean has numerous features, including:
 - First-class functions
 - Powerful data types
 - Pattern matching
-- [Type classes](typeclass.md)
-- [Extensible syntax](syntax.md)
+- [Type classes](./typeclass.md)
+- [Extensible syntax](./syntax.md)
 - Hygienic macros
-- [Dependent types](deptypes.md)
-- [Metaprogramming framework](metaprogramming.md)
+- [Dependent types](https://leanprover.github.io/theorem_proving_in_lean4/dependent_type_theory.html)
+- [Metaprogramming](./metaprogramming.md)
 - Multithreading
 - Verification: you can prove properties of your functions using Lean itself

flake.lock

@@ -2,11 +2,11 @@
   "nodes": {
     "flake-utils": {
       "locked": {
-        "lastModified": 1638122382,
-        "narHash": "sha256-sQzZzAbvKEqN9s0bzWuYmRaA03v40gaJ4+iL1LXjaeI=",
+        "lastModified": 1653893745,
+        "narHash": "sha256-0jntwV3Z8//YwuOjzhV2sgJJPt+HY6KhU7VZUL0fKZQ=",
         "owner": "numtide",
         "repo": "flake-utils",
-        "rev": "74f7e4319258e287b0f9cb95426c9853b282730b",
+        "rev": "1ed9fb1935d260de5fe1c2f7ee0ebaae17ed2fa1",
         "type": "github"
       },
       "original": {
@@ -30,6 +30,22 @@
         "type": "github"
       }
     },
+    "lean4-mode": {
+      "flake": false,
+      "locked": {
+        "lastModified": 1654244721,
+        "narHash": "sha256-AVlr4+WGtJR9DGW/RBq+xNBlyrdmy6cg9dayKHGZowI=",
+        "owner": "leanprover",
+        "repo": "lean4-mode",
+        "rev": "c10def33f603a43f20a4d32d820b61f7ee5dbe5a",
+        "type": "github"
+      },
+      "original": {
+        "owner": "leanprover",
+        "repo": "lean4-mode",
+        "type": "github"
+      }
+    },
     "lowdown-src": {
       "flake": false,
       "locked": {
@@ -46,33 +62,18 @@
         "type": "github"
       }
     },
-    "mdBook": {
-      "flake": false,
-      "locked": {
-        "lastModified": 1637318029,
-        "narHash": "sha256-XU6oQY46mLqLdMp9ONR9WSEBVaA3627cGfzB218Wul0=",
-        "owner": "leanprover",
-        "repo": "mdBook",
-        "rev": "45de7509526f09915b19e4eaeec99c8c2031f1ce",
-        "type": "github"
-      },
-      "original": {
-        "owner": "leanprover",
-        "repo": "mdBook",
-        "type": "github"
-      }
-    },
     "nix": {
       "inputs": {
         "lowdown-src": "lowdown-src",
-        "nixpkgs": "nixpkgs"
+        "nixpkgs": "nixpkgs",
+        "nixpkgs-regression": "nixpkgs-regression"
       },
       "locked": {
-        "lastModified": 1638447470,
-        "narHash": "sha256-DREkiGilBlNzBqonvVrIBNSsYWv1PZuvfXFhaSGeXsM=",
+        "lastModified": 1654239108,
+        "narHash": "sha256-0JzuElxLe5DxM+R4tvBYfvQnMGCERZy4KMRf0JYxxS4=",
         "owner": "NixOS",
         "repo": "nix",
-        "rev": "2ff71b021379a2c9bbdcb789a93cdc585b3520ca",
+        "rev": "1dd7253133c4dfd2e7a16ad6fe505442cef38a5b",
         "type": "github"
       },
       "original": {
@@ -83,26 +84,43 @@
     },
     "nixpkgs": {
       "locked": {
-        "lastModified": 1632864508,
-        "narHash": "sha256-d127FIvGR41XbVRDPVvozUPQ/uRHbHwvfyKHwEt5xFM=",
+        "lastModified": 1645296114,
+        "narHash": "sha256-y53N7TyIkXsjMpOG7RhvqJFGDacLs9HlyHeSTBioqYU=",
         "owner": "NixOS",
         "repo": "nixpkgs",
-        "rev": "82891b5e2c2359d7e58d08849e4c89511ab94234",
+        "rev": "530a53dcbc9437363471167a5e4762c5fcfa34a1",
         "type": "github"
       },
       "original": {
-        "id": "nixpkgs",
+        "owner": "NixOS",
         "ref": "nixos-21.05-small",
-        "type": "indirect"
+        "repo": "nixpkgs",
+        "type": "github"
+      }
+    },
+    "nixpkgs-regression": {
+      "locked": {
+        "lastModified": 1643052045,
+        "narHash": "sha256-uGJ0VXIhWKGXxkeNnq4TvV3CIOkUJ3PAoLZ3HMzNVMw=",
+        "owner": "NixOS",
+        "repo": "nixpkgs",
+        "rev": "215d4d0fd80ca5163643b03a33fde804a29cc1e2",
+        "type": "github"
+      },
+      "original": {
+        "owner": "NixOS",
+        "repo": "nixpkgs",
+        "rev": "215d4d0fd80ca5163643b03a33fde804a29cc1e2",
+        "type": "github"
       }
     },
     "nixpkgs_2": {
       "locked": {
-        "lastModified": 1638397275,
-        "narHash": "sha256-2Jos1CJFTMO9IbulbM4PTKn24nISIDQCAG/AqYQ8rmg=",
+        "lastModified": 1654126564,
+        "narHash": "sha256-sgDXDKGmUG4h7OPDOHyQggFQ08ZqVzUIPi8351yhugY=",
         "owner": "NixOS",
         "repo": "nixpkgs",
-        "rev": "391f93a83c3a486475d60eb4a569bb6afbf306ad",
+        "rev": "f1c9c23aad972787f00f175651e4cb0d7c7fd5ea",
         "type": "github"
       },
       "original": {
@@ -116,26 +134,9 @@
       "inputs": {
         "flake-utils": "flake-utils",
         "lean-stage0": "lean-stage0",
-        "mdBook": "mdBook",
+        "lean4-mode": "lean4-mode",
         "nix": "nix",
-        "nixpkgs": "nixpkgs_2",
-        "temci": "temci"
-      }
-    },
-    "temci": {
-      "flake": false,
-      "locked": {
-        "lastModified": 1638195132,
-        "narHash": "sha256-1DSg4Qr5h54wLrKpZfpkArhFXDFLdO57PiYUMk+7FSc=",
-        "owner": "parttimenerd",
-        "repo": "temci",
-        "rev": "a8d78cb52c248f1ae3f2469bbd0916b14ac9ea84",
-        "type": "github"
-      },
-      "original": {
-        "owner": "parttimenerd",
-        "repo": "temci",
-        "type": "github"
+        "nixpkgs": "nixpkgs_2"
       }
     }
   },

flake.nix

@@ -3,13 +3,9 @@
 
   inputs.nixpkgs.url = github:NixOS/nixpkgs/nixpkgs-unstable;
   inputs.flake-utils.url = github:numtide/flake-utils;
-  inputs.temci = {
-    url = github:parttimenerd/temci;
-    flake = false;
-  };
   inputs.nix.url = github:NixOS/nix;
-  inputs.mdBook = {
-    url = github:leanprover/mdBook;
+  inputs.lean4-mode = {
+    url = github:leanprover/lean4-mode;
     flake = false;
   };
   # used *only* by `stage0-from-input` below
@@ -17,19 +13,18 @@
     url = github:leanprover/lean4;
     inputs.nixpkgs.follows = "nixpkgs";
     inputs.flake-utils.follows = "flake-utils";
-    inputs.temci.follows = "temci";
     inputs.nix.follows = "nix";
-    inputs.mdBook.follows = "mdBook";
+    inputs.lean4-mode.follows = "lean4-mode";
   };
 
-  outputs = { self, nixpkgs, flake-utils, temci, nix, mdBook, lean-stage0 }: flake-utils.lib.eachDefaultSystem (system:
+  outputs = { self, nixpkgs, flake-utils, nix, lean4-mode, lean-stage0 }: flake-utils.lib.eachDefaultSystem (system:
     let
       pkgs = import nixpkgs {
         inherit system;
         # for `vscode-with-extensions`
         config.allowUnfree = true;
       };
-      lean-packages = pkgs.callPackage (./nix/packages.nix) { inherit nix temci mdBook; };
+      lean-packages = pkgs.callPackage (./nix/packages.nix) { inherit nix lean4-mode; };
     in {
       packages = lean-packages // rec {
         debug = lean-packages.override { debug = true; };
@@ -46,12 +41,21 @@
         };
         tsandebug = tsan.override { debug = true; };
         stage0-from-input = lean-packages.override {
-          stage0 = lean-stage0.packages.${system}.lean;
+          stage0 = pkgs.writeShellScriptBin "lean" ''
+            exec ${lean-stage0.packages.${system}.lean}/bin/lean -Dinterpreter.prefer_native=false "$@"
+          '';
         };
         inherit self;
       };
       defaultPackage = lean-packages.lean-all;
 
+      devShell = pkgs.mkShell {
+        buildInputs = [ lean-packages.nix ];
+        shellHook = ''
+          export LEAN_SRC_PATH="$PWD/src"
+        '';
+      };
+
       checks.lean = lean-packages.test;
     }) // rec {
       templates.pkg = {

lean4-mode/.gitignore

@@ -1,2 +0,0 @@
-.cask
-*.elc

lean4-mode/LICENSE

@@ -1,201 +0,0 @@
-                                 Apache License
-                           Version 2.0, January 2004
-                        http://www.apache.org/licenses/
-
-   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
-
-   1. Definitions.
-
-      "License" shall mean the terms and conditions for use, reproduction,
-      and distribution as defined by Sections 1 through 9 of this document.
-
-      "Licensor" shall mean the copyright owner or entity authorized by
-      the copyright owner that is granting the License.
-
-      "Legal Entity" shall mean the union of the acting entity and all
-      other entities that control, are controlled by, or are under common
-      control with that entity. For the purposes of this definition,
-      "control" means (i) the power, direct or indirect, to cause the
-      direction or management of such entity, whether by contract or
-      otherwise, or (ii) ownership of fifty percent (50%) or more of the
-      outstanding shares, or (iii) beneficial ownership of such entity.
-
-      "You" (or "Your") shall mean an individual or Legal Entity
-      exercising permissions granted by this License.
-
-      "Source" form shall mean the preferred form for making modifications,
-      including but not limited to software source code, documentation
-      source, and configuration files.
-
-      "Object" form shall mean any form resulting from mechanical
-      transformation or translation of a Source form, including but
-      not limited to compiled object code, generated documentation,
-      and conversions to other media types.
-
-      "Work" shall mean the work of authorship, whether in Source or
-      Object form, made available under the License, as indicated by a
-      copyright notice that is included in or attached to the work
-      (an example is provided in the Appendix below).
-
-      "Derivative Works" shall mean any work, whether in Source or Object
-      form, that is based on (or derived from) the Work and for which the
-      editorial revisions, annotations, elaborations, or other modifications
-      represent, as a whole, an original work of authorship. For the purposes
-      of this License, Derivative Works shall not include works that remain
-      separable from, or merely link (or bind by name) to the interfaces of,
-      the Work and Derivative Works thereof.
-
-      "Contribution" shall mean any work of authorship, including
-      the original version of the Work and any modifications or additions
-      to that Work or Derivative Works thereof, that is intentionally
-      submitted to Licensor for inclusion in the Work by the copyright owner
-      or by an individual or Legal Entity authorized to submit on behalf of
-      the copyright owner. For the purposes of this definition, "submitted"
-      means any form of electronic, verbal, or written communication sent
-      to the Licensor or its representatives, including but not limited to
-      communication on electronic mailing lists, source code control systems,
-      and issue tracking systems that are managed by, or on behalf of, the
-      Licensor for the purpose of discussing and improving the Work, but
-      excluding communication that is conspicuously marked or otherwise
-      designated in writing by the copyright owner as "Not a Contribution."
-
-      "Contributor" shall mean Licensor and any individual or Legal Entity
-      on behalf of whom a Contribution has been received by Licensor and
-      subsequently incorporated within the Work.
-
-   2. Grant of Copyright License. Subject to the terms and conditions of
-      this License, each Contributor hereby grants to You a perpetual,
-      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
-      copyright license to reproduce, prepare Derivative Works of,
-      publicly display, publicly perform, sublicense, and distribute the
-      Work and such Derivative Works in Source or Object form.
-
-   3. Grant of Patent License. Subject to the terms and conditions of
-      this License, each Contributor hereby grants to You a perpetual,
-      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
-      (except as stated in this section) patent license to make, have made,
-      use, offer to sell, sell, import, and otherwise transfer the Work,
-      where such license applies only to those patent claims licensable
-      by such Contributor that are necessarily infringed by their
-      Contribution(s) alone or by combination of their Contribution(s)
-      with the Work to which such Contribution(s) was submitted. If You
-      institute patent litigation against any entity (including a
-      cross-claim or counterclaim in a lawsuit) alleging that the Work
-      or a Contribution incorporated within the Work constitutes direct
-      or contributory patent infringement, then any patent licenses
-      granted to You under this License for that Work shall terminate
-      as of the date such litigation is filed.
-
-   4. Redistribution. You may reproduce and distribute copies of the
-      Work or Derivative Works thereof in any medium, with or without
-      modifications, and in Source or Object form, provided that You
-      meet the following conditions:
-
-      (a) You must give any other recipients of the Work or
-          Derivative Works a copy of this License; and
-
-      (b) You must cause any modified files to carry prominent notices
-          stating that You changed the files; and
-
-      (c) You must retain, in the Source form of any Derivative Works
-          that You distribute, all copyright, patent, trademark, and
-          attribution notices from the Source form of the Work,
-          excluding those notices that do not pertain to any part of
-          the Derivative Works; and
-
-      (d) If the Work includes a "NOTICE" text file as part of its
-          distribution, then any Derivative Works that You distribute must
-          include a readable copy of the attribution notices contained
-          within such NOTICE file, excluding those notices that do not
-          pertain to any part of the Derivative Works, in at least one
-          of the following places: within a NOTICE text file distributed
-          as part of the Derivative Works; within the Source form or
-          documentation, if provided along with the Derivative Works; or,
-          within a display generated by the Derivative Works, if and
-          wherever such third-party notices normally appear. The contents
-          of the NOTICE file are for informational purposes only and
-          do not modify the License. You may add Your own attribution
-          notices within Derivative Works that You distribute, alongside
-          or as an addendum to the NOTICE text from the Work, provided
-          that such additional attribution notices cannot be construed
-          as modifying the License.
-
-      You may add Your own copyright statement to Your modifications and
-      may provide additional or different license terms and conditions
-      for use, reproduction, or distribution of Your modifications, or
-      for any such Derivative Works as a whole, provided Your use,
-      reproduction, and distribution of the Work otherwise complies with
-      the conditions stated in this License.
-
-   5. Submission of Contributions. Unless You explicitly state otherwise,
-      any Contribution intentionally submitted for inclusion in the Work
-      by You to the Licensor shall be under the terms and conditions of
-      this License, without any additional terms or conditions.
-      Notwithstanding the above, nothing herein shall supersede or modify
-      the terms of any separate license agreement you may have executed
-      with Licensor regarding such Contributions.
-
-   6. Trademarks. This License does not grant permission to use the trade
-      names, trademarks, service marks, or product names of the Licensor,
-      except as required for reasonable and customary use in describing the
-      origin of the Work and reproducing the content of the NOTICE file.
-
-   7. Disclaimer of Warranty. Unless required by applicable law or
-      agreed to in writing, Licensor provides the Work (and each
-      Contributor provides its Contributions) on an "AS IS" BASIS,
-      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
-      implied, including, without limitation, any warranties or conditions
-      of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
-      PARTICULAR PURPOSE. You are solely responsible for determining the
-      appropriateness of using or redistributing the Work and assume any
-      risks associated with Your exercise of permissions under this License.
-
-   8. Limitation of Liability. In no event and under no legal theory,
-      whether in tort (including negligence), contract, or otherwise,
-      unless required by applicable law (such as deliberate and grossly
-      negligent acts) or agreed to in writing, shall any Contributor be
-      liable to You for damages, including any direct, indirect, special,
-      incidental, or consequential damages of any character arising as a
-      result of this License or out of the use or inability to use the
-      Work (including but not limited to damages for loss of goodwill,
-      work stoppage, computer failure or malfunction, or any and all
-      other commercial damages or losses), even if such Contributor
-      has been advised of the possibility of such damages.
-
-   9. Accepting Warranty or Additional Liability. While redistributing
-      the Work or Derivative Works thereof, You may choose to offer,
-      and charge a fee for, acceptance of support, warranty, indemnity,
-      or other liability obligations and/or rights consistent with this
-      License. However, in accepting such obligations, You may act only
-      on Your own behalf and on Your sole responsibility, not on behalf
-      of any other Contributor, and only if You agree to indemnify,
-      defend, and hold each Contributor harmless for any liability
-      incurred by, or claims asserted against, such Contributor by reason
-      of your accepting any such warranty or additional liability.
-
-   END OF TERMS AND CONDITIONS
-
-   APPENDIX: How to apply the Apache License to your work.
-
-      To apply the Apache License to your work, attach the following
-      boilerplate notice, with the fields enclosed by brackets "{}"
-      replaced with your own identifying information. (Don't include
-      the brackets!)  The text should be enclosed in the appropriate
-      comment syntax for the file format. We also recommend that a
-      file or class name and description of purpose be included on the
-      same "printed page" as the copyright notice for easier
-      identification within third-party archives.
-
-   Copyright {yyyy} {name of copyright owner}
-
-   Licensed under the Apache License, Version 2.0 (the "License");
-   you may not use this file except in compliance with the License.
-   You may obtain a copy of the License at
-
-       http://www.apache.org/licenses/LICENSE-2.0
-
-   Unless required by applicable law or agreed to in writing, software
-   distributed under the License is distributed on an "AS IS" BASIS,
-   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-   See the License for the specific language governing permissions and
-   limitations under the License.

lean4-mode/README.md

@@ -1,79 +0,0 @@
-Installation
-============
-
-To use `lean4-mode` in Emacs, add the following to your `init.el`:
-```
-;; You need to modify the following line
-(setq load-path (cons "/path/to/lean4/lean4-mode" load-path))
-
-(setq lean4-mode-required-packages '(dash f flycheck lsp-mode magit-section s))
-
-(require 'package)
-(add-to-list 'package-archives '("melpa" . "http://melpa.org/packages/"))
-(package-initialize)
-(let ((need-to-refresh t))
-  (dolist (p lean4-mode-required-packages)
-    (when (not (package-installed-p p))
-      (when need-to-refresh
-        (package-refresh-contents)
-        (setq need-to-refresh nil))
-      (package-install p))))
-
-(require 'lean4-mode)
-```
-Alternatively if you are a fan of `use-package` and `straight.el` you
-can use:
-```
-(use-package lean4-mode
-  :straight (lean4-mode :type git :host github :repo "leanprover/lean4"
-             :files ("lean4-mode/lean4*.el"))
-  ;; to defer loading the package until required
-  :commands (lean4-mode))
-```
-If you are working on the `lean4` repository already and don't want to
-have two separate checkouts you can use:
-```
-(use-package lean4-mode
-  :straight (lean4-mode :local-repo "/path/to/your/lean4"
-             :files ("lean4-mode/lean4*.el"))
-  ;; to defer loading the package until required
-  :commands (lean4-mode))
-```
-
-
-Trying It Out
-=============
-
-If things are working correctly, you should see the word ``Lean 4`` in the
-Emacs mode line when you open a file with extension `.lean`. Emacs will ask you
-to identify the "project" this file belongs to. If you then type
-```lean
-#check id
-```
-the word ``#check`` will be underlined, and hovering over it will show
-you the type of ``id``. The mode line will show ``FlyC:0/1``, indicating
-that there are no errors and one piece of information displayed.
-
-Settings
-========
-
-Set these with e.g. `M-x customize-variable`.
-
-* `lsp-headerline-breadcrumb-enable`: show a "breadcrumb bar" of namespaces and sections surrounding the current location (default: off)
-
-Key Bindings and Commands
-=========================
-
-| Key                | Function                                                                        |
-|--------------------|---------------------------------------------------------------------------------|
-| <kbd>C-c C-k</kbd> | show the keystroke needed to input the symbol under the cursor                  |
-| <kbd>C-c C-d</kbd> | recompile & reload imports (`lean4-refresh-file-dependencies`)                  |
-| <kbd>C-c C-x</kbd> | execute Lean in stand-alone mode (`lean4-std-exe`)                              |
-| <kbd>C-c C-i</kbd> | toggle info view showing goals and errors at point (`lean4-toggle-info-buffer`) |
-| <kbd>C-c ! n</kbd> | flycheck: go to next error                                                      |
-| <kbd>C-c ! p</kbd> | flycheck: go to previous error                                                  |
-
-For `lsp-mode` bindings, see https://emacs-lsp.github.io/lsp-mode/page/keybindings/ (not all capabilities are supported currently).
-
-In the default configuration, the Flycheck annotation `FlyC:n/n` indicates the
-number of errors / responses from Lean; clicking on `FlyC` opens the Flycheck menu.

lean4-mode/lean4-debug.el

@@ -1,47 +0,0 @@
-;; Copyright (c) 2014 Microsoft Corporation. All rights reserved.
-;; Released under Apache 2.0 license as described in the file LICENSE.
-;;
-;; Author: Soonho Kong
-;;
-(require 'cl-lib)
-
-(defvar lean4-debug-mode nil)
-
-(defvar lean4-debug-buffer-name "*lean4-debug*")
-
-(defun lean4-turn-on-debug-mode (&optional print-msg)
-  (interactive)
-  (when (or (called-interactively-p 'any) print-msg)
-    (message "lean: turn on debug mode"))
-  (get-buffer-create lean4-debug-buffer-name)
-  (buffer-disable-undo lean4-debug-buffer-name)
-  (display-buffer lean4-debug-buffer-name 'display-buffer-reuse-window
-                  '((reusable-frames . t)))
-  (setq lean4-debug-mode t))
-
-(defun lean4-turn-off-debug-mode (&optional print-msg)
-  (interactive)
-  (when (eq major-mode 'lean4-mode)
-    (when (or (called-interactively-p 'any) print-msg)
-      (message "lean: turn off debug mode"))
-    (setq lean4-debug-mode nil)))
-
-(defun lean4-output-to-buffer (buffer-name format-string args)
-  (with-current-buffer
-      (get-buffer-create buffer-name)
-    (save-selected-window
-      (ignore-errors
-        (select-window (get-buffer-window buffer-name t)))
-      (goto-char (point-max))
-      (insert (apply 'format format-string args)))))
-
-(defun lean4-debug (format-string &rest args)
-  "Display a message at the bottom of the *lean4-debug* buffer."
-  (when lean4-debug-mode
-    (let ((time-str (format-time-string "%H:%M:%S.%3N" (current-time))))
-      (lean4-output-to-buffer lean4-debug-buffer-name
-                             (concat "%s -- " format-string "\n")
-                             (cons (propertize time-str 'face 'font-lock-keyword-face)
-                                   args)))))
-
-(provide 'lean4-debug)

lean4-mode/lean4-dev.el

@@ -1,19 +0,0 @@
-;;  -*- lexical-binding: t -*-
-;;
-;; Copyright (c) 2017 Microsoft Corporation. All rights reserved.
-;; Released under Apache 2.0 license as described in the file LICENSE.
-;;
-;; Author: Sebastian Ullrich
-;;
-
-(require 'f)
-(require 'lean4-util)
-
-(defun lean4-diff-test-file ()
-  "Use interactive ./test_input.sh on file of current buffer"
-  (interactive)
-  (save-buffer)
-  ; yes: auto-agree to copying missing files
-  (message (shell-command-to-string (format "yes | PATH=%s/bin:$PATH ./test_single.sh -i \"%s\"" (lean4-get-rootdir) (f-filename (buffer-file-name))))))
-
-(provide 'lean4-dev)

lean4-mode/lean4-eri.el

@@ -1,208 +0,0 @@
-;;; lean4-eri.el --- Enhanced relative indentation (eri)
-
-;;; Commentary:
-
-;; Adapted from agda-mode (https://github.com/agda/agda/blob/master/src/data/emacs-mode/eri.el)
-
-;;; Code:
-
-(require 'cl-lib)
-
-(defun lean4-eri-current-line-length nil
-  "Calculate length of current line."
-  (- (line-end-position) (line-beginning-position)))
-
-(defun lean4-eri-current-line-empty nil
-  "Return non-nil if the current line is empty (not counting white space)."
-  (equal (current-indentation)
-         (lean4-eri-current-line-length)))
-
-(defun lean4-eri-maximum (xs)
-  "Calculate maximum element in XS.
-Returns nil if the list is empty."
-  (if xs (apply 'max xs)))
-
-(defun lean4-eri-take (n xs)
-  "Return the first N elements of XS."
-  (butlast xs (- (length xs) n)))
-
-(defun lean4-eri-split (x xs)
-  "Return a pair of lists (XS1 . XS2).
-If XS is sorted, then XS = (append XS1 XS2), and all elements in
-XS1 are <= X, whereas all elements in XS2 are > X."
-  (let* ((pos (or (cl-position-if (lambda (y) (> y x)) xs) (length xs)))
-         (xs1 (lean4-eri-take pos xs))
-         (xs2 (nthcdr pos xs)))
-    (cons xs1 xs2)))
-
-(defun lean4-eri-calculate-indentation-points-on-line (max)
-  "Calculate indentation points on current line.
-Only points left of column number MAX are included. If MAX is
-nil, then all points are included. Points are returned in
-ascending order.
-
-Example (positions marked with ^ are returned):
-
-  f x y = g 3 (Just y) 5 4
-  ^ ^ ^ ^ ^ ^ ^     ^  |
-                       |
-                       MAX"
-  (let ((result))
-    (save-excursion
-      (save-restriction
-        (beginning-of-line)
-        ; To make \\` work in the regexp below:
-        (narrow-to-region (line-beginning-position) (line-end-position))
-        (while
-            (progn
-              (let ((pos (and (search-forward-regexp
-                               "\\(?:\\s-\\|\\`\\)\\(\\S-\\)" nil t)
-                              (match-beginning 1))))
-                (when (not (null pos))
-                  (let ((pos1 (- pos (line-beginning-position))))
-                    (when (or (null max) (< pos1 max))
-                      (add-to-list 'result pos1))))
-                (and pos
-                     (< (point) (line-end-position))
-                     (or (null max) (< (current-column) max))))))
-        (nreverse result) ; Destructive operation.
-        ))))
-
-(defun lean4-eri-new-indentation-points ()
-  "Calculate new indentation points.
-Returns a singleton list containing the column number two steps
-in from the indentation of the first non-empty line (white space
-excluded) above the current line. If there is no such line,
-then the empty list is returned."
-  (let ((start (line-beginning-position)))
-    (save-excursion
-      ; Find a non-empty line above the current one, if any.
-      (while
-          (progn
-            (forward-line -1)
-            (not (or (bobp)
-                     (not (lean4-eri-current-line-empty))))))
-      (if (or (equal (point) start)
-              (lean4-eri-current-line-empty))
-          nil
-        (list (+ 2 (current-indentation)))))))
-
-(defun lean4-eri-calculate-indentation-points (reverse)
-  "Calculate points used to indent the current line.
-The points are given in reverse order if REVERSE is non-nil. See
-`lean4-eri-indent' for a description of how the indentation points are
-calculated; note that the current indentation is not included in
-the returned list."
-  ;; First find a bunch of indentations used above the current line.
-  (let ((points)
-        (max)
-        (start (line-beginning-position)))
-    (save-excursion
-      (while
-          (progn
-            (forward-line -1)
-            ; Skip the line we started from and lines with nothing but
-            ; white space.
-            (unless (or (equal (point) start)
-                        (lean4-eri-current-line-empty))
-              (setq points
-                    (append
-                     (lean4-eri-calculate-indentation-points-on-line max)
-                     points))
-              (setq max (car points)))
-            ;; Stop after hitting the beginning of the buffer or a
-            ;; non-empty, non-indented line.
-            (not (or (bobp)
-                     (and (equal (current-indentation) 0)
-                          (> (lean4-eri-current-line-length) 0)))))))
-    ;; Add new indentation points, but remove the current indentation.
-    ;; Sort the indentations. Rearrange the points so that the next
-    ;; point is the one after the current one. Reverse if necessary.
-    ;;
-    ;; Note: sort and nreverse are destructive.
-    (let* ((ps0 (remove (current-indentation)
-                        (append (lean4-eri-new-indentation-points) points)))
-           (ps1 (lean4-eri-split (current-indentation) (sort ps0 '<)))
-           (ps2 (append (cdr ps1) (car ps1))))
-      (if reverse
-          (nreverse ps2)
-        ps2))))
-
-(defun lean4-eri-indent (&optional reverse)
-  "Cycle between some possible indentation points.
-With prefix argument REVERSE, cycle in reverse order.
-
-Assume that a file contains the following lines of code, with
-point on the line with three dots:
-
-frob = loooooooooooooooooooooooooong identifier
-foo = f a b
-  where
-    f (Foo x) y = let bar = x
-                      baz = 3 + 5
-
-...
-
-^ ^ ^ ^    ^  ^ ^ ^   ^ * ^ ^ ^ ^
-
-Then the ^'s and the * mark the indentation points that this
-function cycles through. The indentation points are selected as
-follows:
-
-  * All lines before the current one, up to and including the
-    first non-indented line (or the beginning of the buffer) are
-    considered.
-
-      foo = f a b
-        where
-          f (Foo x) y = let bar = x
-                            baz = 3 + 5
-
-  * On these lines, erase all characters that stand to the right
-    of some non-white space character on a lower line.
-
-      foo
-        whe
-          f (Foo x) y = let b
-                            baz = 3 + 5
-
-  * Also erase all characters not immediately preceded by white
-    space.
-
-      f
-        w
-          f (    x  y = l   b
-                            b   = 3 + 5
-
-  * The columns of all remaining characters are indentation
-    points.
-
-      f w f (    x  y = l   b   = 3 + 5
-      ^ ^ ^ ^    ^  ^ ^ ^   ^   ^ ^ ^ ^
-
-  * A new indentation point is also added, two steps in from the
-    indentation of the first non-empty line (white space
-    excluded) above the current line (if there is such a line).
-
-      f w f (    x  y = l   b   = 3 + 5
-      ^ ^ ^ ^    ^  ^ ^ ^   ^ * ^ ^ ^ ^"
-  (interactive "P")
-  (let* ((points (lean4-eri-calculate-indentation-points reverse))
-         (remaining-points (cdr (member (current-indentation) points)))
-         (indentation (if remaining-points
-                          (car remaining-points)
-                        (car points))))
-    (when indentation
-      (save-excursion (indent-line-to indentation))
-      (if (< (current-column) indentation)
-          (indent-line-to indentation)))))
-
-(defun lean4-eri-indent-reverse nil
-  "Cycle between some possible indentation points (in reverse order).
-See `lean4-eri-indent' for a description of how the indentation points
-are calculated."
-  (interactive)
-  (lean4-eri-indent t))
-
-(provide 'lean4-eri)
-;;; lean4-eri.el ends here