chore: only build small allocator if enabled

This prevents us from calling alloc/dealloc if LEAN_SMALL_ALLOCATOR is
disabled.

.gitattributes

@@ -1,6 +1,3 @@
-*.lean text eol=lf
 *.expected.out -text
 RELEASES.md merge=union
 stage0/** binary linguist-generated
-# The following file is often manually edited, so do show it in diffs
-stage0/src/stdlib_flags.h -binary -linguist-generated

.github/ISSUE_TEMPLATE.md

@@ -0,0 +1,30 @@
+### Prerequisites
+
+* [ ] Put an X between the brackets on this line if you have done all of the following:
+    * Checked that your issue isn't already [filed](https://github.com/leanprover/lean4/issues).
+    * Reduced the issue to a self-contained, reproducible test case.
+
+### Description
+
+[Description of the issue]
+
+### Steps to Reproduce
+
+1. [First Step]
+2. [Second Step]
+3. [and so on...]
+
+**Expected behavior:** [What you expect to happen]
+
+**Actual behavior:** [What actually happens]
+
+**Reproduces how often:** [What percentage of the time does it reproduce?]
+
+### Versions
+
+You can get this information from copy and pasting the output of `lean --version`,
+please include the OS and what version of the OS you're running.
+
+### Additional Information
+
+Any additional information, configuration or data that might be necessary to reproduce the issue.

.github/ISSUE_TEMPLATE/bug_report.md

@@ -1,51 +0,0 @@
----
-name: Bug report
-about: Create a bug report
-title: ''
-labels: bug
-assignees: ''
-
----
-
-### Prerequisites
-
-Please put an X between the brackets as you perform the following steps:
-
-* [ ] Check that your issue is not already filed:
-      https://github.com/leanprover/lean4/issues
-* [ ] Reduce the issue to a minimal, self-contained, reproducible test case.
-      Avoid dependencies to Mathlib or Batteries.
-* [ ] Test your test case against the latest nightly release, for example on
-      https://live.lean-lang.org/#project=lean-nightly
-      (You can also use the settings there to switch to “Lean nightly”)
-
-### Description
-
-[Clear and concise description of the issue]
-
-### Context
-
-[Broader context that the issue occurred in. If there was any prior discussion on [the Lean Zulip](https://leanprover.zulipchat.com), link it here as well.]
-
-### Steps to Reproduce
-
-1.
-2.
-3.
-
-**Expected behavior:** [Clear and concise description of what you expect to happen]
-
-**Actual behavior:** [Clear and concise description of what actually happens]
-
-### Versions
-
-[Output of `#version` or `#eval Lean.versionString`]
-[OS version, if not using live.lean-lang.org.]
-
-### Additional Information
-
-[Additional information, configuration or data that might be necessary to reproduce the issue]
-
-### Impact
-
-Add :+1: to [issues you consider important](https://github.com/leanprover/lean4/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc). If others are impacted by this issue, please ask them to add :+1: to it.

.github/ISSUE_TEMPLATE/rfc.md

@@ -1,26 +0,0 @@
----
-name: Request for comments
-about: Create a feature proposal
-title: 'RFC: '
-labels: RFC
-assignees: ''
-
----
-
-### Proposal
-
-Clear and detailed description of the proposal. Consider the following questions:
-
-  - **User Experience**: How does this feature improve the user experience?
-
-  - **Beneficiaries**: Which Lean users and projects benefit most from this feature/change?
-
-  - **Maintainability**: Will this change streamline code maintenance or simplify its structure?
-
-### Community Feedback
-
-Ideas should be discussed on [the Lean Zulip](https://leanprover.zulipchat.com) prior to submitting a proposal. Summarize all prior discussions and link them here.
-
-### Impact
-
-Add :+1: to [issues you consider important](https://github.com/leanprover/lean4/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc). If others benefit from the changes in this proposal being added, please ask them to add :+1: to it.

.github/PULL_REQUEST_TEMPLATE.md

@@ -1,21 +0,0 @@
-# Read this section before submitting
-
-* Ensure your PR follows the [External Contribution Guidelines](https://github.com/leanprover/lean4/blob/master/CONTRIBUTING.md).
-* Please make sure the PR has excellent documentation and tests. If we label it `missing documentation` or `missing tests` then it needs fixing!
-* Include the link to your `RFC` or `bug` issue in the description.
-* If the issue does not already have approval from a developer, submit the PR as draft.
-* The PR title/description will become the commit message. Keep it up-to-date as the PR evolves.
-* For `feat/fix` PRs, the first paragraph starting with "This PR" must be present and will become a
-  changelog entry unless the PR is labeled with `no-changelog`. If the PR does not have this label,
-  it must instead be categorized with one of the `changelog-*` labels (which will be done by a
-  reviewer for external PRs).
-* A toolchain of the form `leanprover/lean4-pr-releases:pr-release-NNNN` for Linux and M-series Macs will be generated upon build. To generate binaries for Windows and Intel-based Macs as well, write a comment containing `release-ci` on its own line.
-* If you rebase your PR onto `nightly-with-mathlib` then CI will test Mathlib against your PR.
-* You can manage the `awaiting-review`, `awaiting-author`, and `WIP` labels yourself, by writing a comment containing one of these labels on its own line.
-* Remove this section, up to and including the `---` before submitting.
-
----
-
-This PR <short changelog summary for feat/fix, see above>.
-
-Closes <`RFC` or `bug` issue number fixed by this PR, if any>

.github/dependabot.yml

@@ -1,8 +0,0 @@
-version: 2
-updates:
-  - package-ecosystem: "github-actions"
-    directory: "/"
-    schedule:
-      interval: "monthly"
-    commit-message:
-      prefix: "chore: CI"

.github/workflows/actionlint.yml

@@ -1,22 +0,0 @@
-name: Actionlint
-on:
-  push:
-    branches:
-      - 'master'
-    paths:
-      - '.github/**'
-  pull_request:
-    paths:
-      - '.github/**'
-  merge_group:
-
-jobs:
-  actionlint:
-    runs-on: ubuntu-latest
-    steps:
-    - name: Checkout
-      uses: actions/checkout@v4
-    - name: actionlint
-      uses: raven-actions/actionlint@v2
-      with:
-        pyflakes: false # we do not use python scripts

.github/workflows/backport.yml

@@ -1,26 +0,0 @@
-name: Backport
-on:
-  pull_request_target:
-    types:
-      - closed
-      - labeled
-
-jobs:
-  backport:
-    name: Backport
-    runs-on: ubuntu-latest
-    # Only react to merged PRs for security reasons.
-    # See https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target.
-    if: >
-      github.event.pull_request.merged
-      && (
-        github.event.action == 'closed'
-        || (
-          github.event.action == 'labeled'
-          && contains(github.event.label.name, 'backport')
-        )
-      )
-    steps:
-      - uses: tibdex/backport@v2
-        with:
-          github_token: ${{ secrets.GITHUB_TOKEN }}

.github/workflows/changelog.yml

@@ -0,0 +1,33 @@
+name: add PR to changelog
+
+on:
+  # needs read/write GH token, do *not* execute arbitrary code from PR
+  pull_request_target:
+    types: [closed]
+
+jobs:
+  update-changelog:
+    if: |
+      github.event.pull_request.merged == true &&
+      contains(github.event.pull_request.labels.*.name, 'changelog') &&
+      github.base_ref == 'master'
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v3
+        with:
+          # needs sufficiently elevated token to override branch protection rules
+          token: ${{ secrets.PUSH_NIGHTLY_TOKEN }}
+      - name: Update changelog
+        run: |
+          set -euxo pipefail
+          escaped_link=$(sed -e 's/[\/&]/\\&/g' <<'EOF'
+          [${{ github.event.pull_request.title}}](${{ github.event.pull_request.html_url }})
+          EOF
+          )
+          # insert link below first dashes line (https://stackoverflow.com/a/9453461/161659)
+          sed -i "0,/^---*/s/^---*/\0\n\n* $escaped_link./" RELEASES.md
+          # commit as github-actions bot (https://github.com/orgs/community/discussions/26560#discussioncomment-3252339)
+          git config user.email "41898282+github-actions[bot]@users.noreply.github.com"
+          git config user.name "github-actions[bot]"
+          git commit -i RELEASES.md -m "doc: update changelog"
+          git push

.github/workflows/check-prelude.yml

@@ -1,29 +0,0 @@
-name: Check for modules that should use `prelude`
-
-on: [pull_request]
-
-jobs:
-  check-prelude:
-    runs-on: ubuntu-latest
-    steps:
-      - name: Checkout
-        uses: actions/checkout@v4
-        with:
-          # the default is to use a virtual merge commit between the PR and master: just use the PR
-          ref: ${{ github.event.pull_request.head.sha }}
-          sparse-checkout: |
-            src/Lean
-            src/Std
-            src/lake/Lake
-      - name: Check Prelude
-        run: |
-          failed_files=""
-          while IFS= read -r -d '' file; do
-            if ! grep -q "^prelude$" "$file"; then
-              failed_files="$failed_files$file\n"
-            fi
-          done < <(find src/Lean src/Std src/lake/Lake -name '*.lean' -print0)
-          if [ -n "$failed_files" ]; then
-            echo -e "The following files should use 'prelude':\n$failed_files"
-            exit 1
-          fi

.github/workflows/check-stage0.yml

@@ -1,57 +0,0 @@
-name: Check for stage0 changes
-
-on:
-  merge_group:
-  pull_request:
-
-jobs:
-  check-stage0-on-queue:
-    runs-on: ubuntu-latest
-    steps:
-    - uses: actions/checkout@v4
-      with:
-        ref: ${{ github.event.pull_request.head.sha }}
-        filter: blob:none
-        fetch-depth: 0
-
-    - name: Find base commit
-      if: github.event_name == 'pull_request'
-      run: echo "BASE=$(git merge-base origin/${{ github.base_ref }} HEAD)" >> "$GITHUB_ENV"
-
-    - name: Identify stage0 changes
-      run: |
-        git diff "${BASE:-HEAD^}..HEAD" --name-only -- stage0 |
-          grep -v -x -F $'stage0/src/stdlib_flags.h\nstage0/src/lean.mk.in' \
-          > "$RUNNER_TEMP/stage0" || true
-        if test -s "$RUNNER_TEMP/stage0"
-        then
-          echo "CHANGES=yes" >> "$GITHUB_ENV"
-        else
-          echo "CHANGES=no" >> "$GITHUB_ENV"
-        fi
-      shell: bash
-
-    - if: github.event_name == 'pull_request'
-      name: Set label
-      uses: actions/github-script@v7
-      with:
-        script: |
-          const { owner, repo, number: issue_number  } = context.issue;
-          if (process.env.CHANGES == 'yes') {
-            await github.rest.issues.addLabels({ owner, repo, issue_number, labels: ['changes-stage0'] }).catch(() => {});
-          } else {
-            await github.rest.issues.removeLabel({ owner, repo, issue_number, name: 'changes-stage0' }).catch(() => {});
-          }
-
-    - if: env.CHANGES == 'yes'
-      name: Report changes
-      run: |
-        echo "Found changes to stage0/, please do not merge using the merge queue." | tee "$GITHUB_STEP_SUMMARY"
-        # shellcheck disable=SC2129
-        echo '```'                  >> "$GITHUB_STEP_SUMMARY"
-        cat  "$RUNNER_TEMP/stage0"  >> "$GITHUB_STEP_SUMMARY"
-        echo '```'                  >> "$GITHUB_STEP_SUMMARY"
-
-    - if: github.event_name == 'merge_group' && env.CHANGES == 'yes'
-      name: Fail when on the merge queue
-      run: exit 1

.github/workflows/ci.yml

@@ -6,275 +6,113 @@ on:
     tags:
       - '*'
   pull_request:
-  merge_group:
+    branches:
+      - master
   schedule:
     - cron: '0 7 * * *'  # 8AM CET/11PM PT
-  # for manual re-release of a nightly
-  workflow_dispatch:
-    inputs:
-      action:
-        description: 'Action'
-        required: true
-        default: 'release nightly'
-        type: choice
-        options:
-        - release nightly
-
 
 concurrency:
   group: ${{ github.workflow }}-${{ github.ref }}-${{ github.event_name }}
   cancel-in-progress: true
 
 jobs:
-
-  # This job determines various settings for the following CI runs; see the `outputs` for details
-  configure:
+  set-nightly:
     runs-on: ubuntu-latest
     outputs:
-      # 0: PRs without special label
-      # 1: PRs with `merge-ci` label, merge queue checks, master commits
-      # 2: PRs with `release-ci` label, releases (incl. nightlies)
-      check-level: ${{ steps.set-level.outputs.check-level }}
-      # The build matrix, dynamically generated here
-      matrix: ${{ steps.set-matrix.outputs.result }}
-      # Should we make a nightly release? If so, this output contains the lean version string, else it is empty
-      nightly: ${{ steps.set-nightly.outputs.nightly }}
-      # Should this be the CI for a tagged release?
-      # Yes only if a tag is pushed to the `leanprover` repository, and the tag is "v" followed by a valid semver.
-      # It sets `set-release.outputs.RELEASE_TAG` to the tag
-      # and sets `set-release.outputs.{LEAN_VERSION_MAJOR,LEAN_VERSION_MINOR,LEAN_VERSION_PATCH,LEAN_SPECIAL_VERSION_DESC}`
-      # to the semver components parsed via regex.
-      LEAN_VERSION_MAJOR: ${{ steps.set-release.outputs.LEAN_VERSION_MAJOR }}
-      LEAN_VERSION_MINOR: ${{ steps.set-release.outputs.LEAN_VERSION_MINOR }}
-      LEAN_VERSION_PATCH: ${{ steps.set-release.outputs.LEAN_VERSION_PATCH }}
-      LEAN_SPECIAL_VERSION_DESC: ${{ steps.set-release.outputs.LEAN_SPECIAL_VERSION_DESC }}
-      RELEASE_TAG: ${{ steps.set-release.outputs.RELEASE_TAG }}
-
+      nightly: ${{ steps.set.outputs.nightly }}
     steps:
       - name: Checkout
-        uses: actions/checkout@v4
+        uses: actions/checkout@v3
         # don't schedule nightlies on forks
-        if: github.event_name == 'schedule' && github.repository == 'leanprover/lean4' || inputs.action == 'release nightly'
+        if: github.event_name == 'schedule' && github.repository == 'leanprover/lean4'
       - name: Set Nightly
-        if: github.event_name == 'schedule' && github.repository == 'leanprover/lean4' || inputs.action == 'release nightly'
-        id: set-nightly
+        if: github.event_name == 'schedule' && github.repository == 'leanprover/lean4'
+        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 "nightly=$LEAN_VERSION_STRING" >> "$GITHUB_OUTPUT"
+            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
 
-      - name: Check for official release
-        if: startsWith(github.ref, 'refs/tags/') && github.repository == 'leanprover/lean4'
-        id: set-release
-        run: |
-          TAG_NAME="${GITHUB_REF##*/}"
-
-          # From https://github.com/fsaintjacques/semver-tool/blob/master/src/semver
-
-          NAT='0|[1-9][0-9]*'
-          ALPHANUM='[0-9]*[A-Za-z-][0-9A-Za-z-]*'
-          IDENT="$NAT|$ALPHANUM"
-          FIELD='[0-9A-Za-z-]+'
-
-          SEMVER_REGEX="\
-          ^[vV]?\
-          ($NAT)\\.($NAT)\\.($NAT)\
-          (\\-(${IDENT})(\\.(${IDENT}))*)?\
-          (\\+${FIELD}(\\.${FIELD})*)?$"
-
-          if [[ ${TAG_NAME} =~ ${SEMVER_REGEX} ]]; then
-            echo "Tag ${TAG_NAME} matches SemVer regex, with groups ${BASH_REMATCH[1]} ${BASH_REMATCH[2]} ${BASH_REMATCH[3]} ${BASH_REMATCH[4]}"
-            {
-              echo "LEAN_VERSION_MAJOR=${BASH_REMATCH[1]}"
-              echo "LEAN_VERSION_MINOR=${BASH_REMATCH[2]}"
-              echo "LEAN_VERSION_PATCH=${BASH_REMATCH[3]}"
-              echo "LEAN_SPECIAL_VERSION_DESC=${BASH_REMATCH[4]##-}"
-              echo "RELEASE_TAG=$TAG_NAME"
-            } >> "$GITHUB_OUTPUT"
-          else
-            echo "Tag ${TAG_NAME} did not match SemVer regex."
-          fi
-
-      - name: Set check level
-        id: set-level
-        # We do not use github.event.pull_request.labels.*.name here because
-        # re-running a run does not update that list, and we do want to be able to
-        # rerun the workflow run after setting the `release-ci`/`merge-ci` labels.
-        run: |
-          check_level=0
-
-          if [[ -n "${{ steps.set-nightly.outputs.nightly }}" || -n "${{ steps.set-release.outputs.RELEASE_TAG }}" ]]; then
-            check_level=2
-          elif [[ "${{ github.event_name }}" != "pull_request" ]]; then
-            check_level=1
-          else
-            labels="$(gh api repos/${{ github.repository_owner }}/${{ github.event.repository.name }}/pulls/${{ github.event.pull_request.number }} --jq '.labels')"
-            if echo "$labels" | grep -q "release-ci"; then
-              check_level=2
-            elif echo "$labels" | grep -q "merge-ci"; then
-              check_level=1
-            fi
-          fi
-
-          echo "check-level=$check_level" >> "$GITHUB_OUTPUT"
-        env:
-          GH_TOKEN: ${{ github.token }}
-
-      - name: Configure build matrix
-        id: set-matrix
-        uses: actions/github-script@v7
-        with:
-          script: |
-            const level = ${{ steps.set-level.outputs.check-level }};
-            console.log(`level: ${level}`);
-            // use large runners where available (original repo)
-            let large = ${{ github.repository == 'leanprover/lean4' }};
-            let matrix = [
-              {
-                // portable release build: use channel with older glibc (2.27)
-                "name": "Linux LLVM",
-                "os": "ubuntu-latest",
-                "release": false,
-                "check-level": 2,
-                "shell": "nix develop .#oldGlibc -c bash -euxo pipefail {0}",
-                "llvm-url": "https://github.com/leanprover/lean-llvm/releases/download/15.0.1/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
-                // reverse-ffi needs to be updated to link to LLVM libraries
-                "CTEST_OPTIONS": "-E 'foreign|leanlaketest_reverse-ffi'",
-                "CMAKE_OPTIONS": "-DLLVM=ON -DLLVM_CONFIG=${GITHUB_WORKSPACE}/build/llvm-host/bin/llvm-config"
-              },
-              {
-                "name": "Linux release",
-                "os": large ? "nscloud-ubuntu-22.04-amd64-4x8" : "ubuntu-latest",
-                "release": true,
-                "check-level": 0,
-                "shell": "nix develop .#oldGlibc -c bash -euxo pipefail {0}",
-                "llvm-url": "https://github.com/leanprover/lean-llvm/releases/download/15.0.1/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'"
-              },
-              {
-                "name": "Linux",
-                "os": large ? "nscloud-ubuntu-22.04-amd64-4x8" : "ubuntu-latest",
-                "check-stage3": level >= 2,
-                "test-speedcenter": level >= 2,
-                "check-level": 1,
-              },
-              {
-                "name": "Linux Debug",
-                "os": "ubuntu-latest",
-                "check-level": 2,
-                "CMAKE_PRESET": "debug",
-                // exclude seriously slow tests
-                "CTEST_OPTIONS": "-E 'interactivetest|leanpkgtest|laketest|benchtest|bv_bitblast_stress'"
-              },
-              // TODO: suddenly started failing in CI
-              /*{
-                "name": "Linux fsanitize",
-                "os": "ubuntu-latest",
-                "check-level": 2,
-                // turn off custom allocator & symbolic functions to make LSAN do its magic
-                "CMAKE_PRESET": "sanitize",
-                // exclude seriously slow/problematic tests (laketests crash)
-                "CTEST_OPTIONS": "-E 'interactivetest|leanpkgtest|laketest|benchtest'"
-              },*/
-              {
-                "name": "macOS",
-                "os": "macos-13",
-                "release": true,
-                "check-level": 2,
-                "shell": "bash -euxo pipefail {0}",
-                "llvm-url": "https://github.com/leanprover/lean-llvm/releases/download/15.0.1/lean-llvm-x86_64-apple-darwin.tar.zst",
-                "prepare-llvm": "../script/prepare-llvm-macos.sh lean-llvm*",
-                "binary-check": "otool -L",
-                "tar": "gtar" // https://github.com/actions/runner-images/issues/2619
-              },
-              {
-                "name": "macOS aarch64",
-                "os": "macos-14",
-                "CMAKE_OPTIONS": "-DLEAN_INSTALL_SUFFIX=-darwin_aarch64",
-                "release": true,
-                "check-level": 0,
-                "shell": "bash -euxo pipefail {0}",
-                "llvm-url": "https://github.com/leanprover/lean-llvm/releases/download/15.0.1/lean-llvm-aarch64-apple-darwin.tar.zst",
-                "prepare-llvm": "../script/prepare-llvm-macos.sh lean-llvm*",
-                "binary-check": "otool -L",
-                "tar": "gtar" // https://github.com/actions/runner-images/issues/2619
-              },
-              {
-                "name": "Windows",
-                "os": "windows-2022",
-                "release": true,
-                "check-level": 2,
-                "shell": "msys2 {0}",
-                "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/15.0.1/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": "nscloud-ubuntu-22.04-arm64-4x8",
-                "CMAKE_OPTIONS": "-DLEAN_INSTALL_SUFFIX=-linux_aarch64",
-                "release": true,
-                "check-level": 2,
-                "shell": "nix develop .#oldGlibcAArch -c bash -euxo pipefail {0}",
-                "llvm-url": "https://github.com/leanprover/lean-llvm/releases/download/15.0.1/lean-llvm-aarch64-linux-gnu.tar.zst",
-                "prepare-llvm": "../script/prepare-llvm-linux.sh lean-llvm*"
-              },
-              {
-                "name": "Linux 32bit",
-                "os": "ubuntu-latest",
-                // Use 32bit on stage0 and stage1 to keep oleans compatible
-                "CMAKE_OPTIONS": "-DSTAGE0_USE_GMP=OFF -DSTAGE0_LEAN_EXTRA_CXX_FLAGS='-m32' -DSTAGE0_LEANC_OPTS='-m32' -DSTAGE0_MMAP=OFF -DUSE_GMP=OFF -DLEAN_EXTRA_CXX_FLAGS='-m32' -DLEANC_OPTS='-m32' -DMMAP=OFF -DLEAN_INSTALL_SUFFIX=-linux_x86 -DCMAKE_LIBRARY_PATH=/usr/lib/i386-linux-gnu/ -DSTAGE0_CMAKE_LIBRARY_PATH=/usr/lib/i386-linux-gnu/",
-                "cmultilib": true,
-                "release": true,
-                "check-level": 2,
-                "cross": true,
-                "shell": "bash -euxo pipefail {0}"
-              }
-              // {
-              //   "name": "Web Assembly",
-              //   "os": "ubuntu-latest",
-              //   // Build a native 32bit binary in stage0 and use it to compile the oleans and the wasm build
-              //   "CMAKE_OPTIONS": "-DCMAKE_C_COMPILER_WORKS=1 -DSTAGE0_USE_GMP=OFF -DSTAGE0_LEAN_EXTRA_CXX_FLAGS='-m32' -DSTAGE0_LEANC_OPTS='-m32' -DSTAGE0_CMAKE_CXX_COMPILER=clang++ -DSTAGE0_CMAKE_C_COMPILER=clang -DSTAGE0_CMAKE_EXECUTABLE_SUFFIX=\"\" -DUSE_GMP=OFF -DMMAP=OFF -DSTAGE0_MMAP=OFF -DCMAKE_AR=../emsdk/emsdk-main/upstream/emscripten/emar -DCMAKE_TOOLCHAIN_FILE=../emsdk/emsdk-main/upstream/emscripten/cmake/Modules/Platform/Emscripten.cmake -DLEAN_INSTALL_SUFFIX=-linux_wasm32 -DSTAGE0_CMAKE_LIBRARY_PATH=/usr/lib/i386-linux-gnu/",
-              //   "wasm": true,
-              //   "cmultilib": true,
-              //   "release": true,
-              //   "check-level": 2,
-              //   "cross": true,
-              //   "shell": "bash -euxo pipefail {0}",
-              //   // Just a few selected tests because wasm is slow
-              //   "CTEST_OPTIONS": "-R \"leantest_1007\\.lean|leantest_Format\\.lean|leanruntest\\_1037.lean|leanruntest_ac_rfl\\.lean|leanruntest_tempfile.lean\\.|leanruntest_libuv\\.lean\""
-              // }
-            ];
-            console.log(`matrix:\n${JSON.stringify(matrix, null, 2)}`)
-            return matrix.filter((job) => level >= job["check-level"])
-
   build:
-    needs: [configure]
+    needs: set-nightly
     if: github.event_name != 'schedule' || github.repository == 'leanprover/lean4'
-    strategy:
-      matrix:
-        include: ${{fromJson(needs.configure.outputs.matrix)}}
-      # complete all jobs
-      fail-fast: false
     runs-on: ${{ matrix.os }}
     defaults:
       run:
-        shell: ${{ matrix.shell || 'nix develop -c bash -euxo pipefail {0}' }}
+        shell: ${{ matrix.shell || 'nix-shell --run "bash -euxo pipefail {0}"' }}
+    strategy:
+      matrix:
+        include:
+          # portable release build: use channel with older glibc (2.27)
+          - name: Linux release
+            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/15.0.1/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
+            test-speedcenter: true
+          - name: Linux Debug
+            os: ubuntu-latest
+            CMAKE_OPTIONS: -DCMAKE_BUILD_TYPE=Debug
+            # exclude seriously slow tests
+            CTEST_OPTIONS: -E 'interactivetest|leanpkgtest|laketest'
+          - name: Linux fsanitize
+            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 seriously slow/problematic tests (laketests crash)
+            CTEST_OPTIONS: -E 'interactivetest|leanpkgtest|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/15.0.1/lean-llvm-x86_64-apple-darwin.tar.zst
+            prepare-llvm: ../script/prepare-llvm-macos.sh lean-llvm*
+            binary-check: otool -L
+            tar: gtar  # https://github.com/actions/runner-images/issues/2619
+          - 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/15.0.1/lean-llvm-aarch64-apple-darwin.tar.zst https://github.com/leanprover/lean-llvm/releases/download/15.0.1/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
+            tar: gtar  # https://github.com/actions/runner-images/issues/2619
+          - name: Windows
+            os: windows-2022
+            release: true
+            shell: msys2 {0}
+            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/15.0.1/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/15.0.1/lean-llvm-x86_64-linux-gnu.tar.zst https://github.com/leanprover/lean-llvm/releases/download/15.0.1/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 }}
     env:
       # must be inside workspace
@@ -287,123 +125,82 @@ jobs:
       LSAN_OPTIONS: max_leaks=10
       # somehow MinGW clang64 (or cmake?) defaults to `g++` even though it doesn't exist
       CXX: c++
-      MACOSX_DEPLOYMENT_TARGET: 10.15
     steps:
+      - name: Checkout
+        uses: actions/checkout@v3
+        with:
+          submodules: true
       - name: Install Nix
-        uses: DeterminateSystems/nix-installer-action@main
-        if: runner.os == 'Linux' && !matrix.cmultilib
+        uses: cachix/install-nix-action@v18
+        with:
+          install_url: https://releases.nixos.org/nix/nix-2.12.0/install
+        if: matrix.os == 'ubuntu-latest'
       - name: Install MSYS2
         uses: msys2/setup-msys2@v2
         with:
           msystem: clang64
-          # `:` means do not prefix with msystem
-          pacboy: "make: python: cmake clang ccache gmp libuv git: zip: unzip: diffutils: binutils: tree: zstd tar:"
-        if: runner.os == 'Windows'
+          # `: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: |
-          brew install ccache tree zstd coreutils gmp libuv
-        if: runner.os == 'macOS'
-      - name: Checkout
-        uses: actions/checkout@v4
-        with:
-          # the default is to use a virtual merge commit between the PR and master: just use the PR
-          ref: ${{ github.event.pull_request.head.sha }}
-      # Do check out some CI-relevant files from virtual merge commit to accommodate CI changes on
-      # master (as the workflow files themselves are always taken from the merge)
-      # (needs to be after "Install *" to use the right shell)
-      - name: CI Merge Checkout
-        run: |
-          git fetch --depth=1 origin ${{ github.sha }}
-          git checkout FETCH_HEAD flake.nix flake.lock
-        if: github.event_name == 'pull_request'
-      # (needs to be after "Checkout" so files don't get overridden)
-      - name: Setup emsdk
-        uses: mymindstorm/setup-emsdk@v14
-        with:
-          version: 3.1.44
-          actions-cache-folder: emsdk
-        if: matrix.wasm
-      - name: Install 32bit c libs
-        run: |
-          sudo dpkg --add-architecture i386
-          sudo apt-get update
-          sudo apt-get install -y gcc-multilib g++-multilib ccache libuv1-dev:i386
-        if: matrix.cmultilib
+          brew install ccache tree zstd coreutils gmp
+        if: matrix.os == 'macos-latest'
       - name: Cache
-        uses: actions/cache@v4
+        uses: actions/cache@v3
         with:
           path: .ccache
-          key: ${{ matrix.name }}-build-v3-${{ github.event.pull_request.head.sha }}
+          key: ${{ matrix.name }}-build-v3-${{ github.sha }}
           # fall back to (latest) previous cache
           restore-keys: |
             ${{ matrix.name }}-build-v3
-          save-always: true
-      # open nix-shell once for initial setup
       - name: Setup
         run: |
-          ccache --zero-stats
-        if: runner.os == 'Linux'
-      - name: Set up NPROC
+          # open nix-shell once for initial setup
+          true
+        if: matrix.os == 'ubuntu-latest'
+      - name: Set up core dumps
         run: |
-          echo "NPROC=$(nproc 2>/dev/null || sysctl -n hw.logicalcpu 2>/dev/null || echo 4)" >> $GITHUB_ENV
+          mkdir -p $PWD/coredumps
+          # store in current directory, for easy uploading together with binary
+          echo $PWD/coredumps/%e.%p.%t | sudo tee /proc/sys/kernel/core_pattern
+        if: matrix.os == 'ubuntu-latest'
       - name: Build
         run: |
           mkdir build
           cd build
-          # arguments passed to `cmake`
-          # this also enables githash embedding into stage 1 library
-          OPTIONS=(-DCHECK_OLEAN_VERSION=ON)
-          OPTIONS+=(-DLEAN_EXTRA_MAKE_OPTS=-DwarningAsError=true)
-          if [[ -n '${{ matrix.cross_target }}' ]]; then
-            # used by `prepare-llvm`
-            export EXTRA_FLAGS=--target=${{ matrix.cross_target }}
-            OPTIONS+=(-DLEAN_PLATFORM_TARGET=${{ matrix.cross_target }})
-          fi
+          ulimit -c unlimited # coredumps
+          OPTIONS=()
           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.configure.outputs.nightly }}' ]]; then
-            OPTIONS+=(-DLEAN_SPECIAL_VERSION_DESC=${{ needs.configure.outputs.nightly }})
-          fi
-          if [[ -n '${{ matrix.release }}' && -n '${{ needs.configure.outputs.RELEASE_TAG }}' ]]; then
-            OPTIONS+=(-DLEAN_VERSION_MAJOR=${{ needs.configure.outputs.LEAN_VERSION_MAJOR }})
-            OPTIONS+=(-DLEAN_VERSION_MINOR=${{ needs.configure.outputs.LEAN_VERSION_MINOR }})
-            OPTIONS+=(-DLEAN_VERSION_PATCH=${{ needs.configure.outputs.LEAN_VERSION_PATCH }})
-            OPTIONS+=(-DLEAN_VERSION_IS_RELEASE=1)
-            OPTIONS+=(-DLEAN_SPECIAL_VERSION_DESC=${{ needs.configure.outputs.LEAN_SPECIAL_VERSION_DESC }})
+          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 .. --preset ${{ matrix.CMAKE_PRESET || 'release' }} -B . ${{ matrix.CMAKE_OPTIONS }} ${OPTIONS[@]+"${OPTIONS[@]}"} -DLEAN_INSTALL_PREFIX=$PWD/..
-          time make -j$NPROC
-      - name: Install
-        run: |
-          make -C build install
+          cmake .. ${{ matrix.CMAKE_OPTIONS }} ${OPTIONS[@]+"${OPTIONS[@]}"} -DLEAN_INSTALL_PREFIX=$PWD/..
+          make -j4
+          make install
       - name: Check Binaries
         run: ${{ matrix.binary-check }} lean-*/bin/* || true
-      - name: Count binary symbols
-        run: |
-          for f in lean-*/bin/*; do
-            echo "$f: $(nm $f | grep " T " | wc -l) exported symbols"
-          done
-        if: matrix.name == 'Windows'
       - name: List Install Tree
         run: |
           # omit contents of Init/, ...
-          tree --du -h lean-*-* | grep -E ' (Init|Lean|Lake|LICENSE|[a-z])'
+          tree --du -h lean-* | grep -E ' (Init|Lean|Lake|LICENSE|[a-z])'
       - name: Pack
         run: |
-          dir=$(echo lean-*-*)
+          dir=$(echo lean-*)
           mkdir pack
           # high-compression tar.zst + zip for release, fast tar.zst otherwise
-          if [[ '${{ startsWith(github.ref, 'refs/tags/') && matrix.release }}' == true || -n '${{ needs.configure.outputs.nightly }}' || -n '${{ needs.configure.outputs.RELEASE_TAG }}' ]]; then
+          if [[ '${{ startsWith(github.ref, 'refs/tags/') && matrix.release }}' == true || -n '${{ needs.set-nightly.outputs.nightly }}' ]]; then
             ${{ matrix.tar || 'tar' }} cf - $dir | zstd -T0 --no-progress -19 -o pack/$dir.tar.zst
             zip -rq pack/$dir.zip $dir
           else
             ${{ matrix.tar || 'tar' }} cf - $dir | zstd -T0 --no-progress -o pack/$dir.tar.zst
           fi
-      - uses: actions/upload-artifact@v4
+      - uses: actions/upload-artifact@v3
         if: matrix.release
         with:
           name: build-${{ matrix.name }}
@@ -413,146 +210,114 @@ jobs:
           build/stage1/bin/lean --stats src/Lean.lean
         if: ${{ !matrix.cross }}
       - name: Test
-        id: test
         run: |
-          time ctest --preset ${{ matrix.CMAKE_PRESET || 'release' }} --test-dir build/stage1 -j$NPROC --output-junit test-results.xml ${{ matrix.CTEST_OPTIONS }}
-        if: (matrix.wasm || !matrix.cross) && needs.configure.outputs.check-level >= 1
-      - name: Test Summary
-        uses: test-summary/action@v2
-        with:
-          paths: build/stage1/test-results.xml
-        # prefix `if` above with `always` so it's run even if tests failed
-        if: always() && steps.test.conclusion != 'skipped'
+          cd build/stage1
+          ulimit -c unlimited # coredumps
+          # 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) && steps.test.conclusion != 'skipped'
+        if: ${{ !matrix.cross }}
       - name: Build Stage 2
         run: |
-          make -C build -j$NPROC stage2
-        if: matrix.test-speedcenter
+          cd build
+          ulimit -c unlimited # coredumps
+          make -j4 stage2
+        if: matrix.build-stage2 || matrix.check-stage3
       - name: Check Stage 3
         run: |
-          make -C build -j$NPROC check-stage3
-        if: matrix.test-speedcenter
+          cd build
+          ulimit -c unlimited # coredumps
+          make -j4 check-stage3
+        if: matrix.check-stage3
       - name: Test Speedcenter Benchmarks
         run: |
-          # Necessary for some timing metrics but does not work on Namespace runners
-          # and we just want to test that the benchmarks run at all here
-          #echo -1 | sudo tee /proc/sys/kernel/perf_event_paranoid
+          echo -1 | sudo tee /proc/sys/kernel/perf_event_paranoid
           export BUILD=$PWD/build PATH=$PWD/build/stage1/bin:$PATH
           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: |
-          # clean rebuild in case of Makefile changes
-          make -C build update-stage0 && rm -rf build/stage* && make -C build -j$NPROC
-        if: matrix.name == 'Linux' && needs.configure.outputs.check-level >= 1
+          cd build
+          ulimit -c unlimited # coredumps
+          make update-stage0 && make -j4
+        if: matrix.name == 'Linux'
       - name: CCache stats
         run: ccache -s
+      - name: Show stacktrace for coredumps
+        if: ${{ failure() }} && matrix.os == 'ubuntu-latest'
+        run: |
+          for c in coredumps/*; do
+            progbin="$(file $c | sed "s/.*execfn: '\([^']*\)'.*/\1/")"
+            echo bt | $GDB/bin/gdb -q $progbin $c || true
+          done
+      - name: Upload coredumps
+        uses: actions/upload-artifact@v3
+        if: ${{ failure() }} && matrix.os == 'ubuntu-latest'
+        with:
+          name: coredumps-${{ matrix.name }}
+          path: |
+            ./coredumps
+            ./build/stage0/bin/lean
+            ./build/stage0/lib/lean/libleanshared.so
+            ./build/stage1/bin/lean
+            ./build/stage1/lib/lean/libleanshared.so
+            ./build/stage2/bin/lean
+            ./build/stage2/lib/lean/libleanshared.so
 
-  # This job collects results from all the matrix jobs
-  # This can be made the "required" job, instead of listing each
-  # matrix job separately
-  all-done:
-    name: Build matrix complete
-    runs-on: ubuntu-latest
-    needs: build
-    # mark as merely cancelled not failed if builds are cancelled
-    if: ${{ !cancelled() }}
-    steps:
-    - if: ${{ contains(needs.*.result, 'failure') && github.repository == 'leanprover/lean4' && github.ref_name == 'master' }}
-      uses: zulip/github-actions-zulip/send-message@v1
-      with:
-        api-key: ${{ secrets.ZULIP_BOT_KEY }}
-        email: "github-actions-bot@lean-fro.zulipchat.com"
-        organization-url: "https://lean-fro.zulipchat.com"
-        to: "infrastructure"
-        topic: "Github actions"
-        type: "stream"
-        content: |
-          A build of `${{ github.ref_name }}`, triggered by event `${{ github.event_name }}`, [failed](https://github.com/${{ github.repository }}/actions/runs/${{ github.run_id }}).
-    - if: contains(needs.*.result, 'failure')
-      uses: actions/github-script@v7
-      with:
-        script: |
-            core.setFailed('Some jobs failed')
-
-
-  # This job creates releases from tags
-  # (whether they are "unofficial" releases for experiments, or official releases when the tag is "v" followed by a semver string.)
-  # We do not attempt to automatically construct a changelog here:
-  # unofficial releases don't need them, and official release notes will be written by a human.
   release:
     if: startsWith(github.ref, 'refs/tags/')
     runs-on: ubuntu-latest
     needs: build
     steps:
-      - uses: actions/download-artifact@v4
+      - uses: actions/download-artifact@v3
         with:
           path: artifacts
       - name: Release
-        uses: softprops/action-gh-release@v2
+        uses: softprops/action-gh-release@v1
         with:
           files: artifacts/*/*
           fail_on_unmatched_files: true
-          prerelease: ${{ !startsWith(github.ref, 'refs/tags/v') || contains(github.ref, '-rc') }}
         env:
           GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
-      - name: Update release.lean-lang.org
-        run: |
-          gh workflow -R leanprover/release-index run update-index.yml
-        env:
-          GITHUB_TOKEN: ${{ secrets.RELEASE_INDEX_TOKEN }}
 
-  # This job creates nightly releases during the cron job.
-  # It is responsible for creating the tag, and automatically generating a changelog.
   release-nightly:
-    needs: [configure, build]
-    if: needs.configure.outputs.nightly
+    needs: [set-nightly, build]
+    if: needs.set-nightly.outputs.nightly
     runs-on: ubuntu-latest
     steps:
       - name: Checkout
-        uses: actions/checkout@v4
+        uses: actions/checkout@v3
         with:
           # needed for tagging
           fetch-depth: 0
           token: ${{ secrets.PUSH_NIGHTLY_TOKEN }}
-      - uses: actions/download-artifact@v4
+      - uses: actions/download-artifact@v3
         with:
           path: artifacts
       - name: Prepare Nightly Release
         run: |
           git remote add nightly https://foo:'${{ secrets.PUSH_NIGHTLY_TOKEN }}'@github.com/${{ github.repository_owner }}/lean4-nightly.git
           git fetch nightly --tags
-          git tag "${{ needs.configure.outputs.nightly }}"
-          git push nightly "${{ needs.configure.outputs.nightly }}"
-          git push -f origin refs/tags/${{ needs.configure.outputs.nightly }}:refs/heads/nightly
-          last_tag="$(git log HEAD^ --simplify-by-decoration --pretty="format:%d" | grep -o "nightly-[-0-9]*" | head -n 1)"
+          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
+          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
+          git log --oneline $last_tag..HEAD | sed 's/^/* /' >> diff.md
       - name: Release Nightly
-        uses: softprops/action-gh-release@v2
+        uses: softprops/action-gh-release@v1
         with:
           body_path: diff.md
           prerelease: true
           files: artifacts/*/*
           fail_on_unmatched_files: true
-          tag_name: ${{ needs.configure.outputs.nightly }}
+          tag_name: ${{ needs.set-nightly.outputs.nightly }}
           repository: ${{ github.repository_owner }}/lean4-nightly
         env:
           GITHUB_TOKEN: ${{ secrets.PUSH_NIGHTLY_TOKEN }}
-      - name: Update release.lean-lang.org
-        run: |
-          gh workflow -R leanprover/release-index run update-index.yml
-        env:
-          GITHUB_TOKEN: ${{ secrets.RELEASE_INDEX_TOKEN }}
-      - name: Update toolchain on mathlib4's nightly-testing branch
-        run: |
-          gh workflow -R leanprover-community/mathlib4 run nightly_bump_toolchain.yml
-        env:
-          GITHUB_TOKEN: ${{ secrets.MATHLIB4_BOT }}

.github/workflows/copyright-header.yml

@@ -1,20 +0,0 @@
-name: Check for copyright header
-
-on: [pull_request]
-
-jobs:
-  check-lean-files:
-    runs-on: ubuntu-latest
-    steps:
-    - uses: actions/checkout@v4
-
-    - name: Verify .lean files start with a copyright header.
-      run: |
-        FILES=$(find ./src -type d \( -path "./src/lake/examples" -o -path "./src/lake/tests" \) -prune -o -type f -name "*.lean" -exec perl -ne 'BEGIN { $/ = undef; } print "$ARGV\n" if !m{\A/-\nCopyright}; exit;' {} \;)
-        if [ -n "$FILES" ]; then
-          echo "Found .lean files which do not have a copyright header:"
-          echo "$FILES"
-          exit 1
-        else
-          echo "All copyright headers present."
-        fi

.github/workflows/jira.yml

@@ -1,34 +0,0 @@
-name: Jira sync
-
-on:
-  issues:
-    types: [closed]
-
-jobs:
-  jira-sync:
-    runs-on: ubuntu-latest
-
-    steps:
-      - name: Move Jira issue to Done
-        env:
-          JIRA_API_TOKEN: ${{ secrets.JIRA_API_TOKEN }}
-          JIRA_USERNAME: ${{ secrets.JIRA_USERNAME }}
-          JIRA_BASE_URL: ${{ secrets.JIRA_BASE_URL }}
-        run: |
-          issue_number=${{ github.event.issue.number }}
-
-          jira_issue_key=$(curl -s -u "${JIRA_USERNAME}:${JIRA_API_TOKEN}" \
-            -X GET -H "Content-Type: application/json" \
-            "${JIRA_BASE_URL}/rest/api/2/search?jql=summary~\"${issue_number}\"" | \
-            jq -r '.issues[0].key')
-
-          if [ -z "$jira_issue_key" ]; then
-            exit
-          fi
-
-          curl -s -u "${JIRA_USERNAME}:${JIRA_API_TOKEN}" \
-            -X POST -H "Content-Type: application/json" \
-            --data "{\"transition\": {\"id\": \"41\"}}" \
-            "${JIRA_BASE_URL}/rest/api/2/issue/${jira_issue_key}/transitions"
-
-          echo "Moved Jira issue ${jira_issue_key} to Done"

.github/workflows/labels-from-comments.yml

@@ -1,67 +0,0 @@
-# This workflow allows any user to add one of the `awaiting-review`, `awaiting-author`, `WIP`,
-# `release-ci`, or a `changelog-XXX` label by commenting on the PR or issue.
-# If any labels from the set {`awaiting-review`, `awaiting-author`, `WIP`} are added, other labels
-# from that set are removed automatically at the same time.
-# Similarly, if any `changelog-XXX` label is added, other `changelog-YYY` labels are removed.
-
-name: Label PR based on Comment
-
-on:
-  issue_comment:
-    types: [created]
-
-jobs:
-  update-label:
-    if: github.event.issue.pull_request != null && (contains(github.event.comment.body, 'awaiting-review') || contains(github.event.comment.body, 'awaiting-author') || contains(github.event.comment.body, 'WIP') || contains(github.event.comment.body, 'release-ci') || contains(github.event.comment.body, 'changelog-'))
-    runs-on: ubuntu-latest
-
-    steps:
-    - name: Add label based on comment
-      uses: actions/github-script@v7
-      with:
-        github-token: ${{ secrets.GITHUB_TOKEN }}
-        script: |
-          const { owner, repo, number: issue_number } = context.issue;
-          const commentLines = context.payload.comment.body.split('\r\n');
-
-          const awaitingReview = commentLines.includes('awaiting-review');
-          const awaitingAuthor = commentLines.includes('awaiting-author');
-          const wip = commentLines.includes('WIP');
-          const releaseCI = commentLines.includes('release-ci');
-          const changelogMatch = commentLines.find(line => line.startsWith('changelog-'));
-
-          if (awaitingReview || awaitingAuthor || wip) {
-            await github.rest.issues.removeLabel({ owner, repo, issue_number, name: 'awaiting-review' }).catch(() => {});
-            await github.rest.issues.removeLabel({ owner, repo, issue_number, name: 'awaiting-author' }).catch(() => {});
-            await github.rest.issues.removeLabel({ owner, repo, issue_number, name: 'WIP' }).catch(() => {});
-          }
-
-          if (awaitingReview) {
-            await github.rest.issues.addLabels({ owner, repo, issue_number, labels: ['awaiting-review'] });
-          }
-          if (awaitingAuthor) {
-            await github.rest.issues.addLabels({ owner, repo, issue_number, labels: ['awaiting-author'] });
-          }
-          if (wip) {
-            await github.rest.issues.addLabels({ owner, repo, issue_number, labels: ['WIP'] });
-          }
-
-          if (releaseCI) {
-            await github.rest.issues.addLabels({ owner, repo, issue_number, labels: ['release-ci'] });
-          }
-
-          if (changelogMatch) {
-            const changelogLabel = changelogMatch.trim();
-            const { data: existingLabels } = await github.rest.issues.listLabelsOnIssue({ owner, repo, issue_number });
-            const changelogLabels = existingLabels.filter(label => label.name.startsWith('changelog-'));
-
-            // Remove all other changelog labels
-            for (const label of changelogLabels) {
-              if (label.name !== changelogLabel) {
-                await github.rest.issues.removeLabel({ owner, repo, issue_number, name: label.name }).catch(() => {});
-              }
-            }
-
-            // Add the new changelog label
-            await github.rest.issues.addLabels({ owner, repo, issue_number, labels: [changelogLabel] });
-          }

.github/workflows/nix-ci.yml

@@ -6,137 +6,106 @@ on:
     tags:
       - '*'
   pull_request:
-  merge_group:
+    branches:
+      - master
 
 concurrency:
   group: ${{ github.workflow }}-${{ github.ref }}
   cancel-in-progress: true
 
 jobs:
-  # see ci.yml
-  configure:
-    runs-on: ubuntu-latest
-    outputs:
-      matrix: ${{ steps.set-matrix.outputs.result }}
-    steps:
-      - name: Configure build matrix
-        id: set-matrix
-        uses: actions/github-script@v7
-        with:
-          script: |
-            let large = ${{ github.repository == 'leanprover/lean4' }};
-            let matrix = [
-              {
-                "name": "Nix Linux",
-                "os": large ? "nscloud-ubuntu-22.04-amd64-8x8" : "ubuntu-latest",
-              }
-            ];
-            console.log(`matrix:\n${JSON.stringify(matrix, null, 2)}`);
-            return matrix;
-
   Build:
-    needs: [configure]
     runs-on: ${{ matrix.os }}
     defaults:
       run:
-        shell: nix run .#ciShell -- bash -euxo pipefail {0}
+        shell: nix -v --experimental-features "nix-command flakes" run .#ciShell -- bash -euxo pipefail {0}
     strategy:
       matrix:
-        include: ${{fromJson(needs.configure.outputs.matrix)}}
+        include:
+          - name: Nix Linux
+            os: ubuntu-latest
+          #- name: Nix macOS
+          #  os: macos-latest
       # complete all jobs
       fail-fast: false
     name: ${{ matrix.name }}
     env:
-      NIX_BUILD_ARGS: --print-build-logs --fallback
+      NIX_BUILD_ARGS: -v --print-build-logs --fallback
     steps:
       - name: Checkout
-        uses: actions/checkout@v4
+        uses: actions/checkout@v3
+      - name: Install Nix
+        uses: cachix/install-nix-action@v18
         with:
-          # the default is to use a virtual merge commit between the PR and master: just use the PR
-          ref: ${{ github.event.pull_request.head.sha }}
+          # https://github.com/NixOS/nix/issues/6572
+          install_url: https://releases.nixos.org/nix/nix-2.7.0/install
+          extra_nix_config: |
+            extra-sandbox-paths = /nix/var/cache/ccache
+            substituters = file://${{ github.workspace }}/nix-store-cache-copy?priority=10&trusted=true https://cache.nixos.org
       - name: Set Up Nix Cache
-        uses: actions/cache@v4
+        uses: actions/cache@v3
         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
-          save-always: true
       - 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: Install Nix
-        uses: DeterminateSystems/nix-installer-action@main
-        with:
-          extra-conf: |
-            extra-sandbox-paths = /nix/var/cache/ccache?
-            substituters = file://${{ github.workspace }}/nix-store-cache-copy?priority=10&trusted=true https://cache.nixos.org  
       - name: Prepare CCache Cache
+        shell: bash -euxo pipefail {0}
         run: |
           sudo mkdir -m0770 -p /nix/var/cache/ccache
           sudo chown -R $USER /nix/var/cache/ccache
       - name: Setup CCache Cache
-        uses: actions/cache@v4
+        uses: actions/cache@v3
         with:
           path: /nix/var/cache/ccache
           key: ${{ matrix.name }}-nix-ccache-${{ github.sha }}
           # fall back to (latest) previous cache
           restore-keys: |
             ${{ matrix.name }}-nix-ccache
-          save-always: true
       - 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@v12
+        with:
+          name: lean4
+          authToken: '${{ secrets.CACHIX_AUTH_TOKEN }}'
+          skipPush: true  # we push specific outputs only
       - name: Build
         run: |
           nix build $NIX_BUILD_ARGS .#cacheRoots -o push-build
       - name: Test
         run: |
-          nix build --keep-failed $NIX_BUILD_ARGS .#test -o push-test || (ln -s /tmp/nix-build-*/build/source/src/build ./push-test; false)
-      - name: Test Summary
-        uses: test-summary/action@v2
-        with:
-          paths: push-test/test-results.xml
-        if: always()
-        continue-on-error: true
+          nix build $NIX_BUILD_ARGS .#test -o push-test
       - name: Build manual
         run: |
-          nix build $NIX_BUILD_ARGS --update-input lean --no-write-lock-file ./doc#{lean-mdbook,leanInk,alectryon,inked} -o push-doc
+          nix build $NIX_BUILD_ARGS --update-input lean --no-write-lock-file ./doc#{lean-mdbook,leanInk,alectryon,test,inked} -o push-doc
           nix build $NIX_BUILD_ARGS --update-input lean --no-write-lock-file ./doc
-          # https://github.com/netlify/cli/issues/1809
-          cp -r --dereference ./result ./dist
         if: matrix.name == 'Nix Linux'
+      - name: Push to Cachix
+        run: |
+          [ -z "${{ secrets.CACHIX_AUTH_TOKEN }}" ] || cachix push -j4 lean4 ./push-* || true
       - name: Rebuild Nix Store Cache
         run: |
           rm -rf nix-store-cache || true
           nix copy ./push-* --to file://$PWD/nix-store-cache?compression=none
-      - id: deploy-info
-        name: Compute Deployment Metadata
-        run: |
-          set -e
-          python3 -c 'import base64; print("alias="+base64.urlsafe_b64encode(bytes.fromhex("${{github.sha}}")).decode("utf-8").rstrip("="))' >> "$GITHUB_OUTPUT"
-          echo "message=`git log -1 --pretty=format:"%s"`" >> "$GITHUB_OUTPUT"
-      - name: Publish manual to Netlify
-        uses: nwtgck/actions-netlify@v3.0
-        id: publish-manual
+      - name: Publish manual
+        uses: peaceiris/actions-gh-pages@v3
         with:
-          publish-dir: ./dist
-          production-branch: master
-          github-token: ${{ secrets.GITHUB_TOKEN }}
-          deploy-message: |
-            ${{ github.event_name == 'pull_request' && format('pr#{0}: {1}', github.event.number, github.event.pull_request.title) || format('ref/{0}: {1}', github.ref_name, steps.deploy-info.outputs.message) }}
-          alias: ${{ steps.deploy-info.outputs.alias }}
-          enable-commit-comment: false
-          enable-pull-request-comment: false
-          github-deployment-environment: "lean-lang.org/lean4/doc"
-          fails-without-credentials: false
-        env:
-          NETLIFY_AUTH_TOKEN: ${{ secrets.NETLIFY_AUTH_TOKEN }}
-          NETLIFY_SITE_ID: "b8e805d2-7e9b-4f80-91fb-a84d72fc4a68"
+          github_token: ${{ secrets.GITHUB_TOKEN }}
+          publish_dir: ./result
+          destination_dir: ./doc
+        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
+      - name: CCache stats
+        run: CCACHE_DIR=/nix/var/cache/ccache nix run .#nixpkgs.ccache -- -s

.github/workflows/pr-body.yml

@@ -1,25 +0,0 @@
-name: Check PR body for changelog convention
-
-on:
-  merge_group:
-  pull_request:
-    types: [opened, synchronize, reopened, edited, labeled, converted_to_draft, ready_for_review]
-
-jobs:
-  check-pr-body:
-    runs-on: ubuntu-latest
-    steps:
-      - name: Check PR body
-        if: github.event_name == 'pull_request'
-        uses: actions/github-script@v7
-        with:
-          script: |
-            const { title, body, labels, draft } = context.payload.pull_request;
-            if (!draft && /^(feat|fix):/.test(title) && !labels.some(label => label.name == "changelog-no")) {
-              if (!labels.some(label => label.name.startsWith("changelog-"))) {
-                core.setFailed('feat/fix PR must have a `changelog-*` label');
-              }
-              if (!/^This PR [^<]/.test(body)) {
-                core.setFailed('feat/fix PR must have changelog summary starting with "This PR ..." as first line.');
-              }
-            }

.github/workflows/pr-release.yml

@@ -1,350 +0,0 @@
-# Push a release to the lean4-pr-releases repository, whenever someone pushes to a PR branch.
-
-# This needs to run with the `secrets.PR_RELEASES_TOKEN` token available,
-# but PR branches will generally come from forks,
-# so it is not possible to run this using the `pull_request` or `pull_request_target` workflows.
-# Instead we use `workflow_run`, which essentially allows us to escalate privileges
-# (but only runs the CI as described in the `master` branch, not in the PR branch).
-
-# The main specification/documentation for this workflow is at
-# https://leanprover-community.github.io/contribute/tags_and_branches.html
-# Keep that in sync!
-
-name: PR release
-
-on:
-  workflow_run: # https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run
-    workflows: [CI]
-    types: [completed]
-
-jobs:
-  on-success:
-    runs-on: ubuntu-latest
-    if: github.event.workflow_run.conclusion == 'success' && github.event.workflow_run.event == 'pull_request' && github.repository == 'leanprover/lean4'
-    steps:
-      - name: Retrieve information about the original workflow
-        uses: potiuk/get-workflow-origin@v1_1 # https://github.com/marketplace/actions/get-workflow-origin
-        # This action is deprecated and archived, but it seems hard to find a better solution for getting the PR number
-        # see https://github.com/orgs/community/discussions/25220 for some discussion
-        id: workflow-info
-        with:
-          token: ${{ secrets.GITHUB_TOKEN }}
-          sourceRunId: ${{ github.event.workflow_run.id }}
-
-      - name: Download artifact from the previous workflow.
-        if: ${{ steps.workflow-info.outputs.pullRequestNumber != '' }}
-        id: download-artifact
-        uses: dawidd6/action-download-artifact@v7 # https://github.com/marketplace/actions/download-workflow-artifact
-        with:
-          run_id: ${{ github.event.workflow_run.id }}
-          path: artifacts
-          name: build-.*
-          name_is_regexp: true
-
-      - name: Push tag
-        if: ${{ steps.workflow-info.outputs.pullRequestNumber != '' }}
-        run: |
-          git init --bare lean4.git
-          git -C lean4.git remote add origin https://github.com/${{ github.repository_owner }}/lean4.git
-          git -C lean4.git fetch -n origin master
-          git -C lean4.git fetch -n origin "${{ steps.workflow-info.outputs.sourceHeadSha }}"
-          git -C lean4.git tag -f pr-release-${{ steps.workflow-info.outputs.pullRequestNumber }} "${{ steps.workflow-info.outputs.sourceHeadSha }}"
-          git -C lean4.git remote add pr-releases https://foo:'${{ secrets.PR_RELEASES_TOKEN }}'@github.com/${{ github.repository_owner }}/lean4-pr-releases.git
-          git -C lean4.git push -f pr-releases pr-release-${{ steps.workflow-info.outputs.pullRequestNumber }}
-      - name: Delete existing release if present
-        if: ${{ steps.workflow-info.outputs.pullRequestNumber != '' }}
-        run: |
-          # Try to delete any existing release for the current PR.
-          gh release delete --repo ${{ github.repository_owner }}/lean4-pr-releases pr-release-${{ steps.workflow-info.outputs.pullRequestNumber }} -y || true
-        env:
-          GH_TOKEN: ${{ secrets.PR_RELEASES_TOKEN }}
-      - name: Release
-        if: ${{ steps.workflow-info.outputs.pullRequestNumber != '' }}
-        uses: softprops/action-gh-release@v2
-        with:
-          name: Release for PR ${{ steps.workflow-info.outputs.pullRequestNumber }}
-          # There are coredumps files here as well, but all in deeper subdirectories.
-          files: artifacts/*/*
-          fail_on_unmatched_files: true
-          draft: false
-          tag_name: pr-release-${{ steps.workflow-info.outputs.pullRequestNumber }}
-          repository: ${{ github.repository_owner }}/lean4-pr-releases
-        env:
-          # The token used here must have `workflow` privileges.
-          GITHUB_TOKEN: ${{ secrets.PR_RELEASES_TOKEN }}
-
-      - name: Report release status
-        if: ${{ steps.workflow-info.outputs.pullRequestNumber != '' }}
-        uses: actions/github-script@v7
-        with:
-          script: |
-            await github.rest.repos.createCommitStatus({
-              owner: context.repo.owner,
-              repo: context.repo.repo,
-              sha: "${{ steps.workflow-info.outputs.sourceHeadSha }}",
-              state: "success",
-              context: "PR toolchain",
-              description: "${{ github.repository_owner }}/lean4-pr-releases:pr-release-${{ steps.workflow-info.outputs.pullRequestNumber }}",
-            });
-
-      - name: Add label
-        if: ${{ steps.workflow-info.outputs.pullRequestNumber != '' }}
-        uses: actions/github-script@v7
-        with:
-          script: |
-            await github.rest.issues.addLabels({
-              issue_number: ${{ steps.workflow-info.outputs.pullRequestNumber }},
-              owner: context.repo.owner,
-              repo: context.repo.repo,
-              labels: ['toolchain-available']
-            })
-
-      # Next, determine the most recent nightly release in this PR's history.
-      - name: Find most recent nightly in feature branch
-        id: most-recent-nightly-tag
-        if: ${{ steps.workflow-info.outputs.pullRequestNumber != '' }}
-        run: |
-          git -C lean4.git remote add nightly https://github.com/leanprover/lean4-nightly.git
-          git -C lean4.git fetch nightly '+refs/tags/nightly-*:refs/tags/nightly-*'
-          git -C lean4.git tag --merged "${{ steps.workflow-info.outputs.sourceHeadSha }}" --list "nightly-*" \
-            | sort -rV | head -n 1 | sed "s/^nightly-*/MOST_RECENT_NIGHTLY=/" | tee -a "$GITHUB_ENV"
-
-      - name: 'Setup jq'
-        if: ${{ steps.workflow-info.outputs.pullRequestNumber != '' }}
-        uses: dcarbone/install-jq-action@v3.0.1
-
-      # Check that the most recently nightly coincides with 'git merge-base HEAD master'
-      - name: Check merge-base and nightly-testing-YYYY-MM-DD
-        if: ${{ steps.workflow-info.outputs.pullRequestNumber != '' }}
-        id: ready
-        run: |
-          echo "Most recent nightly release in your branch: $MOST_RECENT_NIGHTLY"
-          NIGHTLY_SHA=$(git -C lean4.git rev-parse "nightly-$MOST_RECENT_NIGHTLY^{commit}")
-          echo "SHA of most recent nightly release: $NIGHTLY_SHA"
-          MERGE_BASE_SHA=$(git -C lean4.git merge-base origin/master "${{ steps.workflow-info.outputs.sourceHeadSha }}")
-          echo "SHA of merge-base: $MERGE_BASE_SHA"
-          if [ "$NIGHTLY_SHA" = "$MERGE_BASE_SHA" ]; then
-            echo "The merge base of this PR coincides with the nightly release"
-
-            BATTERIES_REMOTE_TAGS="$(git ls-remote https://github.com/leanprover-community/batteries.git nightly-testing-"$MOST_RECENT_NIGHTLY")"
-            MATHLIB_REMOTE_TAGS="$(git ls-remote https://github.com/leanprover-community/mathlib4.git nightly-testing-"$MOST_RECENT_NIGHTLY")"
-
-            if [[ -n "$BATTERIES_REMOTE_TAGS" ]]; then
-              echo "... and Batteries has a 'nightly-testing-$MOST_RECENT_NIGHTLY' tag."
-              MESSAGE=""
-
-              if [[ -n "$MATHLIB_REMOTE_TAGS" ]]; then
-                echo "... and Mathlib has a 'nightly-testing-$MOST_RECENT_NIGHTLY' tag."
-              else
-                echo "... but Mathlib does not yet have a 'nightly-testing-$MOST_RECENT_NIGHTLY' tag."
-                MESSAGE="- ❗ Mathlib CI can not be attempted yet, as the \`nightly-testing-$MOST_RECENT_NIGHTLY\` tag does not exist there yet. We will retry when you push more commits. If you rebase your branch onto \`nightly-with-mathlib\`, Mathlib CI should run now."
-              fi
-            else
-              echo "... but Batteries does not yet have a 'nightly-testing-$MOST_RECENT_NIGHTLY' tag."
-              MESSAGE="- ❗ Batteries CI can not be attempted yet, as the \`nightly-testing-$MOST_RECENT_NIGHTLY\` tag does not exist there yet. We will retry when you push more commits. If you rebase your branch onto \`nightly-with-mathlib\`, Batteries CI should run now."
-            fi
-
-          else
-            echo "The most recently nightly tag on this branch has SHA: $NIGHTLY_SHA"
-            echo "but 'git merge-base origin/master HEAD' reported: $MERGE_BASE_SHA"
-            git -C lean4.git log -10 origin/master
-
-            git -C lean4.git fetch origin nightly-with-mathlib
-            NIGHTLY_WITH_MATHLIB_SHA="$(git -C lean4.git rev-parse "origin/nightly-with-mathlib")"
-            MESSAGE="- ❗ Batteries/Mathlib CI will not be attempted unless your PR branches off the \`nightly-with-mathlib\` branch. Try \`git rebase $MERGE_BASE_SHA --onto $NIGHTLY_WITH_MATHLIB_SHA\`."
-          fi
-
-          if [[ -n "$MESSAGE" ]]; then
-
-            echo "Checking existing messages"
-
-            # The code for updating comments is duplicated in mathlib's
-            # scripts/lean-pr-testing-comments.sh
-            # so keep in sync
-
-            # Use GitHub API to check if a comment already exists
-            existing_comment="$(curl --retry 3 --location --silent \
-                                    -H "Authorization: token ${{ secrets.MATHLIB4_COMMENT_BOT }}" \
-                                    -H "Accept: application/vnd.github.v3+json" \
-                                    "https://api.github.com/repos/leanprover/lean4/issues/${{ steps.workflow-info.outputs.pullRequestNumber }}/comments" \
-                                    | jq 'first(.[] | select(.body | test("^- . Mathlib") or startswith("Mathlib CI status")) | select(.user.login == "leanprover-community-bot"))')"
-            existing_comment_id="$(echo "$existing_comment" | jq -r .id)"
-            existing_comment_body="$(echo "$existing_comment" | jq -r .body)"
-
-            if [[ "$existing_comment_body" != *"$MESSAGE"* ]]; then
-              MESSAGE="$MESSAGE ($(date "+%Y-%m-%d %H:%M:%S"))"
-
-              echo "Posting message to the comments: $MESSAGE"
-
-              # Append new result to the existing comment or post a new comment
-              # It's essential we use the MATHLIB4_COMMENT_BOT token here, so that Mathlib CI can subsequently edit the comment.
-              if [ -z "$existing_comment_id" ]; then
-                INTRO="Mathlib CI status ([docs](https://leanprover-community.github.io/contribute/tags_and_branches.html)):"
-                # Post new comment with a bullet point
-                echo "Posting as new comment at leanprover/lean4/issues/${{ steps.workflow-info.outputs.pullRequestNumber }}/comments"
-                curl -L -s \
-                  -X POST \
-                  -H "Authorization: token ${{ secrets.MATHLIB4_COMMENT_BOT }}" \
-                  -H "Accept: application/vnd.github.v3+json" \
-                  -d "$(jq --null-input --arg intro "$INTRO" --arg val "$MESSAGE" '{"body":($intro + "\n" + $val)}')" \
-                  "https://api.github.com/repos/leanprover/lean4/issues/${{ steps.workflow-info.outputs.pullRequestNumber }}/comments"
-              else
-                # Append new result to the existing comment
-                echo "Appending to existing comment at leanprover/lean4/issues/${{ steps.workflow-info.outputs.pullRequestNumber }}/comments"
-                curl -L -s \
-                  -X PATCH \
-                  -H "Authorization: token ${{ secrets.MATHLIB4_COMMENT_BOT }}" \
-                  -H "Accept: application/vnd.github.v3+json" \
-                  -d "$(jq --null-input --arg existing "$existing_comment_body" --arg message "$MESSAGE" '{"body":($existing + "\n" + $message)}')" \
-                  "https://api.github.com/repos/leanprover/lean4/issues/comments/$existing_comment_id"
-              fi
-            else
-              echo "The message already exists in the comment body."
-            fi
-            echo "mathlib_ready=false" >> "$GITHUB_OUTPUT"
-          else
-            echo "mathlib_ready=true" >> "$GITHUB_OUTPUT"
-          fi
-
-      - name: Report mathlib base
-        if: ${{ steps.workflow-info.outputs.pullRequestNumber != '' && steps.ready.outputs.mathlib_ready == 'true' }}
-        uses: actions/github-script@v7
-        with:
-          script: |
-            const description =
-              process.env.MOST_RECENT_NIGHTLY ?
-              "nightly-" + process.env.MOST_RECENT_NIGHTLY :
-              "not branched off nightly";
-            await github.rest.repos.createCommitStatus({
-              owner: context.repo.owner,
-              repo: context.repo.repo,
-              sha: "${{ steps.workflow-info.outputs.sourceHeadSha }}",
-              state: "success",
-              context: "PR branched off:",
-              description: description,
-            });
-
-      # We next automatically create a Batteries branch using this toolchain.
-      # Batteries doesn't itself have a mechanism to report results of CI from this branch back to Lean
-      # Instead this is taken care of by Mathlib CI, which will fail if Batteries fails.
-      - name: Cleanup workspace
-        if: steps.workflow-info.outputs.pullRequestNumber != '' && steps.ready.outputs.mathlib_ready == 'true'
-        run: |
-          sudo rm -rf ./*
-
-      # Checkout the Batteries repository with all branches
-      - name: Checkout Batteries repository
-        if: steps.workflow-info.outputs.pullRequestNumber != '' && steps.ready.outputs.mathlib_ready == 'true'
-        uses: actions/checkout@v4
-        with:
-          repository: leanprover-community/batteries
-          token: ${{ secrets.MATHLIB4_BOT }}
-          ref: nightly-testing
-          fetch-depth: 0 # This ensures we check out all tags and branches.
-
-      - name: Check if tag exists
-        if: steps.workflow-info.outputs.pullRequestNumber != '' && steps.ready.outputs.mathlib_ready == 'true'
-        id: check_batteries_tag
-        run: |
-          git config user.name "leanprover-community-mathlib4-bot"
-          git config user.email "leanprover-community-mathlib4-bot@users.noreply.github.com"
-
-          if git ls-remote --heads --tags --exit-code origin "nightly-testing-${MOST_RECENT_NIGHTLY}" >/dev/null; then
-            BASE="nightly-testing-${MOST_RECENT_NIGHTLY}"
-          else
-            echo "This shouldn't be possible: couldn't find a 'nightly-testing-${MOST_RECENT_NIGHTLY}' tag at Batteries. Falling back to 'nightly-testing'."
-            BASE=nightly-testing
-          fi
-
-          echo "Using base branch: $BASE"
-
-          EXISTS="$(git ls-remote --heads origin lean-pr-testing-${{ steps.workflow-info.outputs.pullRequestNumber }} | wc -l)"
-          echo "Branch exists: $EXISTS"
-          if [ "$EXISTS" = "0" ]; then
-            echo "Branch does not exist, creating it."
-            git switch -c lean-pr-testing-${{ steps.workflow-info.outputs.pullRequestNumber }} "$BASE"
-            echo "leanprover/lean4-pr-releases:pr-release-${{ steps.workflow-info.outputs.pullRequestNumber }}" > lean-toolchain
-            git add lean-toolchain
-            git commit -m "Update lean-toolchain for testing https://github.com/leanprover/lean4/pull/${{ steps.workflow-info.outputs.pullRequestNumber }}"
-          else
-            echo "Branch already exists, pushing an empty commit."
-            git switch lean-pr-testing-${{ steps.workflow-info.outputs.pullRequestNumber }}
-            # The Batteries `nightly-testing` or `nightly-testing-YYYY-MM-DD` branch may have moved since this branch was created, so merge their changes.
-            # (This should no longer be possible once `nightly-testing-YYYY-MM-DD` is a tag, but it is still safe to merge.)
-            git merge "$BASE" --strategy-option ours --no-commit --allow-unrelated-histories
-            git commit --allow-empty -m "Trigger CI for https://github.com/leanprover/lean4/pull/${{ steps.workflow-info.outputs.pullRequestNumber }}"
-          fi
-
-      - name: Push changes
-        if: steps.workflow-info.outputs.pullRequestNumber != '' && steps.ready.outputs.mathlib_ready == 'true'
-        run: |
-          git push origin lean-pr-testing-${{ steps.workflow-info.outputs.pullRequestNumber }}
-
-
-      # We next automatically create a Mathlib branch using this toolchain.
-      # Mathlib CI will be responsible for reporting back success or failure
-      # to the PR comments asynchronously.
-      - name: Cleanup workspace
-        if: steps.workflow-info.outputs.pullRequestNumber != '' && steps.ready.outputs.mathlib_ready == 'true'
-        run: |
-          sudo rm -rf ./*
-
-      # Checkout the mathlib4 repository with all branches
-      - name: Checkout mathlib4 repository
-        if: steps.workflow-info.outputs.pullRequestNumber != '' && steps.ready.outputs.mathlib_ready == 'true'
-        uses: actions/checkout@v4
-        with:
-          repository: leanprover-community/mathlib4
-          token: ${{ secrets.MATHLIB4_BOT }}
-          ref: nightly-testing
-          fetch-depth: 0 # This ensures we check out all tags and branches.
-
-      - name: install elan
-        run: |
-          set -o pipefail
-          curl -sSfL https://github.com/leanprover/elan/releases/download/v3.0.0/elan-x86_64-unknown-linux-gnu.tar.gz | tar xz
-          ./elan-init -y --default-toolchain none
-          echo "$HOME/.elan/bin" >> "${GITHUB_PATH}"
-
-      - name: Check if tag exists
-        if: steps.workflow-info.outputs.pullRequestNumber != '' && steps.ready.outputs.mathlib_ready == 'true'
-        id: check_mathlib_tag
-        run: |
-          git config user.name "leanprover-community-mathlib4-bot"
-          git config user.email "leanprover-community-mathlib4-bot@users.noreply.github.com"
-
-          if git ls-remote --heads --tags --exit-code origin "nightly-testing-${MOST_RECENT_NIGHTLY}" >/dev/null; then
-            BASE="nightly-testing-${MOST_RECENT_NIGHTLY}"
-          else
-            echo "This shouldn't be possible: couldn't find a 'nightly-testing-${MOST_RECENT_NIGHTLY}' branch at Mathlib. Falling back to 'nightly-testing'."
-            BASE=nightly-testing
-          fi
-
-          echo "Using base tag: $BASE"
-
-          EXISTS="$(git ls-remote --heads origin lean-pr-testing-${{ steps.workflow-info.outputs.pullRequestNumber }} | wc -l)"
-          echo "Branch exists: $EXISTS"
-          if [ "$EXISTS" = "0" ]; then
-            echo "Branch does not exist, creating it."
-            git switch -c lean-pr-testing-${{ steps.workflow-info.outputs.pullRequestNumber }} "$BASE"
-            echo "leanprover/lean4-pr-releases:pr-release-${{ steps.workflow-info.outputs.pullRequestNumber }}" > lean-toolchain
-            git add lean-toolchain
-            sed -i 's,require "leanprover-community" / "batteries" @ git ".\+",require "leanprover-community" / "batteries" @ git "lean-pr-testing-${{ steps.workflow-info.outputs.pullRequestNumber }}",' lakefile.lean
-            lake update batteries
-            git add lakefile.lean lake-manifest.json
-            git commit -m "Update lean-toolchain for testing https://github.com/leanprover/lean4/pull/${{ steps.workflow-info.outputs.pullRequestNumber }}"
-          else
-            echo "Branch already exists, merging $BASE and bumping Batteries."
-            git switch lean-pr-testing-${{ steps.workflow-info.outputs.pullRequestNumber }}
-            # The Mathlib `nightly-testing` branch or `nightly-testing-YYYY-MM-DD` tag may have moved since this branch was created, so merge their changes.
-            # (This should no longer be possible once `nightly-testing-YYYY-MM-DD` is a tag, but it is still safe to merge.)
-            git merge "$BASE" --strategy-option ours --no-commit --allow-unrelated-histories
-            lake update batteries
-            git add lake-manifest.json
-            git commit --allow-empty -m "Trigger CI for https://github.com/leanprover/lean4/pull/${{ steps.workflow-info.outputs.pullRequestNumber }}"
-          fi
-
-      - name: Push changes
-        if: steps.workflow-info.outputs.pullRequestNumber != '' && steps.ready.outputs.mathlib_ready == 'true'
-        run: |
-          git push origin lean-pr-testing-${{ steps.workflow-info.outputs.pullRequestNumber }}

.github/workflows/pr-title.yml

@@ -1,20 +0,0 @@
-name: Check PR title for commit convention
-
-on:
-  merge_group:
-  pull_request:
-    types: [opened, synchronize, reopened, edited]
-
-jobs:
-  check-pr-title:
-    runs-on: ubuntu-latest
-    steps:
-      - name: Check PR title
-        uses: actions/github-script@v7
-        with:
-          script: |
-            const msg = context.payload.pull_request? context.payload.pull_request.title : context.payload.merge_group.head_commit.message;
-            console.log(`Message: ${msg}`)
-            if (!/^(feat|fix|doc|style|refactor|test|chore|perf): .*[^.]($|\n\n)/.test(msg)) {
-              core.setFailed('PR title does not follow the Commit Convention (https://leanprover.github.io/lean4/doc/dev/commit_convention.html).');
-            }

.github/workflows/pr.yml

@@ -0,0 +1,31 @@
+name: sanity-check opened PRs
+
+on:
+  # needs read/write GH token, do *not* execute arbitrary code from PR
+  pull_request_target:
+    types: [opened]
+
+jobs:
+  check-pr:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Check Commit Message
+        uses: actions/github-script@v6
+        with:
+          github-token: ${{ secrets.GITHUB_TOKEN }}
+          script: |
+            const { data: commits } = await github.rest.pulls.listCommits({
+              owner: context.repo.owner,
+              repo: context.repo.repo,
+              pull_number: context.issue.number,
+            });
+            console.log(commits[0].commit.message);
+            // check first commit only (and only once) since later commits might be intended to be squashed away
+            if (!/^(feat|fix|doc|style|refactor|test|chore|perf): .*[^.]($|\n\n)/.test(commits[0].commit.message)) {
+              await github.rest.issues.createComment({
+                owner: context.repo.owner,
+                repo: context.repo.repo,
+                issue_number: context.issue.number,
+                body: 'Thanks for your contribution! Please make sure to follow our [Commit Convention](https://leanprover.github.io/lean4/doc/dev/commit_convention.html).',
+              });
+            }

.github/workflows/restart-on-label.yml

@@ -1,35 +0,0 @@
-name: Restart by label
-on:
-  pull_request_target:
-    types:
-      - unlabeled
-      - labeled
-jobs:
-  restart-on-label:
-    runs-on: ubuntu-latest
-    if: contains(github.event.label.name, 'merge-ci') || contains(github.event.label.name, 'release-ci')
-    steps:
-    - run: |
-        # Finding latest CI workflow run on current pull request
-        # (unfortunately cannot search by PR number, only base branch,
-        # and that is't even unique given PRs from forks, but the risk
-        # of confusion is low and the danger is mild)
-        echo "Trying to find a run with branch $head_ref and commit $head_sha"
-        run_id="$(gh run list -e pull_request -b "$head_ref" -c "$head_sha" \
-          --workflow 'CI' --limit 1 --json databaseId --jq '.[0].databaseId')"
-        echo "Run id: ${run_id}"
-        gh run view "$run_id"
-        echo "Cancelling (just in case)"
-        gh run cancel "$run_id" || echo "(failed)"
-        echo "Waiting for 30s"
-        sleep 30
-        gh run view "$run_id"
-        echo "Rerunning"
-        gh run rerun "$run_id"
-        gh run view "$run_id"
-      shell: bash
-      env:
-        head_ref: ${{ github.head_ref }}
-        head_sha: ${{ github.event.pull_request.head.sha }}
-        GH_TOKEN: ${{ github.token }}
-        GH_REPO: ${{ github.repository }}

.github/workflows/stale.yml

@@ -1,20 +0,0 @@
-name: 'Label stale PRs'
-on:
-  schedule:
-    - cron: '30 1 * * *'
-  workflow_dispatch:
-
-permissions:
-  pull-requests: write
-
-jobs:
-  stale:
-    runs-on: ubuntu-latest
-    steps:
-      - uses: actions/stale@v9
-        with:
-          days-before-stale: -1
-          days-before-pr-stale: 30
-          days-before-close: -1
-          stale-pr-label: 'stale'
-          only-labels: 'awaiting-author'

.github/workflows/update-stage0.yml

@@ -1,78 +0,0 @@
-name: Update stage0
-
-# This action will update stage0 on master as soon as
-# src/stdlib_flags.h and stage0/src/stdlib_flags.h
-# are out of sync there, or when manually triggered.
-# The update bypasses the merge queue to be quick.
-# Also see <doc/dev/bootstrap.md>.
-
-on:
-  push:
-    branches:
-      - 'master'
-  workflow_dispatch:
-
-concurrency:
-  group: stage0
-  cancel-in-progress: true
-
-jobs:
-  update-stage0:
-    runs-on: ubuntu-latest
-    steps:
-    # This action should push to an otherwise protected branch, so it
-    # uses a deploy key with write permissions, as suggested at
-    # https://stackoverflow.com/a/76135647/946226
-    - uses: actions/checkout@v4
-      with:
-        ssh-key: ${{secrets.STAGE0_SSH_KEY}}
-    - run: echo "should_update_stage0=yes" >> "$GITHUB_ENV"
-    - name: Check if automatic update is needed
-      if: github.event_name == 'push'
-      run: |
-        if diff -u src/stdlib_flags.h stage0/src/stdlib_flags.h
-        then
-          echo "src/stdlib_flags.h and stage0/src/stdlib_flags.h agree, nothing to do"
-          echo "should_update_stage0=no" >> "$GITHUB_ENV"
-        fi
-    - name: Setup git user
-      if: env.should_update_stage0 == 'yes'
-      run: |
-          git config --global user.name "Lean stage0 autoupdater"
-          git config --global user.email "<>"
-    # Would be nice, but does not work yet:
-    # https://github.com/DeterminateSystems/magic-nix-cache/issues/39
-    # This action does not run that often and building runs in a few minutes, so ok for now
-    #- if: env.should_update_stage0 == 'yes'
-    #  uses: DeterminateSystems/magic-nix-cache-action@v2
-    - if: env.should_update_stage0 == 'yes'
-      name: Restore Build Cache
-      uses: actions/cache/restore@v4
-      with:
-        path: nix-store-cache
-        key: Nix Linux-nix-store-cache-${{ github.sha }}
-        # fall back to (latest) previous cache
-        restore-keys: |
-          Nix Linux-nix-store-cache
-    - if: env.should_update_stage0 == 'yes'
-      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
-    - if: env.should_update_stage0 == 'yes'
-      name: Install Nix
-      uses: DeterminateSystems/nix-installer-action@main
-      with:
-        extra-conf: |
-          substituters = file://${{ github.workspace }}/nix-store-cache-copy?priority=10&trusted=true https://cache.nixos.org  
-    - if: env.should_update_stage0 == 'yes'
-      run: nix run .#update-stage0-commit
-    - if: env.should_update_stage0 == 'yes'
-      run: git show --stat
-    - if: env.should_update_stage0 == 'yes' && github.event_name == 'push'
-      name: Sanity check # to avoid loops
-      run: |
-        diff -u src/stdlib_flags.h stage0/src/stdlib_flags.h || exit 1
-    - if: env.should_update_stage0 == 'yes'
-      run: git push origin

.gitignore

@@ -2,12 +2,7 @@
 \#*
 .#*
 *.lock
-.lake
-lake-manifest.json
-/build
-/src/lakefile.toml
-/tests/lakefile.toml
-/lakefile.toml
+build
 GPATH
 GRTAGS
 GSYMS
@@ -30,4 +25,4 @@ fwIn.txt
 fwOut.txt
 wdErr.txt
 wdIn.txt
-wdOut.txt
+wdOut.txt

.gitmodules

@@ -0,0 +1,4 @@
+[submodule "lake"]
+        path = src/lake
+        url = https://github.com/leanprover/lake.git
+        ignore = untracked

.gitpod.Dockerfile

@@ -1,14 +0,0 @@
-# You can find the new timestamped tags here: https://hub.docker.com/r/gitpod/workspace-full/tags
-FROM gitpod/workspace-full
-
-USER root
-RUN apt-get update && apt-get install git libgmp-dev libuv1-dev cmake ccache clang -y && apt-get clean
-
-USER gitpod
-
-# Install and configure elan
-RUN curl https://raw.githubusercontent.com/leanprover/elan/master/elan-init.sh -sSf | sh -s -- -y --default-toolchain none
-ENV PATH="/home/gitpod/.elan/bin:${PATH}"
-# Create a dummy toolchain so that we can pre-register it with elan
-RUN mkdir -p /workspace/lean4/build/release/stage1/bin && touch /workspace/lean4/build/release/stage1/bin/lean && elan toolchain link lean4 /workspace/lean4/build/release/stage1
-RUN mkdir -p /workspace/lean4/build/release/stage0/bin && touch /workspace/lean4/build/release/stage0/bin/lean && elan toolchain link lean4-stage0 /workspace/lean4/build/release/stage0

.gitpod.yml

@@ -1,11 +0,0 @@
-image:
-    file: .gitpod.Dockerfile
-
-vscode:
-  extensions:
-    - leanprover.lean4
-
-tasks:
-  - name: Release build
-    init: cmake --preset release
-    command: make -C build/release -j$(nproc || sysctl -n hw.logicalcpu)

.vscode/settings.json

@@ -0,0 +1,7 @@
+{
+    "files.insertFinalNewline": true,
+    "files.trimTrailingWhitespace": true,
+    "[markdown]": {
+        "rewrap.wrappingColumn": 70
+    }
+}

CMakeLists.txt

@@ -11,13 +11,10 @@ foreach(var ${vars})
     list(APPEND STAGE0_ARGS "-D${CMAKE_MATCH_1}=${${var}}")
   elseif("${currentHelpString}" MATCHES "No help, variable specified on the command line." OR "${currentHelpString}" STREQUAL "")
     list(APPEND CL_ARGS "-D${var}=${${var}}")
-    if("${var}" MATCHES "USE_GMP|CHECK_OLEAN_VERSION")
+    if("${var}" STREQUAL "USE_GMP")
       # must forward options that generate incompatible .olean format
       list(APPEND STAGE0_ARGS "-D${var}=${${var}}")
     endif()
-    if("${var}" MATCHES "LLVM*")
-      list(APPEND STAGE0_ARGS "-D${var}=${${var}}")
-    endif()
   elseif(("${var}" MATCHES "CMAKE_.*") AND NOT ("${var}" MATCHES "CMAKE_BUILD_TYPE") AND NOT ("${var}" MATCHES "CMAKE_HOME_DIRECTORY"))
     list(APPEND PLATFORM_ARGS "-D${var}=${${var}}")
   endif()
@@ -26,46 +23,28 @@ endforeach()
 include(ExternalProject)
 project(LEAN CXX C)
 
-if(NOT (DEFINED STAGE0_CMAKE_EXECUTABLE_SUFFIX))
-    set(STAGE0_CMAKE_EXECUTABLE_SUFFIX "${CMAKE_EXECUTABLE_SUFFIX}")
+if("${CMAKE_SYSTEM_NAME}" MATCHES "Emscripten")
+  # For Emscripten, we build GMP before any of the stages and reuse it in all of them.
+  set(GMP_INSTALL_PREFIX ${CMAKE_BINARY_DIR}/gmp-root)
+  set(EMSCRIPTEN_FLAGS "-s ALLOW_MEMORY_GROWTH=1 -s MAIN_MODULE=1 -O3")
+  ExternalProject_Add(
+    gmp
+    URL https://gmplib.org/download/gmp/gmp-6.2.1.tar.bz2
+    URL_HASH SHA256=eae9326beb4158c386e39a356818031bd28f3124cf915f8c5b1dc4c7a36b4d7c
+    BUILD_IN_SOURCE 1
+    CONFIGURE_COMMAND emconfigure ./configure "CFLAGS=${EMSCRIPTEN_FLAGS}" --host=wasm32-unknown-emscripten --disable-assembly --prefix=${GMP_INSTALL_PREFIX}
+    BUILD_COMMAND emmake make -j4
+    INSTALL_COMMAND emmake make install
+  )
+  set(EXTRA_DEPENDS "gmp")
+  list(APPEND CL_ARGS "-DGMP_INSTALL_PREFIX=${GMP_INSTALL_PREFIX}")
+  list(APPEND PLATFORM_ARGS "-DGMP_INSTALL_PREFIX=${GMP_INSTALL_PREFIX}")
 endif()
-
-# Don't do anything with cadical on wasm
-if (NOT ${CMAKE_SYSTEM_NAME} MATCHES "Emscripten")
-  # On CI Linux, we source cadical from Nix instead; see flake.nix
-  find_program(CADICAL cadical)
-  if(NOT CADICAL)
-    set(CADICAL_CXX c++)
-    find_program(CCACHE ccache)
-    if(CCACHE)
-      set(CADICAL_CXX "${CCACHE} ${CADICAL_CXX}")
-    endif()
-    # missing stdio locking API on Windows
-    if(${CMAKE_SYSTEM_NAME} MATCHES "Windows")
-      string(APPEND CADICAL_CXXFLAGS " -DNUNLOCKED")
-    endif()
-    ExternalProject_add(cadical
-      PREFIX cadical
-      GIT_REPOSITORY https://github.com/arminbiere/cadical
-      GIT_TAG rel-1.9.5
-      CONFIGURE_COMMAND ""
-      # https://github.com/arminbiere/cadical/blob/master/BUILD.md#manual-build
-      BUILD_COMMAND $(MAKE) -f ${CMAKE_SOURCE_DIR}/src/cadical.mk CMAKE_EXECUTABLE_SUFFIX=${CMAKE_EXECUTABLE_SUFFIX} CXX=${CADICAL_CXX} CXXFLAGS=${CADICAL_CXXFLAGS}
-      BUILD_IN_SOURCE ON
-      INSTALL_COMMAND "")
-    set(CADICAL ${CMAKE_BINARY_DIR}/cadical/cadical${CMAKE_EXECUTABLE_SUFFIX} CACHE FILEPATH "path to cadical binary" FORCE)
-    set(EXTRA_DEPENDS "cadical")
-  endif()
-  list(APPEND CL_ARGS -DCADICAL=${CADICAL})
-endif()
-
 ExternalProject_add(stage0
   SOURCE_DIR "${LEAN_SOURCE_DIR}/stage0"
   SOURCE_SUBDIR src
   BINARY_DIR stage0
   # do not rebuild stage0 when git hash changes; it's not from this commit anyway
-  # (however, `CHECK_OLEAN_VERSION=ON` in CI will override this as we need to
-  # embed the githash into the stage 1 library built by stage 0)
   CMAKE_ARGS -DSTAGE=0 -DUSE_GITHASH=OFF ${PLATFORM_ARGS} ${STAGE0_ARGS}
   BUILD_ALWAYS ON  # cmake doesn't auto-detect changes without a download method
   INSTALL_COMMAND ""  # skip install
@@ -75,7 +54,7 @@ ExternalProject_add(stage1
   SOURCE_DIR "${LEAN_SOURCE_DIR}"
   SOURCE_SUBDIR src
   BINARY_DIR stage1
-  CMAKE_ARGS -DSTAGE=1 -DPREV_STAGE=${CMAKE_BINARY_DIR}/stage0 -DPREV_STAGE_CMAKE_EXECUTABLE_SUFFIX=${STAGE0_CMAKE_EXECUTABLE_SUFFIX} ${CL_ARGS}
+  CMAKE_ARGS -DSTAGE=1 -DPREV_STAGE=${CMAKE_BINARY_DIR}/stage0 ${CL_ARGS}
   BUILD_ALWAYS ON
   INSTALL_COMMAND ""
   DEPENDS stage0
@@ -84,7 +63,7 @@ ExternalProject_add(stage2
   SOURCE_DIR "${LEAN_SOURCE_DIR}"
   SOURCE_SUBDIR src
   BINARY_DIR stage2
-  CMAKE_ARGS -DSTAGE=2 -DPREV_STAGE=${CMAKE_BINARY_DIR}/stage1 -DPREV_STAGE_CMAKE_EXECUTABLE_SUFFIX=${CMAKE_EXECUTABLE_SUFFIX} ${CL_ARGS}
+  CMAKE_ARGS -DSTAGE=2 -DPREV_STAGE=${CMAKE_BINARY_DIR}/stage1 ${CL_ARGS}
   BUILD_ALWAYS ON
   INSTALL_COMMAND ""
   DEPENDS stage1
@@ -94,7 +73,7 @@ ExternalProject_add(stage3
   SOURCE_DIR "${LEAN_SOURCE_DIR}"
   SOURCE_SUBDIR src
   BINARY_DIR stage3
-  CMAKE_ARGS -DSTAGE=3 -DPREV_STAGE=${CMAKE_BINARY_DIR}/stage2 -DPREV_STAGE_CMAKE_EXECUTABLE_SUFFIX=${CMAKE_EXECUTABLE_SUFFIX} ${CL_ARGS}
+  CMAKE_ARGS -DSTAGE=3 -DPREV_STAGE=${CMAKE_BINARY_DIR}/stage2 ${CL_ARGS}
   BUILD_ALWAYS ON
   INSTALL_COMMAND ""
   DEPENDS stage2
@@ -107,10 +86,6 @@ add_custom_target(update-stage0
   COMMAND $(MAKE) -C stage1 update-stage0
   DEPENDS stage1)
 
-add_custom_target(update-stage0-commit
-  COMMAND $(MAKE) -C stage1 update-stage0-commit
-  DEPENDS stage1)
-
 add_custom_target(test
   COMMAND $(MAKE) -C stage1 test
   DEPENDS stage1)

CMakePresets.json

@@ -1,83 +0,0 @@
-{
-  "version": 2,
-  "cmakeMinimumRequired": {
-    "major": 3,
-    "minor": 10,
-    "patch": 0
-  },
-  "configurePresets": [
-    {
-      "name": "release",
-      "displayName": "Default development optimized build config",
-      "generator": "Unix Makefiles",
-      "binaryDir": "${sourceDir}/build/release"
-    },
-    {
-      "name": "debug",
-      "displayName": "Debug build config",
-      "cacheVariables": {
-        "CMAKE_BUILD_TYPE": "Debug"
-      },
-      "generator": "Unix Makefiles",
-      "binaryDir": "${sourceDir}/build/debug"
-    },
-    {
-      "name": "sanitize",
-      "displayName": "Sanitize build config",
-      "cacheVariables": {
-        "LEAN_EXTRA_CXX_FLAGS": "-fsanitize=address,undefined",
-        "LEANC_EXTRA_FLAGS": "-fsanitize=address,undefined -fsanitize-link-c++-runtime",
-        "SMALL_ALLOCATOR": "OFF",
-        "BSYMBOLIC": "OFF"
-      },
-      "generator": "Unix Makefiles",
-      "binaryDir": "${sourceDir}/build/sanitize"
-    },
-    {
-      "name": "sandebug",
-      "inherits": ["debug", "sanitize"],
-      "displayName": "Sanitize+debug build config",
-      "binaryDir": "${sourceDir}/build/sandebug"
-    }
-  ],
-  "buildPresets": [
-    {
-      "name": "release",
-      "configurePreset": "release"
-    },
-    {
-      "name": "debug",
-      "configurePreset": "debug"
-    },
-    {
-      "name": "sanitize",
-      "configurePreset": "sanitize"
-    },
-    {
-      "name": "sandebug",
-      "configurePreset": "sandebug"
-    }
-  ],
-  "testPresets": [
-    {
-      "name": "release",
-      "configurePreset": "release",
-      "output": {"outputOnFailure": true, "shortProgress": true}
-    },
-    {
-      "name": "debug",
-      "configurePreset": "debug",
-      "inherits": "release"
-    },
-    {
-      "name": "sanitize",
-      "configurePreset": "sanitize",
-      "inherits": "release"
-    },
-    {
-      "name": "sandebug",
-      "configurePreset": "sandebug",
-      "inherits": "release"
-    }
-  ]
-}

CODEOWNERS

@@ -1,46 +0,0 @@
-# Code Owners
-#
-# Documents responsible people per component.
-# Listed persons will automatically be asked by GitHub to review a PR touching these paths.
-# If multiple names are listed, a review by any of them is considered sufficient by default.
-
-/.github/ @kim-em
-/RELEASES.md @kim-em
-/src/kernel/ @leodemoura
-/src/lake/ @tydeu
-/src/Lean/Compiler/ @leodemoura
-/src/Lean/Data/Lsp/ @mhuisi
-/src/Lean/Elab/Deriving/ @kim-em
-/src/Lean/Elab/Tactic/ @kim-em
-/src/Lean/Language/ @Kha
-/src/Lean/Meta/Tactic/ @leodemoura
-/src/Lean/PrettyPrinter/ @kmill
-/src/Lean/Server/ @mhuisi
-/src/Lean/Widget/ @Vtec234
-/src/Init/Data/ @kim-em
-/src/Init/Data/Array/Lemmas.lean @digama0
-/src/Init/Data/List/Lemmas.lean @digama0
-/src/Init/Data/List/BasicAux.lean @digama0
-/src/Init/Data/Array/Subarray.lean @david-christiansen
-/src/Lean/Elab/Tactic/RCases.lean @digama0
-/src/Init/RCases.lean @digama0
-/src/Lean/Elab/Tactic/Ext.lean @digama0
-/src/Init/Ext.lean @digama0
-/src/Lean/Elab/Tactic/Simpa.lean @digama0
-/src/Lean/Elab/Tactic/NormCast.lean @digama0
-/src/Lean/Meta/Tactic/NormCast.lean @digama0
-/src/Lean/Meta/Tactic/TryThis.lean @digama0
-/src/Lean/Elab/Tactic/SimpTrace.lean @digama0
-/src/Lean/Elab/Tactic/NoMatch.lean @digama0
-/src/Lean/Elab/Tactic/ShowTerm.lean @digama0
-/src/Lean/Elab/Tactic/Repeat.lean @digama0
-/src/Lean/Meta/Tactic/Repeat.lean @digama0
-/src/Lean/Meta/CoeAttr.lean @digama0
-/src/Lean/Elab/GuardMsgs.lean @digama0
-/src/Lean/Elab/Tactic/Guard.lean @digama0
-/src/Init/Guard.lean @digama0
-/src/Lean/Server/CodeActions/ @digama0
-/src/Std/ @TwoFX
-/src/Std/Tactic/BVDecide/ @hargoniX
-/src/Lean/Elab/Tactic/BVDecide/ @hargoniX
-/src/Std/Sat/ @hargoniX

CONTRIBUTING.md

@@ -1,93 +1,57 @@
-External Contribution Guidelines
-============
+# Contribution Guidelines
 
-In the past, we accepted most pull requests. This practice produced hard to maintain code, performance problems, and bugs. In order to improve the quality and maintainability of our codebase, we've established the following guidelines for external contributions.
+Thank you for your interest in contributing to Lean! There are many ways to contribute and we appreciate all of them.
 
-Helpful links
--------
+## Bug reports
 
-* [Development Setup](./doc/dev/index.md)
-* [Testing](./doc/dev/testing.md)
-* [Commit convention](./doc/dev/commit_convention.md)
+Bug reports as new issues are always welcome. Please check the existing [issues](https://github.com/leanprover/lean4/issues) first.
+Reduce the issue to a self-contained, reproducible test case.
+If you have the chance, before reporting a bug, please search existing issues, as it's possible that
+someone else has already reported your error.
+If you're not sure if something is a bug or not, feel free to file a bug anyway. You may also want to discuss it with the Lean
+community using the [lean4 Zulip channel](https://leanprover.zulipchat.com/#narrow/stream/270676-lean4).
 
-Before You Submit a Pull Request (PR):
--------
+## Simple fixes
 
-**Start with an Issue**: Before submitting a PR, always open an issue discussing the problem you wish to solve or the feature you'd like to add. Use the prefix `RFC:` (request for comments) if you are proposing a new feature. Ask for feedback from other users. Take the time to summarize all the feedback. This allows the maintainers to evaluate your proposal more efficiently. When creating a RFC, consider the following questions:
+Simple fixes for **typos and clear bugs** are welcome.
 
-  - **User Experience**: How does this feature improve the user experience?
+## Documentation
 
-  - **Beneficiaries**: Which Lean users and projects do benefit most from this feature/change?
+Tutorial-like examples are very welcome.
+They are useful for finding rough edges and bugs in Lean 4, for highlighting new features, and for showing how to use Lean.
+If you want to store your tutorial in the Lean 4 repository to make sure future changes will not break it, we suggest the following workflow:
+* Contact one of the Lean developers on Zulip, and check whether your tutorial is a good match for the Lean 4 repository.
+* Send bug reports and report rough edges. We will work with you until the tutorial looks great.
+* Add plenty of comments and make sure others will be able to follow it.
+* Create a pull request in the Lean 4 repository. After merging, we will link it to the official documentation and make sure it becomes part of our test suite.
 
-  - **Community Feedback**: Have you sought feedback or insights from other Lean users?
+You can use `.lean` or `.md` files to create your tutorial. The `.md` files are ideal when you want to format your prose using markdown. For an example, see [this `.md` file](https://github.com/leanprover/lean4/blob/master/doc/lean3changes.md).
 
-  - **Maintainability**: Will this change streamline code maintenance or simplify its structure?
+Contributions to the reference manual are also welcome, but since Lean 4 is changing rapidly, please contact us first using Zulip
+to find out which parts are stable enough to document. We will work with you to get this kind of
+pull request merged. We are also happy to meet using Zoom, Skype or Google hangout to coordinate this kind of effort.
 
-**Understand the Project**: Familiarize yourself with the project, existing issues, and latest commits. Ensure your contribution aligns with the project's direction and priorities.
+As Lean 4 matures, other forms of documentation (e.g., doc-strings) will be welcome too.
 
-**Stay Updated**: Regularly fetch and merge changes from the main branch to ensure your branch is up-to-date and can be smoothly integrated.
+## "Help wanted"
 
-**Help wanted**: We have issues tagged with ["help wanted"](https://github.com/leanprover/lean4/issues?q=is%3Aissue+is%3Aopen+label%3A%22help+wanted%22), if you want to contribute to the project, please take a look at them. If you are interested in one of them, post comments, ask questions, and engage with the core developers there.
+For issues marked as [`help wanted`](https://github.com/leanprover/lean4/issues?q=is%3Aissue+is%3Aopen+label%3A%22help+wanted%22), pull requests (PR) are welcome and we will work with you to get a PR merged. Some of these issues are nontrivial. If you are interested, please consider adding comments to the issue and/or messaging the Lean developers in [Zulip](https://leanprover.zulipchat.com/#).
 
-Quality Over Quantity:
------
+## Unexpected Pull Requests
 
-**Focused Changes**: Each PR should address a single, clearly-defined issue or feature. Avoid making multiple unrelated changes in a single PR.
+We have very few core developers, and we cannot review arbitrary pull requests (PRs). Moreover, many features involve subtle tradeoffs, and it may require significant time and energy to even assess a proposed design. We suggest the following workflow:
 
-**Write Tests**: Every new feature or bug fix should come with relevant tests. This ensures the robustness and reliability of the contribution.
+* First, discuss your idea with the Lean community on Zulip. Ask the community to help collect examples, document the requirements, and detect complications.
+* If there is broad support, create a detailed issue for it on the Lean 4 repository at GitHub, and tag the issue with `RFC`.
+* Ask the community for help documenting the requirements, and for collecting examples and concerns.
+* Wait for one of the core developers to give you a "go ahead". At this point, the core developers will work with you to make sure your PR gets merged.
 
-**Documentation**: Update relevant documentation, including comments in the code, to explain the logic and reasoning behind your changes.
+We don't want to waste your time by you implementing a feature and then us not being able to merge it.
 
-Coding Standards:
-----
+## How to Contribute
 
-**Follow the Code Style**: Ensure that your code follows the established coding style of the project.
-
-**Lean on Lean**: Use Lean's built-in features and libraries effectively, avoiding reinventions.
-
-**Performance**: Make sure that your changes do not introduce performance regressions. If possible, optimize the solution for speed and resource usage.
-
-PR Submission:
----
-
-**Descriptive Title and Summary**: The PR title should briefly explain the purpose of the PR. The summary should give more detailed information on what changes are made and why. Links to Zulip threads are not acceptable as a summary. You are responsible for summarizing the discussion, and getting support for it.
-
-**Follow the commit convention**: Pull requests are squash merged, and the
-commit message is taken from the pull request title and body, so make sure they adhere to the [commit convention](https://github.com/leanprover/lean4/blob/master/doc/dev/commit_convention.md). Put questions and extra information, which should not be part of the final commit message, into a first comment rather than the Pull Request description.
-Because the change will be squashed, there is no need to polish the commit messages and history on the branch.
-
-**Link to Relevant Issues**: Reference any issues that your PR addresses to provide context.
-
-**Stay Responsive**: Once the PR is submitted, stay responsive to feedback and be prepared to make necessary revisions. We will close any PR that has been inactive (no response or updates from the submitter) for more than a month.
-
-Reviews and Feedback:
-----
-
-The lean4 repo is managed by the Lean FRO's *triage team* that aims to provide initial feedback on new bug reports, PRs, and RFCs weekly.
-This feedback generally consists of prioritizing the ticket using one of the following categories:
-* label `P-high`: We will work on this issue
-* label `P-medium`: We may work on this issue if we find the time
-* label `P-low`: We are not planning to work on this issue
-* *closed*: This issue is already fixed, it is not an issue, or is not sufficiently compatible with our roadmap for the project and we will not work on it nor accept external contributions on it
-
-For *bug reports*, the listed priority reflects our commitment to fixing the issue.
-It is generally indicative but not necessarily identical to the priority an external contribution addressing this bug would receive.
-For *PRs* and *RFCs*, the priority reflects our commitment to reviewing them and getting them to an acceptable state.
-Accepted RFCs are marked with the label `RFC accepted` and afterwards assigned a new "implementation" priority as with bug reports.
-
-General guidelines for interacting with reviews and feedback:
-
-**Be Patient**: Given the limited number of full-time maintainers and the volume of PRs, reviews may take some time.
-
-**Engage Constructively**: Always approach feedback positively and constructively. Remember, reviews are about ensuring the best quality for the project, not personal criticism.
-
-**Continuous Integration**: Ensure that all CI checks pass on your PR. Failed checks will delay the review process. The maintainers will not check PRs containing failures.
-
-What to Expect:
-----
-
-**Not All PRs Get Merged**: While we appreciate every contribution, not all PRs will be merged. Ensure your changes align with the project's goals and quality standards.
-
-**Feedback is a Gift**: It helps improve the project and can also help you grow as a developer or contributor.
-
-**Community Involvement**: Engage with the Lean community on our communication channels. This can lead to better collaboration and understanding of the project's direction.
+* Always follow the [commit convention](https://leanprover.github.io/lean4/doc/dev/commit_convention.html).
+* Follow the style of the surrounding code. When in doubt, look at other files using the particular syntax as well.
+* Make sure your code is documented.
+* New features or bug fixes should come with appropriate tests.
+* Ensure all tests work before submitting a PR; see [Development Setup](https://leanprover.github.io/lean4/doc/make/index.html#development-setup) and [Fixing Tests](https://leanprover.github.io/lean4/doc/dev/fixing_tests.html).

LICENSES

@@ -1341,33 +1341,3 @@ whether future versions of the GNU Lesser General Public License shall
 apply, that proxy's public statement of acceptance of any version is
 permanent authorization for you to choose that version for the
 Library.
-==============================================================================
-CaDiCaL is under the MIT License:
-==============================================================================
-MIT License
-
-Copyright (c) 2016-2021 Armin Biere, Johannes Kepler University Linz, Austria
-Copyright (c) 2020-2021 Mathias Fleury, Johannes Kepler University Linz, Austria
-Copyright (c) 2020-2021 Nils Froleyks, Johannes Kepler University Linz, Austria
-Copyright (c) 2022-2024 Katalin Fazekas, Vienna University of Technology, Austria
-Copyright (c) 2021-2024 Armin Biere, University of Freiburg, Germany
-Copyright (c) 2021-2024 Mathias Fleury, University of Freiburg, Germany
-Copyright (c) 2023-2024 Florian Pollitt, University of Freiburg, Germany
-
-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.

README.md

@@ -1,21 +1,22 @@
-This is the repository for **Lean 4**.
+This is the repository for **Lean 4**, which is currently being released as milestone releases towards a first stable release.
+[Lean 3](https://github.com/leanprover/lean) is still the latest stable release.
 
 # About
 
-- [Quickstart](https://lean-lang.org/lean4/doc/quickstart.html)
-- [Homepage](https://lean-lang.org)
-- [Theorem Proving Tutorial](https://lean-lang.org/theorem_proving_in_lean4/)
-- [Functional Programming in Lean](https://lean-lang.org/functional_programming_in_lean/)
-- [Documentation Overview](https://lean-lang.org/lean4/doc/)
-- [Language Reference](https://lean-lang.org/doc/reference/latest/)
+- [Quickstart](https://github.com/leanprover/lean4/blob/master/doc/quickstart.md)
+- [Walkthrough installation video](https://www.youtube.com/watch?v=yZo6k48L0VY)
+- [Quick tour video](https://youtu.be/zyXtbb_eYbY)
+- [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://lean-lang.org/lean4/doc/examples.html)
-- [External Contribution Guidelines](CONTRIBUTING.md)
-- [FAQ](https://lean-lang.org/lean4/doc/faq.html)
+- [Examples](https://leanprover.github.io/lean4/doc/examples.html)
+- [FAQ](https://leanprover.github.io/lean4/doc/faq.html)
 
 # Installation
 
-See [Setting Up Lean](https://lean-lang.org/lean4/doc/setup.html).
+See [Setting Up Lean](https://leanprover.github.io/lean4/doc/setup.html).
 
 # Contributing
 
@@ -23,4 +24,4 @@ Please read our [Contribution Guidelines](CONTRIBUTING.md) first.
 
 # Building from Source
 
-See [Building Lean](https://lean-lang.org/lean4/doc/make/index.html) (documentation source: [doc/make/index.md](doc/make/index.md)).
+See [Building Lean](https://leanprover.github.io/lean4/doc/make/index.html).

default.nix

@@ -0,0 +1,9 @@
+# used for `nix-shell https://github.com/leanprover/lean4/archive/master.tar.gz -A nix`
+{ nix = (import ./shell.nix {}).nix; } //
+(import (
+  fetchTarball {
+    url = "https://github.com/edolstra/flake-compat/archive/c75e76f80c57784a6734356315b306140646ee84.tar.gz";
+    sha256 = "071aal00zp2m9knnhddgr2wqzlx6i6qa1263lv1y7bdn2w20h10h"; }
+) {
+  src =  ./.;
+}).defaultNix

doc/BoolExpr.lean

@@ -1,4 +1,4 @@
-open Batteries
+open Std
 open Lean
 
 inductive BoolExpr where

doc/SUMMARY.md

@@ -13,13 +13,61 @@
   - [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)
-  - [Syntax Examples](./syntax_examples.md)
-    - [Balanced Parentheses](./syntax_example.md)
-    - [Arithmetic DSL](./metaprogramming-arith.md)
 
 # Language Manual
-
-- [The Lean Reference Manual](./reference.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) -->
+- [Syntax Extensions](./syntax.md)
+  - [The `do` Notation](./do.md)
+  - [String Interpolation](./stringinterp.md)
+  - [User-Defined Notation](./notation.md)
+  - [Macro Overview](./macro_overview.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)
+  - [Structures](./struct.md)
+  - [Type classes](./typeclass.md)
+  - [Unification Hints](./unifhint.md)
+- [Builtin Types](./builtintypes.md)
+  - [Natural number](./nat.md)
+  - [Integer](./int.md)
+  - [Fixed precision unsigned integer](./uint.md)
+  - [Float](./float.md)
+  - [Array](./array.md)
+  - [List](./list.md)
+  - [Character](./char.md)
+  - [String](./string.md)
+  - [Option](./option.md)
+  - [Thunk](./thunk.md)
+  - [Task and Thread](./task.md)
+- [Functions](./functions.md)
+- [Monads](./monads/intro.md)
+  - [Functor](./monads/functors.lean.md)
+  - [Applicative](./monads/applicatives.lean.md)
+  - [Monad](./monads/monads.lean.md)
+  - [Reader](./monads/readers.lean.md)
+  - [State](./monads/states.lean.md)
+  - [Except](./monads/except.lean.md)
+  - [Transformers](./monads/transformers.lean.md)
+  - [Laws](./monads/laws.lean.md)
 
 # Other
 
@@ -37,10 +85,10 @@
   - [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)
 - [Bootstrapping](./dev/bootstrap.md)
 - [Testing](./dev/testing.md)
 - [Debugging](./dev/debugging.md)
 - [Commit Convention](./dev/commit_convention.md)
-- [Release checklist](./dev/release_checklist.md)
 - [Building This Manual](./dev/mdbook.md)
 - [Foreign Function Interface](./dev/ffi.md)

doc/array.md

@@ -0,0 +1,77 @@
+# Arrays
+
+The `Array` type implements a *dynamic* (aka growable) array.
+It is defined as
+```lean
+# namespace hidden
+structure Array (α : Type u) where
+  data : List α
+# end hidden
+```
+but its execution time representation is optimized, and it is similar to C++ `std::vector<T>` and Rust `Vec<T>`.
+The Lean type checker has no special support for reducing `Array`s.
+
+You can create arrays in several ways. You can create a small array by listing consecutive values between
+`#[` and `]` and separated by commas, as shown in the following examples.
+
+```lean
+#check #[1, 2, 3] -- Array Nat
+
+#check #[] -- Array ?m
+```
+
+The type of the array elements is inferred from the literals used and must be consistent.
+```lean
+#check #["hello", "world"] -- Array String
+
+-- The following is not valid
+#check_failure #[10, "hello"]
+```
+Recall that the command `#check_failure <term>` only succeeds when the given term is not type correct.
+
+To create an array of size `n` in which all the elements are initialized to some value `a`, use `mkArray`.
+```lean
+#eval mkArray 5 'a'
+-- #['a', 'a', 'a', 'a', 'a']
+```
+
+## Accessing elements
+
+You can access array elements by using brackets (`[` and `]`).
+```lean
+def f (a : Array Nat) (i : Fin a.size) :=
+  a[i] + a[i]
+```
+Note that the index `i` has type `Fin a.size`, i.e., it is natural number less than `a.size`.
+You can also write
+```lean
+def f (a : Array Nat) (i : Nat) (h  : i < a.size) :=
+  a[i] + a[i]
+```
+The bracket operator is whitespace sensitive.
+
+```lean
+def f (xs : List Nat) : List Nat :=
+  xs ++ xs
+
+def as : Array Nat :=
+  #[1, 2, 3, 4]
+
+def idx : Fin 4 :=
+  2
+
+#eval f [1, 2, 3] -- This is a function application
+
+#eval as[idx] -- This is an array access
+```
+The notation `a[i]` has two variants: `a[i]!` and `a[i]?`. In both cases, `i` has type `Nat`. The first one
+produces a panic error message if the index `i` is out of bounds. The latter returns an `Option` type.
+
+```lean
+#eval #['a', 'b', 'c'][1]?
+-- some 'b'
+#eval #['a', 'b', 'c'][5]?
+-- none
+#eval #['a', 'b', 'c'][1]!
+-- 'b!
+```

doc/autobound.md

@@ -0,0 +1,47 @@
+## Auto Bound Implicit Arguments
+
+In the previous section, we have shown how implicit arguments make functions more convenient to use.
+However, functions such as `compose` are still quite verbose to define. Note that the universe
+polymorphic `compose` is even more verbose than the one previously defined.
+
+```lean
+universe u v w
+def compose {α : Type u} {β : Type v} {γ : Type w}
+            (g : β → γ) (f : α → β) (x : α) : γ :=
+  g (f x)
+```
+
+You can avoid the `universe` command by providing the universe parameters when defining `compose`.
+
+```lean
+def compose.{u, v, w}
+            {α : Type u} {β : Type v} {γ : Type w}
+            (g : β → γ) (f : α → β) (x : α) : γ :=
+  g (f x)
+```
+
+Lean 4 supports a new feature called *auto bound implicit arguments*. It makes functions such as
+`compose` much more convenient to write. When Lean processes the header of a declaration,
+any unbound identifier is automatically added as an implicit argument *if* it is a single lower case or
+greek letter. With this feature, we can write `compose` as
+
+```lean
+def compose (g : β → γ) (f : α → β) (x : α) : γ :=
+  g (f x)
+
+#check @compose
+-- {β : Sort u_1} → {γ : Sort u_2} → {α : Sort u_3} → (β → γ) → (α → β) → α → γ
+```
+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 autoImplicit false`.
+```lean
+set_option autoImplicit false
+/- The following definition produces `unknown identifier` errors -/
+-- def compose (g : β → γ) (f : α → β) (x : α) : γ :=
+--   g (f x)
+```
+The Lean language server provides [semantic highlighting](./semantic_highlighting.md) information to editors, and it provides
+visual feedback whether an identifier has been interpreted as an auto bound implicit argument.

doc/bin/README.md

@@ -11,4 +11,4 @@ the following command executes a simple set of examples
 
 % bin/lean examples/ex.lean
 
-For more information on Lean and supported editors, please see https://lean-lang.org/documentation/.
+For more information on Lean and supported editors, please see https://leanprover.github.io/documentation/.

doc/book.toml

@@ -3,7 +3,7 @@ authors = ["Leonardo de Moura", "Sebastian Ullrich"]
 language = "en"
 multilingual = false
 src = "."
-title = "Lean Documentation Overview"
+title = "Lean Manual"
 
 [build]
 build-dir = "out"

doc/builtintypes.md

@@ -0,0 +1,25 @@
+# Builtin Types
+
+## Numeric Operations
+
+Lean supports the basic mathematical operations you’d expect for all of the number types: addition, subtraction, multiplication, division, and remainder.
+The following code shows how you’d use each one in a `def` commands:
+
+```lean
+-- addition
+def sum := 5 + 10
+
+-- subtraction
+def difference := 95.5 - 4.3
+
+-- multiplication
+def product := 4 * 30
+
+-- division
+def quotient := 53.7 / 32.2
+
+-- remainder/modulo
+def modulo := 43 % 5
+```
+
+Each expression in these statements uses a mathematical operator and evaluates to a single value.

doc/char.md

@@ -0,0 +1 @@
+# Characters

doc/declarations.md

@@ -60,7 +60,7 @@ a b c : Nat
 
 Here ``a b c : Nat`` indicates the local context, and the second ``Nat`` indicates the expected type of the result.
 
-A *context* is sometimes called a *telescope*, but the latter is used more generally to include a sequence of declarations occurring relative to a given context. For example, relative to the context ``(a₁ : α₁) (a₂ : α₂) ... (aₙ : αₙ)``, the types ``βᵢ`` in a telescope ``(b₁ : β₁) (b₂ : β₂) ... (bₙ : βₙ)`` can refer to ``a₁, ..., aₙ``. Thus a context can be viewed as a telescope relative to the empty context.
+A *context* is sometimes called a *telescope*, but the latter is used more generally to include a sequence of declarations occuring relative to a given context. For example, relative to the context ``(a₁ : α₁) (a₂ : α₂) ... (aₙ : αₙ)``, the types ``βᵢ`` in a telescope ``(b₁ : β₁) (b₂ : β₂) ... (bₙ : βₙ)`` can refer to ``a₁, ..., aₙ``. Thus a context can be viewed as a telescope relative to the empty context.
 
 Telescopes are often used to describe a list of arguments, or parameters, to a declaration. In such cases, it is often notationally convenient to let ``(a : α)`` stand for a telescope rather than just a single argument. In general, the annotations described in [Implicit Arguments](expressions.md#implicit_arguments) can be used to mark arguments as implicit.
 
@@ -76,7 +76,7 @@ Lean provides ways of adding new objects to the environment. The following provi
 * ``theorem c : p := v`` : similar to ``def``, but intended to be used when ``p`` is a proposition.
 * ``opaque c : α (:= v)?`` : declares a opaque constant named ``c`` of type ``α``, the optional value `v` is must have type `α`
   and can be viewed as a certificate that ``α`` is not an empty type. If the value is not provided, Lean tries to find one
-  using a procedure based on type class resolution. The value `v` is hidden from the type checker. You can assume that
+  using a proceture based on type class resolution. The value `v` is hidden from the type checker. You can assume that
   Lean "forgets" `v` after type checking this kind of declaration.
 
 It is sometimes useful to be able to simulate a definition or theorem without naming it or adding it to the environment.
@@ -483,43 +483,7 @@ def baz : Char → Nat
 | _   => 3
 ```
 
-The case where patterns are matched against an argument whose type is an inductive family is known as *dependent pattern matching*. This is more complicated, because the type of the function being defined can impose constraints on the patterns that are matched. In this case, the equation compiler will detect inconsistent cases and rule them out.
-
-```lean
-universe u
-
-inductive Vector (α : Type u) : Nat → Type u
-  | nil  : Vector α 0
-  | cons : α → Vector α n → Vector α (n+1)
-
-namespace Vector
-
-def head : Vector α (n+1) → α
-  | cons h t => h
-
-def tail : Vector α (n+1) → Vector α n
-  | cons h t => t
-
-def map (f : α → β → γ) : Vector α n → Vector β n → Vector γ n
-  | nil, nil => nil
-  | cons a va, cons b vb => cons (f a b) (map f va vb)
-
-end Vector
-```
-
-.. _recursive_functions:
-
-Recursive functions
-===================
-
-Lean must ensure that a recursive function terminates, for which there are two strategies: _structural recursion_, in which all recursive calls are made on smaller parts of the input data, and _well-founded recursion_, in which recursive calls are justified by showing that arguments to recursive calls are smaller according to some other measure.
-
-Structural recursion
---------------------
-
-If the definition of a function contains recursive calls, Lean first tries to interpret the definition as a structural recursion. In order for that to succeed, the recursive arguments must be subterms of the corresponding arguments on the left-hand side.
-
-The function is then defined using a *course of values* recursion, using automatically generated functions ``below`` and ``brec`` in the namespace corresponding to the inductive type of the recursive argument. In this case the defining equations hold definitionally, possibly with additional case splits.
+If any of the terms ``tᵢ`` in the template above contain a recursive call to ``foo``, the equation compiler tries to interpret the definition as a structural recursion. In order for that to succeed, the recursive arguments must be subterms of the corresponding arguments on the left-hand side. The function is then defined using a *course of values* recursion, using automatically generated functions ``below`` and ``brec`` in the namespace corresponding to the inductive type of the recursive argument. In this case the defining equations hold definitionally, possibly with additional case splits.
 
 ```lean
 namespace Hide
@@ -540,12 +504,7 @@ example : append [(1 : Nat), 2, 3] [4, 5] = [1, 2, 3, 4, 5] => rfl
 end Hide
 ```
 
-Well-founded recursion
----------------------
-
-If structural recursion fails, the equation compiler falls back on well-founded recursion. It tries to infer an instance of ``SizeOf`` for the type of each argument, and then tries to find a permutation of the arguments such that each recursive call is decreasing under the lexicographic order with respect to ``sizeOf`` measures.  Lean uses information in the local context, so you can often provide the relevant proof manually using ``have`` in the body of the definition.
-
-In the case of well-founded recursion, the equation used to declare the function holds only propositionally, but not definitionally, and can be accessed using ``unfold``, ``simp`` and ``rewrite`` with the function name (for example ``unfold foo`` or ``simp [foo]``, where ``foo`` is the function defined with well-founded recursion).
+If structural recursion fails, the equation compiler falls back on well-founded recursion. It tries to infer an instance of ``SizeOf`` for the type of each argument, and then show that each recursive call is decreasing under the lexicographic order of the arguments with respect to ``sizeOf`` measure. If it fails, the error message provides information as to the goal that Lean tried to prove. Lean uses information in the local context, so you can often provide the relevant proof manually using ``have`` in the body of the definition. In this case of well-founded recursion, the defining equations hold only propositionally, and can be accessed using ``simp`` and ``rewrite`` with the name ``foo``.
 
 ```lean
 namespace Hide
@@ -569,53 +528,9 @@ by rw [div]; rfl
 end Hide
 ```
 
-If Lean cannot find a permutation of the arguments for which all recursive calls are decreasing, it will print a table that contains, for every recursive call, which arguments Lean could prove to be decreasing. For example, a function with three recursive calls and four parameters might cause the following message to be printed
-
-```
-example.lean:37:0-43:31: error: Could not find a decreasing measure.
-The arguments relate at each recursive call as follows:
-(<, ≤, =: relation proved, ? all proofs failed, _: no proof attempted)
-           x1 x2 x3 x4
-1) 39:6-27  =  =  _  =
-2) 40:6-25  =  ?  _  <
-3) 41:6-25  <  _  _  _
-Please use `termination_by` to specify a decreasing measure.
-```
-
-This table should be read as follows:
-
- * In the first recursive call, in line 39, arguments 1, 2 and 4 are equal to the function's parameters.
- * The second recursive call, in line 40, has an equal first argument, a smaller fourth argument, and nothing could be inferred for the second argument.
- * The third recursive call, in line 41, has a decreasing first argument.
- * No other proofs were attempted, either because the parameter has a type without a non-trivial ``WellFounded`` instance (parameter 3), or because it is already clear that no decreasing measure can be found.
-
-
-Lean will print the termination argument it found if ``set_option showInferredTerminationBy true`` is set.
-
-If Lean does not find the termination argument, or if you want to be explicit, you can append a `termination_by` clause to the function definition, after the function's body, but before the `where` clause if present. It is of the form
-```
-termination_by e
-```
-where ``e`` is an expression that depends on the parameters of the function and should be decreasing at each recursive call. The type of `e` should be an instance of the class ``WellFoundedRelation``, which determines how to compare two values of that type.
-
-If ``f`` has parameters “after the ``:``” (for example when defining functions via patterns using `|`), then these can be brought into scope using the syntax
-```
-termination_by a₁ … aₙ => e
-```
-
-By default, Lean uses the tactic ``decreasing_tactic`` when proving that an argument is decreasing; see its documentation for how to globally extend it. You can also choose to use a different tactic for a given function definition with the clause
-```
-decreasing_by <tac>
-```
-which should come after ``termination_by`, if present.
-
-
 Note that recursive definitions can in general require nested recursions, that is, recursion on different arguments of ``foo`` in the template above. The equation compiler handles this by abstracting later arguments, and recursively defining higher-order functions to meet the specification.
 
-Mutual recursion
-----------------
-
-The equation compiler also allows mutual recursive definitions, with a syntax similar to that of [Mutual and Nested Inductive Definitions](#mutual-and-nested-inductive-definitions). Mutual definitions are always compiled using well-founded recursion, and so once again the defining equations hold only propositionally.
+The equation compiler also allows mutual recursive definitions, with a syntax similar to that of [Mutual and Nested Inductive Definitions](#mutual-and-nested-inductive-definitions). They are compiled using well-founded recursion, and so once again the defining equations hold only propositionally.
 
 ```lean
 mutual
@@ -672,31 +587,29 @@ def num_consts_lst : List Term → Nat
 end
 ```
 
-In a set of mutually recursive function, either all or no functions must have an explicit termination argument (``termination_by``). A change of the default termination tactic (``decreasing_by``) only affects the proofs about the recursive calls of that function, not the other functions in the group.
+The case where patterns are matched against an argument whose type is an inductive family is known as *dependent pattern matching*. This is more complicated, because the type of the function being defined can impose constraints on the patterns that are matched. In this case, the equation compiler will detect inconsistent cases and rule them out.
 
-```
-mutual
-theorem even_of_odd_succ : ∀ n, Odd (n + 1) → Even n
-| _, odd_succ n h => h
-termination_by n h => h
-decreasing_by decreasing_tactic
+```lean
+universe u
 
-theorem odd_of_even_succ : ∀ n, Even (n + 1) → Odd n
-| _, even_succ n h => h
-termination_by n h => h
-end
-```
+inductive Vector (α : Type u) : Nat → Type u
+| nil  : Vector α 0
+| cons : α → Vector α n → Vector α (n+1)
 
-Another way to express mutual recursion is using local function definitions in ``where`` or ``let rec`` clauses: these can be mutually recursive with each other and their containing function:
+namespace Vector
 
-```
-theorem even_of_odd_succ : ∀ n, Odd (n + 1) → Even n
-  | _, odd_succ n h => h
-termination_by n h => h
-  where
-    theorem odd_of_even_succ : ∀ n, Even (n + 1) → Odd n
-      | _, even_succ n h => h
-    termination_by n h => h
+def head {α : Type} : Vector α (n+1) → α
+| cons h t => h
+
+def tail {α : Type} : Vector α (n+1) → Vector α n
+| cons h t => t
+
+def map {α β γ : Type} (f : α → β → γ) :
+  ∀ {n}, Vector α n → Vector β n → Vector γ n
+| 0,   nil,       nil       => nil
+| n+1, cons a va, cons b vb => cons (f a b) (map f va vb)
+
+end Vector
 ```
 
 .. _match_expressions:

doc/decltypes.md

@@ -0,0 +1,29 @@
+# Declaring New Types
+
+In Lean's library, every concrete type other than the universes and every type constructor other than the dependent function type is
+an instance of a general family of type constructions known as *inductive types*. It is remarkable that it is possible to develop
+complex programs and formalize mathematics based on nothing more than the type universes, dependent function types,
+and inductive types; everything else follows from those.
+
+Intuitively, an inductive type is built up from a specified list of constructors. In Lean, the basic syntax for specifying such a type is as follows:
+```
+inductive NewType where
+  | constructor_1 : ... → NewType
+  | constructor_2 : ... → NewType
+  ...
+  | constructor_n : ... → NewType
+```
+
+The intuition is that each constructor specifies a way of building new objects of ``NewType``, possibly from previously constructed values.
+The type ``NewType`` consists of nothing more than the objects that are constructed in this way.
+
+We will see below that the arguments to the constructors can include objects of type ``NewType``,
+subject to a certain "positivity" constraint, which guarantees that elements of ``NewType`` are built
+from the bottom up. Roughly speaking, each ``...`` can be any function type constructed from ``NewType``
+and previously defined types, in which ``NewType`` appears, if at all, only as the "target" of the function type.
+
+We will provide a number of examples of inductive types. We will also consider slight generalizations of the scheme above,
+to mutually defined inductive types, and so-called *inductive families*.
+
+Every inductive type comes with constructors, which show how to construct an element of the type, and elimination rules,
+which show how to "use" an element of the type in another construction.

doc/dev/bootstrap.md

@@ -65,59 +65,19 @@ You now have a Lean binary and library that include your changes, though their
 own compilation was not influenced by them, that you can use to test your
 changes on test programs whose compilation *will* be influenced by the changes.
 
-## Updating stage0
-
 Finally, when we want to use new language features in the library, we need to
-update the archived C source code of the stage 0 compiler in `stage0/src`.
-
-The github repository will automatically update stage0 on `master` once
-`src/stdlib_flags.h` and `stage0/src/stdlib_flags.h` are out of sync.
-
-If you have write access to the lean4 repository, you can also manually
-trigger that process, for example to be able to use new features in the compiler itself.
-You can do that on <https://github.com/leanprover/lean4/actions/workflows/update-stage0.yml>
-or using Github CLI with
-```
-gh workflow run update-stage0.yml
-```
-
-Leaving stage0 updates to the CI automation is preferable, but should you need
-to do it locally, you can use `make update-stage0-commit` in `build/release` to
-update `stage0` from `stage1` or `make -C stageN update-stage0-commit` to
-update from another stage. This command will automatically stage the updated files
-and introduce a commit,so make sure to commit your work before that.
-
-If you rebased the branch (either onto a newer version of `master`, or fixing
-up some commits prior to the stage0 update, recreate the stage0 update commits.
-The script `script/rebase-stage0.sh` can be used for that.
-
-The CI should prevent PRs with changes to stage0 (besides `stdlib_flags.h`)
-from entering `master` through the (squashing!) merge queue, and label such PRs
-with the `changes-stage0` label. Such PRs should have a cleaned up history,
-with separate stage0 update commits; then coordinate with the admins to merge
-your PR using rebase merge, bypassing the merge queue.
-
+update the stage 0 compiler, which can be done via `make -C stageN update-stage0`.
+`make update-stage0` without `-C` defaults to stage1.
 
 ## Further Bootstrapping Complications
 
 As written above, changes in meta code in the current stage usually will only
 affect later stages. This is an issue in two specific cases.
 
-* For the special case of *quotations*, it is desirable to have changes in builtin parsers affect them immediately: when the changes in the parser become active in the next stage, builtin macros implemented via quotations should generate syntax trees compatible with the new parser, and quotation patterns in builtin macros and elaborators should be able to match syntax created by the new parser and macros.
-  Since quotations capture the syntax tree structure during execution of the current stage and turn it into code for the next stage, we need to run the current stage's builtin parsers in quotations via the interpreter for this to work.
-  Caveats:
-  * We activate this behavior by default when building stage 1 by setting `-Dinternal.parseQuotWithCurrentStage=true`.
-    We force-disable it inside `macro/macro_rules/elab/elab_rules` via `suppressInsideQuot` as they are guaranteed not to run in the next stage and may need to be run in the current one, so the stage 0 parser is the correct one to use for them.
-    It may be necessary to extend this disabling to functions that contain quotations and are (exclusively) used by one of the mentioned commands. A function using quotations should never be used by both builtin and non-builtin macros/elaborators. Example: https://github.com/leanprover/lean4/blob/f70b7e5722da6101572869d87832494e2f8534b7/src/Lean/Elab/Tactic/Config.lean#L118-L122
-  * The parser needs to be reachable via an `import` statement, otherwise the version of the previous stage will silently be used.
-  * Only the parser code (`Parser.fn`) is affected; all metadata such as leading tokens is taken from the previous stage.
-
-  For an example, see https://github.com/leanprover/lean4/commit/f9dcbbddc48ccab22c7674ba20c5f409823b4cc1#diff-371387aed38bb02bf7761084fd9460e4168ae16d1ffe5de041b47d3ad2d22422R13
-
 * For *non-builtin* meta code such as `notation`s or `macro`s in
   `Notation.lean`, we expect changes to affect the current file and all later
   files of the same stage immediately, just like outside the stdlib. To ensure
-  this, we build stage 1 using `-Dinterpreter.prefer_native=false` -
+  this, we need to build the stage using `-Dinterpreter.prefer_native=false` -
   otherwise, when executing a macro, the interpreter would notice that there is
   already a native symbol available for this function and run it instead of the
   new IR, but the symbol is from the previous stage!
@@ -135,11 +95,26 @@ affect later stages. This is an issue in two specific cases.
   further stages (e.g. after an `update-stage0`) will then need to be compiled
   with the flag set to `false` again since they will expect the new signature.
 
-  When enabling `prefer_native`, we usually want to *disable* `parseQuotWithCurrentStage` as it would otherwise make quotations use the interpreter after all.
-  However, there is a specific case where we want to set both options to `true`: when we make changes to a non-builtin parser like `simp` that has a builtin elaborator, we cannot have the new parser be active outside of quotations in stage 1 as the builtin elaborator from stage 0 would not understand them; on the other hand, we need quotations in e.g. the builtin `simp` elaborator to produce the new syntax in the next stage.
-  As this issue usually affects only tactics, enabling `debug.byAsSorry` instead of `prefer_native` can be a simpler solution.
+  For an example, see https://github.com/leanprover/lean4/commit/da4c46370d85add64ef7ca5e7cc4638b62823fbb.
 
-  For a `prefer_native` example, see https://github.com/leanprover/lean4/commit/da4c46370d85add64ef7ca5e7cc4638b62823fbb.
+* For the special case of *quotations*, it is desirable to have changes in
+  built-in parsers affect them immediately: when the changes in the parser
+  become active in the next stage, macros implemented via quotations should
+  generate syntax trees compatible with the new parser, and quotation patterns
+  in macro and elaborators should be able to match syntax created by the new
+  parser and macros. Since quotations capture the syntax tree structure during
+  execution of the current stage and turn it into code for the next stage, we
+  need to run the current stage's built-in parsers in quotation via the
+  interpreter for this to work. Caveats:
+  * Since interpreting full parsers is not nearly as cheap and we rarely change
+    built-in syntax, this needs to be opted in using `-Dinternal.parseQuotWithCurrentStage=true`.
+  * The parser needs to be reachable via an `import` statement, otherwise the
+    version of the previous stage will silently be used.
+  * Only the parser code (`Parser.fn`) is affected; all metadata such as leading
+    tokens is taken from the previous stage.
+
+  For an example, see https://github.com/leanprover/lean4/commit/f9dcbbddc48ccab22c7674ba20c5f409823b4cc1#diff-371387aed38bb02bf7761084fd9460e4168ae16d1ffe5de041b47d3ad2d22422
+  (from before the flag defaulted to `false`).
 
 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

doc/dev/commit_convention.md

@@ -1,15 +1,10 @@
 Git Commit Convention
 =====================
 
-We are using the following convention for writing git commit messages. For pull
-requests, make sure the pull request title and description follow this
-convention, as the squash-merge commit will inherit title and body from the
-pull request.
-
-This convention is based on the one from the AngularJS project ([doc][angularjs-doc],
+We are using the following convention for writing git-commit messages.
+It is based on the one from AngularJS project([doc][angularjs-doc],
 [commits][angularjs-git]).
 
-
 [angularjs-git]: https://github.com/angular/angular.js/commits/master
 [angularjs-doc]: https://docs.google.com/document/d/1QrDFcIiPjSLDn3EL15IJygNPiHORgU1_OOAqWjiDU5Y/edit#
 

doc/dev/debugging.md

@@ -5,7 +5,7 @@ Some notes on how to debug Lean, which may also be applicable to debugging Lean
 
 ## Tracing
 
-In `CoreM` and derived monads, we use `trace[traceCls] "msg with {interpolations}"` to fill the structured trace viewable with `set_option trace.traceCls true`.
+In `CoreM` and derived monads, we use `trace![traceCls] "msg with {interpolations}"` to fill the structured trace viewable with `set_option trace.traceCls true`.
 New trace classes have to be registered using `registerTraceClass` first.
 
 Notable trace classes:
@@ -22,9 +22,7 @@ Notable trace classes:
 
 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.
-
-By default, such stderr output is buffered and shown as messages after a command has been elaborated, which is necessary to ensure deterministic ordering of messages under parallelism.
-If Lean aborts the process before it can finish the command or takes too long to do that, using `-DstderrAsMessages=false` avoids this buffering and shows `dbg_trace` output (but not `trace`s or other diagnostics) immediately.
+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

@@ -11,8 +11,6 @@ There are two primary attributes for interoperating with other languages:
   It can also be used with `def` to provide an internal definition, but ensuring consistency of both definitions is up to the user.
 * `@[export sym] def leanSym : ...` exports `leanSym` under the unmangled symbol name `sym`.
 
-For simple examples of how to call foreign code from Lean and vice versa, see <https://github.com/leanprover/lean4/blob/master/src/lake/examples/ffi> and <https://github.com/leanprover/lean4/blob/master/src/lake/examples/reverse-ffi>, respectively.
-
 ## The Lean ABI
 
 The Lean Application Binary Interface (ABI) describes how the signature of a Lean declaration is encoded as a native calling convention.
@@ -49,64 +47,14 @@ In the case of `@[extern]` all *irrelevant* types are removed first; see next se
   is represented by the representation of that parameter's type.
 
   For example, `{ x : α // p }`, the `Subtype` structure of a value of type `α` and an irrelevant proof, is represented by the representation of `α`.
-  Similarly, the signed integer types `Int8`, ..., `Int64`, `ISize` are also represented by the unsigned C types `uint8_t`, ..., `uint64_t`, `size_t`, respectively, because they have a trivial structure.
-* `Nat` and `Int` are represented by `lean_object *`.
-  Their runtime values is either a pointer to an opaque bignum object or, if the lowest bit of the "pointer" is 1 (`lean_is_scalar`), an encoded unboxed natural number or integer (`lean_box`/`lean_unbox`).
+* `Nat` is represented by `lean_object *`.
+  Its runtime value is either a pointer to an opaque bignum object or, if the lowest bit of the "pointer" is 1 (`lean_is_scalar`), an encoded unboxed natural number (`lean_box`/`lean_unbox`).
 * A universe `Sort u`, type constructor `... → Sort u`, or proposition `p : Prop` is *irrelevant* and is either statically erased (see above) or represented as a `lean_object *` with the runtime value `lean_box(0)`
 * Any other type is represented by `lean_object *`.
-  Its runtime value is a pointer to an object of a subtype of `lean_object` (see the "Inductive types" section below) or the unboxed value `lean_box(cidx)` for the `cidx`th constructor of an inductive type if this constructor does not have any relevant parameters.
+  Its runtime value is a pointer to an object of a subtype of `lean_object` (see respective declarations in `lean.h`) or the unboxed value `lean_box(cidx)` for the `cidx`th constructor of an inductive type if this constructor does not have any relevant parameters.
 
   Example: the runtime value of `u : Unit` is always `lean_box(0)`.
 
-#### Inductive types
-
-For inductive types which are in the fallback `lean_object *` case above and not trivial constructors, the type is stored as a `lean_ctor_object`, and `lean_is_ctor` will return true. A `lean_ctor_object` stores the constructor index in the header, and the fields are stored in the `m_objs` portion of the object.
-
-The memory order of the fields is derived from the types and order of the fields in the declaration. They are ordered as follows:
-
-* Non-scalar fields stored as `lean_object *`
-* Fields of type `USize`
-* Other scalar fields, in decreasing order by size
-
-Within each group the fields are ordered in declaration order. **Warning**: Trivial wrapper types still count toward a field being treated as non-scalar for this purpose.
-
-* To access fields of the first kind, use `lean_ctor_get(val, i)` to get the `i`th non-scalar field.
-* To access `USize` fields, use `lean_ctor_get_usize(val, n+i)` to get the `i`th usize field and `n` is the total number of fields of the first kind.
-* To access other scalar fields, use `lean_ctor_get_uintN(val, off)` or `lean_ctor_get_usize(val, off)` as appropriate. Here `off` is the byte offset of the field in the structure, starting at `n*sizeof(void*)` where `n` is the number of fields of the first two kinds.
-
-For example, a structure such as
-```lean
-structure S where
-  ptr_1 : Array Nat
-  usize_1 : USize
-  sc64_1 : UInt64
-  ptr_2 : { x : UInt64 // x > 0 } -- wrappers don't count as scalars
-  sc64_2 : Float -- `Float` is 64 bit
-  sc8_1 : Bool
-  sc16_1 : UInt16
-  sc8_2 : UInt8
-  sc64_3 : UInt64
-  usize_2 : USize
-  ptr_3 : Char -- trivial wrapper around `UInt32`
-  sc32_1 : UInt32
-  sc16_2 : UInt16
-```
-would get re-sorted into the following memory order:
-
-* `S.ptr_1` - `lean_ctor_get(val, 0)`
-* `S.ptr_2` - `lean_ctor_get(val, 1)`
-* `S.ptr_3` - `lean_ctor_get(val, 2)`
-* `S.usize_1` - `lean_ctor_get_usize(val, 3)`
-* `S.usize_2` - `lean_ctor_get_usize(val, 4)`
-* `S.sc64_1` - `lean_ctor_get_uint64(val, sizeof(void*)*5)`
-* `S.sc64_2` - `lean_ctor_get_float(val, sizeof(void*)*5 + 8)`
-* `S.sc64_3` - `lean_ctor_get_uint64(val, sizeof(void*)*5 + 16)`
-* `S.sc32_1` - `lean_ctor_get_uint32(val, sizeof(void*)*5 + 24)`
-* `S.sc16_1` - `lean_ctor_get_uint16(val, sizeof(void*)*5 + 28)`
-* `S.sc16_2` - `lean_ctor_get_uint16(val, sizeof(void*)*5 + 30)`
-* `S.sc8_1` - `lean_ctor_get_uint8(val, sizeof(void*)*5 + 32)`
-* `S.sc8_2` - `lean_ctor_get_uint8(val, sizeof(void*)*5 + 33)`
-
 ### Borrowing
 
 By default, all `lean_object *` parameters of an `@[extern]` function are considered *owned*, i.e. the external code is passed a "virtual RC token" and is responsible for passing this token along to another consuming function (exactly once) or freeing it via `lean_dec`.
@@ -161,15 +109,6 @@ if (lean_io_result_is_ok(res)) {
 lean_io_mark_end_initialization();
 ```
 
-In addition, any other thread not spawned by the Lean runtime itself must be initialized for Lean use by calling
-```c
-void lean_initialize_thread();
-```
-and should be finalized in order to free all thread-local resources by calling
-```c
-void lean_finalize_thread();
-```
-
 ## `@[extern]` in the Interpreter
 
 The interpreter can run Lean declarations for which symbols are available in loaded shared libraries, which includes `@[extern]` declarations.
@@ -180,4 +119,4 @@ Thus to e.g. run `#eval` on such a declaration, you need to
 Note that it is not sufficient to load the foreign library containing the external symbol because the interpreter depends on code that is emitted for each `@[extern]` declaration.
 Thus it is not possible to interpret an `@[extern]` declaration in the same file.
 
-See [`tests/compiler/foreign`](https://github.com/leanprover/lean4/tree/master/tests/compiler/foreign/) for an example.
+See `tests/compiler/foreign` for an example.

doc/dev/index.md

@@ -1,6 +1,6 @@
 # Development Workflow
 
-If you want to make changes to Lean itself, start by [building Lean](../make/index.md) from a clean checkout to make sure that everything is set up correctly.
+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).
 
 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).
@@ -30,14 +30,20 @@ powershell -f elan-init.ps1 --default-toolchain none
 del elan-init.ps1
 ```
 
-The `lean-toolchain` files in the Lean 4 repository are set up to use the `lean4-stage0`
-toolchain for editing files in `src` and the `lean4` toolchain for editing files in `tests`.
-
-Run the following commands to make `lean4` point at `stage1` and `lean4-stage0` point at `stage0`:
+You can use `elan toolchain link` to give a specific stage build
+directory a reference name, then use `elan override set` to associate
+such a name to the current directory. We usually want to use `stage0`
+for editing files in `src` and `stage1` for everything else (e.g.
+tests).
 ```bash
 # in the Lean rootdir
 elan toolchain link lean4 build/release/stage1
 elan toolchain link lean4-stage0 build/release/stage0
+# make `lean` etc. point to stage1 in the rootdir and subdirs
+elan override set lean4
+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
@@ -51,32 +57,3 @@ You might find that debugging through elan, e.g. via `gdb lean`, disables some
 things like symbol autocompletion because at first only the elan proxy binary
 is loaded. You can instead pass the explicit path to `bin/lean` in your build
 folder to gdb, or use `gdb $(elan which lean)`.
-
-It is also possible to generate releases that others can use,
-simply by pushing a tag to your fork of the Lean 4 github repository
-(and waiting about an hour; check the `Actions` tab for completion).
-If you push `my-tag` to a fork in your github account `my_name`,
-you can then put `my_name/lean4:my-tag` in your `lean-toolchain` file in a project using `lake`.
-(You must use a tag name that does not start with a numeral, or contain `_`).
-
-### VS Code
-
-There is a `lean.code-workspace` file that correctly sets up VS Code with workspace roots for the stage0/stage1 setup described above as well as with other settings.
-You should always load it when working on Lean, such as by invoking
-```
-code lean.code-workspace
-```
-on the command line.
-
-### `ccache`
-
-Lean's build process uses [`ccache`](https://ccache.dev/) if it is
-installed to speed up recompilation of the generated C code. Without
-`ccache`, you'll likely spend more time than necessary waiting on
-rebuilds - it's a good idea to make sure it's installed.
-
-### `prelude`
-Unlike most Lean projects, all submodules of the `Lean` module begin with the
-`prelude` keyword. This disables the automated import of `Init`, meaning that
-developers need to figure out their own subset of `Init` to import. This is done
-such that changing files in `Init` doesn't force a full rebuild of `Lean`.

doc/dev/mdbook.md

@@ -1,6 +1,6 @@
 # Documentation
 
-The Lean `doc` folder contains the [Lean Manual](https://lean-lang.org/lean4/doc/) and is
+The Lean `doc` folder contains the [Lean Manual](https://leanprover.github.io/lean4/doc/) and is
 authored in a combination of markdown (`*.md`) files and literate Lean files.  The .lean files are
 preprocessed using a tool called [LeanInk](https://github.com/leanprover/leanink) and
 [Alectryon](https://github.com/Kha/alectryon) which produces a generated markdown file.  We then run
@@ -83,7 +83,7 @@ Then run the following:
     ```
 
 This will put the HTML in a `out` folder so you can load `out/index.html` in your web browser and
-it should look like https://lean-lang.org/lean4/doc/.
+it should look like https://leanprover.github.io/lean4/doc/.
 
 1. It is also handy to use e.g. [`mdbook watch`](https://rust-lang.github.io/mdBook/cli/watch.html)
    in the `doc/` folder so that it keeps the html up to date while you are editing.

doc/dev/release_checklist.md

@@ -1,261 +0,0 @@
-# Releasing a stable version
-
-This checklist walks you through releasing a stable version.
-See below for the checklist for release candidates.
-
-We'll use `v4.6.0` as the intended release version as a running example.
-
-- `git checkout releases/v4.6.0`
-  (This branch should already exist, from the release candidates.)
-- `git pull`
-- In `src/CMakeLists.txt`, verify you see
-  - `set(LEAN_VERSION_MINOR 6)` (for whichever `6` is appropriate)
-  - `set(LEAN_VERSION_IS_RELEASE 1)`
-  - (both of these should already be in place from the release candidates)
-- `git tag v4.6.0`
-- `git push $REMOTE v4.6.0`, where `$REMOTE` is the upstream Lean repository (e.g., `origin`, `upstream`)
-- Now wait, while CI runs.
-  - You can monitor this at `https://github.com/leanprover/lean4/actions/workflows/ci.yml`,
-    looking for the `v4.6.0` tag.
-  - This step can take up to an hour.
-  - If you are intending to cut the next release candidate on the same day,
-    you may want to start on the release candidate checklist now.
-- Go to https://github.com/leanprover/lean4/releases and verify that the `v4.6.0` release appears.
-  - Edit the release notes on Github to select the "Set as the latest release".
-  - Follow the instructions in creating a release candidate for the "GitHub release notes" step,
-    now that we have a written `RELEASES.md` section.
-    Do a quick sanity check.
-- Next, we will move a curated list of downstream repos to the latest stable release.
-  - For each of the repositories listed below:
-    - Make a PR to `master`/`main` changing the toolchain to `v4.6.0`
-      - Update the toolchain file
-      - In the Lakefile, if there are dependencies on specific version tags of dependencies that you've already pushed as part of this process, update them to the new tag.
-        If they depend on `main` or `master`, don't change this; you've just updated the dependency, so it will work and be saved in the manifest
-      - Run `lake update`
-      - The PR title should be "chore: bump toolchain to v4.6.0".
-    - Merge the PR once CI completes.
-    - Create the tag `v4.6.0` from `master`/`main` and push it.
-    - Merge the tag `v4.6.0` into the `stable` branch and push it.
-  - We do this for the repositories:
-    - [Batteries](https://github.com/leanprover-community/batteries)
-      - No dependencies
-      - Toolchain bump PR
-      - Create and push the tag
-      - Merge the tag into `stable`
-    - [lean4checker](https://github.com/leanprover/lean4checker)
-      - No dependencies
-      - Toolchain bump PR
-      - Create and push the tag
-      - Merge the tag into `stable`
-    - [doc-gen4](https://github.com/leanprover/doc-gen4)
-      - Dependencies: exist, but they're not part of the release workflow
-      - Toolchain bump PR including updated Lake manifest
-      - Create and push the tag
-      - There is no `stable` branch; skip this step
-    - [Verso](https://github.com/leanprover/verso)
-      - Dependencies: exist, but they're not part of the release workflow
-      - The `SubVerso` dependency should be compatible with _every_ Lean release simultaneously, rather than following this workflow
-      - Toolchain bump PR including updated Lake manifest
-      - Create and push the tag
-      - There is no `stable` branch; skip this step
-    - [Cli](https://github.com/leanprover/lean4-cli)
-      - No dependencies
-      - Toolchain bump PR
-      - Create and push the tag
-      - There is no `stable` branch; skip this step
-    - [ProofWidgets4](https://github.com/leanprover-community/ProofWidgets4)
-      - Dependencies: `Batteries`
-      - Note on versions and branches:
-        - `ProofWidgets` uses a sequential version tagging scheme, e.g. `v0.0.29`,
-          which does not refer to the toolchain being used.
-        - Make a new release in this sequence after merging the toolchain bump PR.
-        - `ProofWidgets` does not maintain a `stable` branch.
-      - Toolchain bump PR
-      - Create and push the tag, following the version convention of the repository
-    - [Aesop](https://github.com/leanprover-community/aesop)
-      - Dependencies: `Batteries`
-      - Toolchain bump PR including updated Lake manifest
-      - Create and push the tag
-      - Merge the tag into `stable`
-    - [import-graph](https://github.com/leanprover-community/import-graph)
-      - Toolchain bump PR including updated Lake manifest
-      - Create and push the tag
-      - There is no `stable` branch; skip this step
-    - [plausible](https://github.com/leanprover-community/plausible)
-      - Toolchain bump PR including updated Lake manifest
-      - Create and push the tag
-      - There is no `stable` branch; skip this step
-    - [Mathlib](https://github.com/leanprover-community/mathlib4)
-      - Dependencies: `Aesop`, `ProofWidgets4`, `lean4checker`, `Batteries`, `doc-gen4`, `import-graph`
-      - Toolchain bump PR notes:
-        - In addition to updating the `lean-toolchain` and `lakefile.lean`,
-          in `.github/workflows/lean4checker.yml` update the line
-          `git checkout v4.6.0` to the appropriate tag.
-        - Push the PR branch to the main Mathlib repository rather than a fork, or CI may not work reliably
-        - Create and push the tag
-        - Create a new branch from the tag, push it, and open a pull request against `stable`.
-          Coordinate with a Mathlib maintainer to get this merged.
-    - [REPL](https://github.com/leanprover-community/repl)
-      - Dependencies: `Mathlib` (for test code)
-      - Note that there are two copies of `lean-toolchain`/`lakefile.lean`:
-        in the root, and in `test/Mathlib/`. Edit both, and run `lake update` in both directories.
-      - Toolchain bump PR including updated Lake manifest
-      - Create and push the tag
-      - Merge the tag into `stable`
-- Run `scripts/release_checklist.py v4.6.0` to check that everything is in order.
-- The `v4.6.0` section of `RELEASES.md` is out of sync between
-  `releases/v4.6.0` and `master`. This should be reconciled:
-  - Replace the `v4.6.0` section on `master` with the `v4.6.0` section on `releases/v4.6.0`
-    and commit this to `master`.
-- Merge the release announcement PR for the Lean website - it will be deployed automatically
-- Finally, make an announcement!
-  This should go in https://leanprover.zulipchat.com/#narrow/stream/113486-announce, with topic `v4.6.0`.
-  Please see previous announcements for suggested language.
-  You will want a few bullet points for main topics from the release notes.
-  Link to the blog post from the Zulip announcement.
-- Make sure that whoever is handling social media knows the release is out.
-
-## Optimistic(?) time estimates:
-- Initial checks and push the tag: 30 minutes.
-- Waiting for the release: 60 minutes.
-- Fixing release notes: 10 minutes.
-- Bumping toolchains in downstream repositories, up to creating the Mathlib PR: 30 minutes.
-- Waiting for Mathlib CI and bors: 120 minutes.
-- Finalizing Mathlib tags and stable branch, and updating REPL: 15 minutes.
-- Posting announcement and/or blog post: 20 minutes.
-
-# Creating a release candidate.
-
-This checklist walks you through creating the first release candidate for a version of Lean.
-
-We'll use `v4.7.0-rc1` as the intended release version in this example.
-
-- Decide which nightly release you want to turn into a release candidate.
-  We will use `nightly-2024-02-29` in this example.
-- It is essential that Batteries and Mathlib already have reviewed branches compatible with this nightly.
-  - Check that both Batteries and Mathlib's `bump/v4.7.0` branch contain `nightly-2024-02-29`
-    in their `lean-toolchain`.
-  - The steps required to reach that state are beyond the scope of this checklist, but see below!
-- Create the release branch from this nightly tag:
-    ```
-    git remote add nightly https://github.com/leanprover/lean4-nightly.git
-    git fetch nightly tag nightly-2024-02-29
-    git checkout nightly-2024-02-29
-    git checkout -b releases/v4.7.0
-    ```
-- In `RELEASES.md` replace `Development in progress` in the `v4.7.0` section with `Release notes to be written.`
-- It is essential to choose the nightly that will become the release candidate as early as possible, to avoid confusion.
-- In `src/CMakeLists.txt`,
-  - verify that you see `set(LEAN_VERSION_MINOR 7)` (for whichever `7` is appropriate); this should already have been updated when the development cycle began.
-  - `set(LEAN_VERSION_IS_RELEASE 1)` (this should be a change; on `master` and nightly releases it is always `0`).
-  - Commit your changes to `src/CMakeLists.txt`, and push.
-- `git tag v4.7.0-rc1`
-- `git push origin v4.7.0-rc1`
-- Now wait, while CI runs.
-  - You can monitor this at `https://github.com/leanprover/lean4/actions/workflows/ci.yml`, looking for the `v4.7.0-rc1` tag.
-  - This step can take up to an hour.
-- (GitHub release notes) Once the release appears at https://github.com/leanprover/lean4/releases/
-  - Verify that the release is marked as a prerelease (this should have been done automatically by the CI release job).
-  - In the "previous tag" dropdown, select `v4.6.0`, and click "Generate release notes".
-    This will add a list of all the commits since the last stable version.
-    - Delete "update stage0" commits, and anything with a completely inscrutable commit message.
-- Next, we will move a curated list of downstream repos to the release candidate.
-  - This assumes that for each repository either:
-    * There is already a *reviewed* branch `bump/v4.7.0` containing the required adaptations.
-      The preparation of this branch is beyond the scope of this document.
-    * The repository does not need any changes to move to the new version.
-  - For each of the target repositories:
-    - If the repository does not need any changes (i.e. `bump/v4.7.0` does not exist) then create
-      a new PR updating `lean-toolchain` to `leanprover/lean4:v4.7.0-rc1` and running `lake update`.
-    - Otherwise:
-      - Checkout the `bump/v4.7.0` branch.
-      - Verify that the `lean-toolchain` is set to the nightly from which the release candidate was created.
-      - `git merge origin/master`
-      - Change the `lean-toolchain` to `leanprover/lean4:v4.7.0-rc1`
-      - In `lakefile.lean`, change any dependencies which were using `nightly-testing` or `bump/v4.7.0` branches
-        back to `master` or `main`, and run `lake update` for those dependencies.
-      - Run `lake build` to ensure that dependencies are found (but it's okay to stop it after a moment).
-      - `git commit`
-      - `git push`
-      - Open a PR from `bump/v4.7.0` to `master`, and either merge it yourself after CI, if appropriate,
-        or notify the maintainers that it is ready to go.
-    - Once the PR has been merged, tag `master` with `v4.7.0-rc1` and push this tag.
-  - We do this for the same list of repositories as for stable releases, see above.
-    As above, there are dependencies between these, and so the process above is iterative.
-    It greatly helps if you can merge the `bump/v4.7.0` PRs yourself!
-    It is essential for Mathlib CI that you then create the next `bump/v4.8.0` branch
-    for the next development cycle.
-    Set the `lean-toolchain` file on this branch to same `nightly` you used for this release.
-  - For Batteries/Aesop/Mathlib, which maintain a `nightly-testing` branch, make sure there is a tag
-    `nightly-testing-2024-02-29` with date corresponding to the nightly used for the release
-    (create it if not), and then on the `nightly-testing` branch `git reset --hard master`, and force push.
-- Make an announcement!
-  This should go in https://leanprover.zulipchat.com/#narrow/stream/113486-announce, with topic `v4.7.0-rc1`.
-  Please see previous announcements for suggested language.
-  You will want a few bullet points for main topics from the release notes.
-  Please also make sure that whoever is handling social media knows the release is out.
-- Begin the next development cycle (i.e. for `v4.8.0`) on the Lean repository, by making a PR that:
-  - Updates `src/CMakeLists.txt` to say `set(LEAN_VERSION_MINOR 8)`
-  - Replaces the "release notes will be copied" text in the `v4.6.0` section of `RELEASES.md` with the
-    finalized release notes from the `releases/v4.6.0` branch.
-  - Replaces the "development in progress" in the `v4.7.0` section of `RELEASES.md` with
-    ```
-    Release candidate, release notes will be copied from the branch `releases/v4.7.0` once completed.
-    ```
-    and inserts the following section before that section:
-    ```
-    v4.8.0
-    ----------
-    Development in progress.
-    ```
-  - Removes all the entries from the `./releases_drafts/` folder.
-  - Titled "chore: begin development cycle for v4.8.0"
-
-
-## Time estimates:
-Slightly longer than the corresponding steps for a stable release.
-Similar process, but more things go wrong.
-In particular, updating the downstream repositories is significantly more work
-(because we need to merge existing `bump/v4.7.0` branches, not just update a toolchain).
-
-# Preparing `bump/v4.7.0` branches
-
-While not part of the release process per se,
-this is a brief summary of the work that goes into updating Batteries/Aesop/Mathlib to new versions.
-
-Please read https://leanprover-community.github.io/contribute/tags_and_branches.html
-
-* Each repo has an unreviewed `nightly-testing` branch that
-  receives commits automatically from `master`, and
-  has its toolchain updated automatically for every nightly.
-  (Note: the aesop branch is not automated, and is updated on an as needed basis.)
-  As a consequence this branch is often broken.
-  A bot posts in the (private!) "Mathlib reviewers" stream on Zulip about the status of these branches.
-* We fix the breakages by committing directly to `nightly-testing`: there is no PR process.
-  * This can either be done by the person managing this process directly,
-    or by soliciting assistance from authors of files, or generally helpful people on Zulip!
-* Each repo has a `bump/v4.7.0` which accumulates reviewed changes adapting to new versions.
-* Once `nightly-testing` is working on a given nightly, say `nightly-2024-02-15`, we will create a PR to `bump/v4.7.0`.
-* For Mathlib, there is a script in `scripts/create-adaptation-pr.sh` that automates this process.
-* For Batteries and Aesop it is currently manual.
-* For all of these repositories, the process is the same:
-  * Make sure `bump/v4.7.0` is up to date with `master` (by merging `master`, no PR necessary)
-  * Create from `bump/v4.7.0` a `bump/nightly-2024-02-15` branch.
-  * In that branch, `git merge nightly-testing` to bring across changes from `nightly-testing`.
-  * Sanity check changes, commit, and make a PR to `bump/v4.7.0` from the `bump/nightly-2024-02-15` branch.
-  * Solicit review, merge the PR into `bump/v4.7.0`.
-* It is always okay to merge in the following directions:
-  `master` -> `bump/v4.7.0` -> `bump/nightly-2024-02-15` -> `nightly-testing`.
-  Please remember to push any merges you make to intermediate steps!
-
-# Writing the release notes
-
-Release notes are automatically generated from the commit history, using `script/release_notes.py`.
-
-Run this as `script/release_notes.py v4.6.0`, where `v4.6.0` is the *previous* release version. This will generate output
-for all commits since that tag. Note that there is output on both stderr, which should be manually reviewed,
-and on stdout, which should be manually copied to `RELEASES.md`.
-
-There can also be pre-written entries in `./releases_drafts`, which should be all incorporated in the release notes and then deleted from the branch.
-  See `./releases_drafts/README.md` for more information.
-

doc/dev/testing.md

@@ -5,6 +5,7 @@ After [building Lean](../make/index.md) you can run all the tests using
 cd build/release
 make test ARGS=-j4
 ```
+
 Change the 4 to the maximum number of parallel tests you want to
 allow. The best choice is the number of CPU cores on your machine as
 the tests are mostly CPU bound.  You can find the number of processors
@@ -16,12 +17,6 @@ adding the `-C stageN` argument. The default when run as above is stage 1.  The
 Lean tests will automatically use that stage's corresponding Lean
 executables
 
-Running `make test` will not pick up new test files; run
-```bash
-cmake build/release/stage1
-```
-to update the list of tests.
-
 You can also use `ctest` directly if you are in the right folder.  So
 to run stage1 tests with a 300 second timeout run this:
 
@@ -29,9 +24,6 @@ to run stage1 tests with a 300 second timeout run this:
 cd build/release/stage1
 ctest -j 4 --output-on-failure --timeout 300
 ```
-Useful `ctest` flags are `-R <name of test>` to run a single test, and
-`--rerun-failed` to run all tests that failed during the last run.
-You can also pass `ctest` flags via `make test ARGS="--rerun-failed"`.
 
 To get verbose output from ctest pass the `--verbose` command line
 option. Test output is normally suppressed and only summary
@@ -41,17 +33,17 @@ information is displayed. This option will show all test output.
 
 All these tests are included by [src/shell/CMakeLists.txt](https://github.com/leanprover/lean4/blob/master/src/shell/CMakeLists.txt):
 
-- [`tests/lean`](https://github.com/leanprover/lean4/tree/master/tests/lean/): contains tests that come equipped with a
-  .lean.expected.out file. The driver script [`test_single.sh`](https://github.com/leanprover/lean4/tree/master/tests/lean/test_single.sh) runs
+- `tests/lean`: contains tests that come equipped with a
+  .lean.expected.out file. The driver script `test_single.sh` runs
   each test and checks the actual output (*.produced.out) with the
   checked in expected output.
 
-- [`tests/lean/run`](https://github.com/leanprover/lean4/tree/master/tests/lean/run/): contains tests that are run through the lean
+- `tests/lean/run`: contains tests that are run through the lean
   command line one file at a time. These tests only look for error
   codes and do not check the expected output even though output is
   produced, it is ignored.
 
-- [`tests/lean/interactive`](https://github.com/leanprover/lean4/tree/master/tests/lean/interactive/): are designed to test server requests at a
+- `tests/lean/interactive`: are designed to test server requests at a
   given position in the input file. Each .lean file contains comments
   that indicate how to simulate a client request at that position.
   using a `--^` point to the line position. Example:
@@ -61,7 +53,7 @@ All these tests are included by [src/shell/CMakeLists.txt](https://github.com/le
     Bla.
       --^ textDocument/completion
     ```
-    In this example, the test driver [`test_single.sh`](https://github.com/leanprover/lean4/tree/master/tests/lean/interactive/test_single.sh) will simulate an
+    In this example, the test driver `test_single.sh` will simulate an
     auto-completion request at `Bla.`. The expected output is stored in
     a .lean.expected.out in the json format that is part of the
     [Language Server
@@ -78,33 +70,23 @@ All these tests are included by [src/shell/CMakeLists.txt](https://github.com/le
     --^ collectDiagnostics
     ```
 
-- [`tests/lean/server`](https://github.com/leanprover/lean4/tree/master/tests/lean/server/): Tests more of the Lean `--server` protocol.
+- `tests/lean/server`: Tests more of the Lean `--server` protocol.
   There are just a few of them, and it uses .log files containing
   JSON.
 
-- [`tests/compiler`](https://github.com/leanprover/lean4/tree/master/tests/compiler/): contains tests that will run the Lean compiler and
+- `tests/compiler`: contains tests that will run the Lean compiler and
   build an executable that is executed and the output is compared to
   the .lean.expected.out file. This test also contains a subfolder
-  [`foreign`](https://github.com/leanprover/lean4/tree/master/tests/compiler/foreign/) which shows how to extend Lean using C++.
+  `foreign` which shows how to extend Lean using C++.
 
-- [`tests/lean/trust0`](https://github.com/leanprover/lean4/tree/master/tests/lean/trust0): tests that run Lean in a mode that Lean doesn't
+- `tests/lean/trust0`: tests that run Lean in a mode that Lean doesn't
   even trust the .olean files (i.e., trust 0).
 
-- [`tests/bench`](https://github.com/leanprover/lean4/tree/master/tests/bench/): contains performance tests.
+- `tests/bench`: contains performance tests.
 
-- [`tests/plugin`](https://github.com/leanprover/lean4/tree/master/tests/plugin/): tests that compiled Lean code can be loaded into
+- `tests/plugin`: tests that compiled Lean code can be loaded into
   `lean` via the `--plugin` command line option.
 
-## Writing Good Tests
-
-Every test file should contain:
-* an initial `/-! -/` module docstring summarizing the test's purpose
-* a module docstring for each test section that describes what is tested
-  and, if not 100% clear, why that is the desirable behavior
-
-At the time of writing, most tests do not follow these new guidelines yet.
-For an example of a conforming test, see [`tests/lean/1971.lean`](https://github.com/leanprover/lean4/tree/master/tests/lean/1971.lean).
-
 ## Fixing Tests
 
 When the Lean source code or the standard library are modified, some of the
@@ -119,7 +101,7 @@ First, we must install [meld](http://meldmerge.org/). On Ubuntu, we can do it by
 sudo apt-get install meld
 ```
 
-Now, suppose `bad_class.lean` test is broken. We can see the problem by going to [`tests/lean`](https://github.com/leanprover/lean4/tree/master/tests/lean) directory and
+Now, suppose `bad_class.lean` test is broken. We can see the problem by going to `test/lean` directory and
 executing
 
 ```
@@ -132,3 +114,8 @@ 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

@@ -0,0 +1,417 @@
+# The `do` notation
+
+Lean is a pure functional programming language, but you can write effectful code using the `do` embedded domain specific language (DSL). The following simple program prints two strings "hello" and "world" in the standard output and terminates with exit code 0. Note that the type of the program is `IO UInt32`. You can read this type as the type of values that perform input-output effects and produce a value of type `UInt32`.
+
+```lean
+def main : IO UInt32 := do
+  IO.println "hello"
+  IO.println "world"
+  return 0
+```
+The type of `IO.println` is `String → IO Unit`. That is, it is a function from `String` to `IO Unit` which indicates it may perform input-output effects and produce a value of type `Unit`. We often say that functions that may perform effects are *methods*.
+We also say a method application, such as `IO.println "hello"` is an *action*.
+Note that the examples above also demonstrates that braceless `do` blocks are whitespace sensitive.
+If you like `;`s and curly braces, you can write the example above as
+```lean
+def main : IO UInt32 := do {
+  IO.println "hello";
+  IO.println "world";
+  return 0;
+}
+```
+Semicolons can be used even when curly braces are not used. They are particularly useful when you want to "pack" more than one action in a single line.
+```lean
+def main : IO UInt32 := do
+  IO.println "hello"; IO.println "world"
+  return 0
+```
+Whitespace sensitivity in programming languages is a controversial topic
+among programmers. You should use your own style. We, the Lean developers, **love** the
+braceless and semicolon-free style.
+We believe it is clean and beautiful.
+
+The `do` DSL expands into the core Lean language. Let's inspect the different components using the commands `#print` and `#check`.
+
+```lean
+# def main : IO UInt32 := do
+#  IO.println "hello"
+#  IO.println "world"
+#  return 0
+
+#check IO.println "hello"
+-- IO Unit
+#print main
+-- Output contains the infix operator `>>=` and `pure`
+-- The following `set_option` disables notation such as `>>=` in the output
+set_option pp.notation false in
+#print main
+-- Output contains `bind` and `pure`
+#print bind
+-- bind : {m : Type u → Type v} → [self : Bind m] → {α β : Type u} →
+--        m α → (α → m β) → m β
+#print pure
+-- pure : {m : Type u → Type v} → [self : Pure m] → {α : Type u} →
+--        α → m α
+
+-- IO implements the type classes `Bind` and `Pure`.
+#check (inferInstance : Bind IO)
+#check (inferInstance : Pure IO)
+```
+The types of `bind` and `pure` may look daunting at first sight.
+They both have many implicit arguments. Let's focus first on the explicit arguments.
+`bind` has two explicit arguments `m α` and `α → m β`. The first one should
+be viewed as an action with effects `m` and producing a value of type `α`.
+The second is a function that takes a value of type `α` and produces an action
+with effects `m` and a value of type `β`. The result is `m β`. The method `bind` is composing
+these two actions. We often say `bind` is an abstract semicolon. The method `pure` converts
+a value `α` into an action that produces an action `m α`.
+
+Here is the same function being defined using `bind` and `pure` without the `do` DSL.
+```lean
+def main : IO UInt32 :=
+  bind (IO.println "hello") fun _ =>
+  bind (IO.println "world") fun _ =>
+  pure 0
+```
+
+The notations `let x <- action1; action2` and `let x ← action1; action2` are just syntax sugar for `bind action1 fun x => action2`.
+Here is a small example using it.
+```lean
+def isGreaterThan0 (x : Nat) : IO Bool := do
+  IO.println s!"value: {x}"
+  return x > 0
+
+def f (x : Nat) : IO Unit := do
+  let c <- isGreaterThan0 x
+  if c then
+    IO.println s!"{x} is greater than 0"
+  else
+    pure ()
+
+#eval f 10
+-- value: 10
+-- 10 is greater than 0
+```
+
+
+## Nested actions
+
+Note that we cannot write `if isGreaterThan0 x then ... else ...` because the condition in a `if-then-else` is a **pure** value without effects, but `isGreaterThan0 x` has type `IO Bool`. You can use the nested action notation to avoid this annoyance. Here is an equivalent definition for `f` using a nested action.
+```lean
+# def isGreaterThan0 (x : Nat) : IO Bool := do
+#  IO.println s!"x: {x}"
+#  return x > 0
+
+def f (x : Nat) : IO Unit := do
+  if (<- isGreaterThan0 x) then
+    IO.println s!"{x} is greater than 0"
+  else
+    pure ()
+
+#print f
+```
+Lean "lifts" the nested actions and introduces the `bind` for us.
+Here is an example with two nested actions. Note that both actions are executed
+even if `x = 0`.
+```lean
+# def isGreaterThan0 (x : Nat) : IO Bool := do
+#  IO.println s!"x: {x}"
+#  return x > 0
+
+def f (x y : Nat) : IO Unit := do
+  if (<- isGreaterThan0 x) && (<- isGreaterThan0 y) then
+    IO.println s!"{x} and {y} are greater than 0"
+  else
+    pure ()
+
+#eval f 0 10
+-- value: 0
+-- value: 10
+
+-- The function `f` above is equivalent to
+def g (x y : Nat) : IO Unit := do
+  let c1 <- isGreaterThan0 x
+  let c2 <- isGreaterThan0 y
+  if c1 && c2 then
+    IO.println s!"{x} and {y} are greater than 0"
+  else
+    pure ()
+
+theorem fgEqual : f = g :=
+  rfl -- proof by reflexivity
+```
+Here are two ways to achieve the short-circuit semantics in the example above
+```lean
+# def isGreaterThan0 (x : Nat) : IO Bool := do
+#  IO.println s!"x: {x}"
+#  return x > 0
+
+def f1 (x y : Nat) : IO Unit := do
+  if (<- isGreaterThan0 x <&&> isGreaterThan0 y) then
+    IO.println s!"{x} and {y} are greater than 0"
+  else
+    pure ()
+
+-- `<&&>` is the effectful version of `&&`
+-- Given `x y : IO Bool`, `x <&&> y` : m Bool`
+-- It only executes `y` if `x` returns `true`.
+
+#eval f1 0 10
+-- value: 0
+#eval f1 1 10
+-- value: 1
+-- value: 10
+-- 1 and 10 are greater than 0
+
+def f2 (x y : Nat) : IO Unit := do
+  if (<- isGreaterThan0 x) then
+    if (<- isGreaterThan0 y) then
+      IO.println s!"{x} and {y} are greater than 0"
+    else
+      pure ()
+  else
+    pure ()
+```
+
+## `if-then` notation
+
+In the `do` DSL, we can write `if c then action` as a shorthand for `if c then action else pure ()`. Here is the method `f2` using this shorthand.
+```lean
+# def isGreaterThan0 (x : Nat) : IO Bool := do
+#  IO.println s!"x: {x}"
+#  return x > 0
+
+def f2 (x y : Nat) : IO Unit := do
+  if (<- isGreaterThan0 x) then
+    if (<- isGreaterThan0 y) then
+      IO.println s!"{x} and {y} are greater than 0"
+```
+
+## Reassignments
+
+When writing effectful code, it is natural to think imperatively.
+For example, suppose we want to create an empty array `xs`,
+add `0` if some condition holds, add `1` if another condition holds,
+and then print it. In the following example, we use variable
+"shadowing" to simulate this kind of "update".
+
+```lean
+def f (b1 b2 : Bool) : IO Unit := do
+  let xs := #[]
+  let xs := if b1 then xs.push 0 else xs
+  let xs := if b2 then xs.push 1 else xs
+  IO.println xs
+
+#eval f true true
+-- #[0, 1]
+#eval f false true
+-- #[1]
+#eval f true false
+-- #[0]
+#eval f false false
+-- #[]
+```
+
+We can use tuples to simulate updates on multiple variables.
+
+```lean
+def f (b1 b2 : Bool) : IO Unit := do
+  let xs := #[]
+  let ys := #[]
+  let (xs, ys) := if b1 then (xs.push 0, ys) else (xs, ys.push 0)
+  let (xs, ys) := if b2 then (xs.push 1, ys) else (xs, ys.push 1)
+  IO.println s!"xs: {xs}, ys: {ys}"
+
+#eval f true false
+-- xs: #[0], ys: #[1]
+```
+
+We can also simulate the control-flow above using *join-points*.
+A join-point is a `let` that is always tail called and fully applied.
+The Lean compiler implements them using `goto`s.
+Here is the same example using join-points.
+
+```lean
+def f (b1 b2 : Bool) : IO Unit := do
+  let jp1 xs ys := IO.println s!"xs: {xs}, ys: {ys}"
+  let jp2 xs ys := if b2 then jp1 (xs.push 1) ys else jp1 xs (ys.push 1)
+  let xs := #[]
+  let ys := #[]
+  if b1 then jp2 (xs.push 0) ys else jp2 xs (ys.push 0)
+
+#eval f true false
+-- xs: #[0], ys: #[1]
+```
+
+You can capture complex control-flow using join-points.
+The `do` DSL offers the variable reassignment feature to make this kind of code more comfortable to write. In the following example, the `mut` modifier at `let mut xs := #[]` indicates that variable `xs` can be reassigned. The example contains two reassignments `xs := xs.push 0` and `xs := xs.push 1`. The reassignments are compiled using join-points. There is no hidden state being updated.
+
+```lean
+def f (b1 b2 : Bool) : IO Unit := do
+  let mut xs := #[]
+  if b1 then xs := xs.push 0
+  if b2 then xs := xs.push 1
+  IO.println xs
+
+#eval f true true
+-- #[0, 1]
+```
+The notation `x <- action` reassigns `x` with the value produced by the action. It is equivalent to `x := (<- action)`
+
+## Iteration
+
+The `do` DSL provides a unified notation for iterating over datastructures. Here are a few examples.
+
+```lean
+def sum (xs : Array Nat) : IO Nat := do
+  let mut s := 0
+  for x in xs do
+    IO.println s!"x: {x}"
+    s := s + x
+  return s
+
+#eval sum #[1, 2, 3]
+-- x: 1
+-- x: 2
+-- x: 3
+-- 6
+
+-- 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
+  return s
+
+#eval sum' #[1, 2, 3]
+-- 6
+
+def sumEven (xs : Array Nat) : IO Nat := do
+  let mut s := 0
+  for x in xs do
+    if x % 2 == 0 then
+      IO.println s!"x: {x}"
+      s := s + x
+  return s
+
+#eval sumEven #[1, 2, 3, 6]
+-- x: 2
+-- x: 6
+-- 8
+
+def splitEvenOdd (xs : List Nat) : IO Unit := do
+  let mut evens := #[]
+  let mut odds  := #[]
+  for x in xs do
+    if x % 2 == 0 then
+      evens := evens.push x
+    else
+      odds := odds.push x
+  IO.println s!"evens: {evens}, odds: {odds}"
+
+#eval splitEvenOdd [1, 2, 3, 4]
+-- evens: #[2, 4], odds: #[1, 3]
+
+def findNatLessThan (x : Nat) (p : Nat → Bool) : IO Nat := do
+  -- [:x] is notation for the range [0, x)
+  for i in [:x] do
+    if p i then
+      return i -- `return` from the `do` block
+  throw (IO.userError "value not found")
+
+#eval findNatLessThan 10 (fun x => x > 5 && x % 4 == 0)
+-- 8
+
+def sumOddUpTo (xs : List Nat) (threshold : Nat) : IO Nat := do
+  let mut s := 0
+  for x in xs do
+    if x % 2 == 0 then
+      continue -- it behaves like the `continue` statement in imperative languages
+    IO.println s!"x: {x}"
+    s := s + x
+    if s > threshold then
+      break -- it behaves like the `break` statement in imperative languages
+  IO.println s!"result: {s}"
+  return s
+
+#eval sumOddUpTo [2, 3, 4, 11, 20, 31, 41, 51, 107] 40
+-- x: 3
+-- x: 11
+-- x: 31
+-- result: 45
+-- 45
+```
+
+TODO: describe `forIn`
+
+## Try-catch
+
+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
+
+## Monads
+
+TODO
+
+## ReaderT
+
+TODO
+
+## StateT
+
+TODO
+
+## StateRefT
+
+TODO
+
+## ExceptT
+
+TODO
+
+## MonadLift and automatic lifting
+
+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/enum.md

@@ -0,0 +1,190 @@
+# Enumerated Types
+
+The simplest kind of inductive type is simply a type with a finite, enumerated list of elements.
+The following command declares the enumerated type `Weekday`.
+```lean
+inductive Weekday where
+  | sunday    : Weekday
+  | monday    : Weekday
+  | tuesday   : Weekday
+  | wednesday : Weekday
+  | thursday  : Weekday
+  | friday    : Weekday
+  | saturday  : Weekday
+```
+
+The `Weekday` type has 7 constructors/elements. The constructors live in the `Weekday` namespace
+Think of `sunday`, `monday`, …, `saturday` as being distinct elements of `Weekday`,
+with no other distinguishing properties.
+```lean
+# inductive Weekday where
+#  | sunday    : Weekday
+#  | monday    : Weekday
+#  | tuesday   : Weekday
+#  | wednesday : Weekday
+#  | thursday  : Weekday
+#  | friday    : Weekday
+#  | saturday  : Weekday
+#check Weekday.sunday   -- Weekday
+#check Weekday.monday   -- Weekday
+```
+
+You can define functions by pattern matching.
+The following function converts a `Weekday` into a natural number.
+```lean
+# inductive Weekday where
+#  | sunday    : Weekday
+#  | monday    : Weekday
+#  | tuesday   : Weekday
+#  | wednesday : Weekday
+#  | thursday  : Weekday
+#  | friday    : Weekday
+#  | saturday  : Weekday
+def natOfWeekday (d : Weekday) : Nat :=
+  match d with
+  | Weekday.sunday    => 1
+  | Weekday.monday    => 2
+  | Weekday.tuesday   => 3
+  | Weekday.wednesday => 4
+  | Weekday.thursday  => 5
+  | Weekday.friday    => 6
+  | Weekday.saturday  => 7
+
+#eval natOfWeekday Weekday.tuesday -- 3
+```
+
+It is often useful to group definitions related to a type in a namespace with the same name.
+For example, we can put the function above into the ``Weekday`` namespace.
+We are then allowed to use the shorter name when we open the namespace.
+
+In the following example, we define functions from ``Weekday`` to ``Weekday`` in the namespace `Weekday`.
+```lean
+# inductive Weekday where
+#  | sunday    : Weekday
+#  | monday    : Weekday
+#  | tuesday   : Weekday
+#  | wednesday : Weekday
+#  | thursday  : Weekday
+#  | friday    : Weekday
+#  | saturday  : Weekday
+namespace Weekday
+
+def next (d : Weekday) : Weekday :=
+  match d with
+  | sunday    => monday
+  | monday    => tuesday
+  | tuesday   => wednesday
+  | wednesday => thursday
+  | thursday  => friday
+  | friday    => saturday
+  | saturday  => sunday
+
+end Weekday
+```
+It is so common to start a definition with a `match` in Lean, that Lean provides a syntax sugar for it.
+```lean
+# inductive Weekday where
+#  | sunday    : Weekday
+#  | monday    : Weekday
+#  | tuesday   : Weekday
+#  | wednesday : Weekday
+#  | thursday  : Weekday
+#  | friday    : Weekday
+#  | saturday  : Weekday
+# namespace Weekday
+def previous : Weekday -> Weekday
+  | sunday    => saturday
+  | monday    => sunday
+  | tuesday   => monday
+  | wednesday => tuesday
+  | thursday  => wednesday
+  | friday    => thursday
+  | saturday  => friday
+# end Weekday
+```
+We can use the command `#eval` to test our definitions.
+```lean
+# inductive Weekday where
+#  | sunday    : Weekday
+#  | monday    : Weekday
+#  | tuesday   : Weekday
+#  | wednesday : Weekday
+#  | thursday  : Weekday
+#  | friday    : Weekday
+#  | saturday  : Weekday
+# namespace Weekday
+# def next (d : Weekday) : Weekday :=
+#  match d with
+#  | sunday    => monday
+#  | monday    => tuesday
+#  | tuesday   => wednesday
+#  | wednesday => thursday
+#  | thursday  => friday
+#  | friday    => saturday
+#  | saturday  => sunday
+# def previous : Weekday -> Weekday
+#  | sunday    => saturday
+#  | monday    => sunday
+#  | tuesday   => monday
+#  | wednesday => tuesday
+#  | thursday  => wednesday
+#  | friday    => thursday
+#  | saturday  => friday
+def toString : Weekday -> String
+  | sunday    => "Sunday"
+  | monday    => "Monday"
+  | tuesday   => "Tuesday"
+  | wednesday => "Wednesday"
+  | thursday  => "Thursday"
+  | friday    => "Friday"
+  | saturday  => "Saturday"
+
+#eval toString (next sunday)             -- "Monday"
+#eval toString (next tuesday)            -- "Wednesday"
+#eval toString (previous wednesday)      -- "Tuesday"
+#eval toString (next (previous sunday))  -- "Sunday"
+#eval toString (next (previous monday))  -- "Monday"
+-- ..
+# end Weekday
+```
+We can now prove the general theorem that ``next (previous d) = d`` for any weekday ``d``.
+The idea is to perform a proof by cases using `match`, and rely on the fact for each constructor both
+sides of the equality reduce to the same term.
+```lean
+# inductive Weekday where
+#  | sunday    : Weekday
+#  | monday    : Weekday
+#  | tuesday   : Weekday
+#  | wednesday : Weekday
+#  | thursday  : Weekday
+#  | friday    : Weekday
+#  | saturday  : Weekday
+# namespace Weekday
+# def next (d : Weekday) : Weekday :=
+#  match d with
+#  | sunday    => monday
+#  | monday    => tuesday
+#  | tuesday   => wednesday
+#  | wednesday => thursday
+#  | thursday  => friday
+#  | friday    => saturday
+#  | saturday  => sunday
+# def previous : Weekday -> Weekday
+#  | sunday    => saturday
+#  | monday    => sunday
+#  | tuesday   => monday
+#  | wednesday => tuesday
+#  | thursday  => wednesday
+#  | friday    => thursday
+#  | saturday  => friday
+theorem nextOfPrevious (d : Weekday) : next (previous d) = d :=
+  match d with
+  | sunday    => rfl
+  | monday    => rfl
+  | tuesday   => rfl
+  | wednesday => rfl
+  | thursday  => rfl
+  | friday    => rfl
+  | saturday  => rfl
+# end Weekday
+```

doc/examples/Certora2022/ex8.lean

@@ -4,16 +4,16 @@ 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 x y => (x, y)
+termination_by ack x y => (x, y)
 
 def sum (a : Array Int) : Int :=
   let rec go (i : Nat) :=
-     if _ : i < a.size then
+     if i < a.size then
         a[i] + go (i+1)
      else
         0
-  termination_by a.size - i
   go 0
+termination_by go i => a.size - i
 
 set_option pp.proofs true
 #print sum.go

doc/examples/ICERM2022/ctor.lean

@@ -4,42 +4,43 @@ open Lean Meta
 
 def ctor (mvarId : MVarId) (idx : Nat) : MetaM (List MVarId) := do
   /- Set `MetaM` context using `mvarId` -/
-  mvarId.withContext do
+  withMVarContext mvarId do 
     /- Fail if the metavariable is already assigned. -/
-    mvarId.checkNotAssigned `ctor
+    checkNotAssigned mvarId `ctor
     /- Retrieve the target type, instantiateMVars, and use `whnf`. -/
-    let target ← mvarId.getType'
+    let target ← getMVarType' mvarId
     let .const declName us := target.getAppFn
       | throwTacticEx `ctor mvarId "target is not an inductive datatype"
     let .inductInfo { ctors, .. } ← getConstInfo declName
       | throwTacticEx `ctor mvarId "target is not an inductive datatype"
     if idx = 0 then
-      throwTacticEx `ctor mvarId "invalid index, it must be > 0"
+      throwTacticEx `ctor mvarId "invalid index, it must be > 0"  
     else if h : idx - 1 < ctors.length then
-      mvarId.apply (.const ctors[idx - 1] us)
+      apply mvarId (.const ctors[idx - 1] us)
     else
-      throwTacticEx `ctor mvarId "invalid index, inductive datatype has only {ctors.length} constructors"
+      throwTacticEx `ctor mvarId "invalid index, inductive datatype has only {ctors.length} contructors"  
 
 open Elab Tactic
 
-elab "ctor" idx:num : tactic =>
+elab "ctor" idx:num : tactic => 
   liftMetaTactic (ctor · idx.getNat)
 
-example (p : Prop) : p := by
+example (p : Prop) : p := by 
   ctor 1 -- Error
 
-example (h : q) : p ∨ q := by
+example (h : q) : p ∨ q := by 
   ctor 0 -- Error
   exact h
 
-example (h : q) : p ∨ q := by
+example (h : q) : p ∨ q := by 
   ctor 3 -- Error
   exact h
 
-example (h : q) : p ∨ q := by
+example (h : q) : p ∨ q := by 
   ctor 2
   exact h
 
-example (h : q) : p ∨ q := by
+example (h : q) : p ∨ q := by 
   ctor 1
-  exact h -- Error
+  exact h -- Error 
+

doc/examples/ICERM2022/meta.lean

@@ -5,15 +5,15 @@ open Lean Meta
 def ex1 (declName : Name) : MetaM Unit := do
   let info ← getConstInfo declName
   IO.println s!"{declName} : {← ppExpr info.type}"
-  if let some val := info.value? then
+  if let some val := info.value? then 
     IO.println s!"{declName} : {← ppExpr val}"
-
+    
 #eval ex1 ``Nat
 
 def ex2 (declName : Name) : MetaM Unit := do
   let info ← getConstInfo declName
   trace[Meta.debug] "{declName} : {info.type}"
-  if let some val := info.value? then
+  if let some val := info.value? then 
     trace[Meta.debug] "{declName} : {val}"
 
 #eval ex2 ``Add.add
@@ -29,10 +29,10 @@ def ex3 (declName : Name) : MetaM Unit := do
     for x in xs do
       trace[Meta.debug] "{x} : {← inferType x}"
 
-def myMin [LT α] [DecidableLT α] (a b : α) : α :=
-  if a < b then
+def myMin [LT α] [DecidableRel (α := α) (·<·)] (a b : α) : α :=
+  if a < b then 
     a
-  else
+  else 
     b
 
 set_option trace.Meta.debug true in
@@ -40,7 +40,7 @@ set_option trace.Meta.debug true in
 
 def ex4 : MetaM Unit := do
   let nat := mkConst ``Nat
-  withLocalDeclD `a nat fun a =>
+  withLocalDeclD `a nat fun a => 
   withLocalDeclD `b nat fun b => do
     let e ← mkAppM ``HAdd.hAdd #[a, b]
     trace[Meta.debug] "{e} : {← inferType e}"
@@ -66,17 +66,15 @@ open Elab Term
 
 def ex5 : TermElabM Unit := do
   let nat := Lean.mkConst ``Nat
-  withLocalDeclD `a nat fun a => do
+  withLocalDeclD `a nat fun a => do 
   withLocalDeclD `b nat fun b => do
     let ab ← mkAppM ``HAdd.hAdd #[a, b]
-    let abStx ← exprToSyntax ab
-    let aStx ← exprToSyntax a
-    let stx ← `(fun x => if x < 10 then $abStx + x else x + $aStx)
+    let stx ← `(fun x => if x < 10 then $(← exprToSyntax ab) + x else x + $(← exprToSyntax a))
     let e ← elabTerm stx none
     trace[Meta.debug] "{e} : {← inferType e}"
     let e := mkApp e (mkNatLit 5)
     let e ← whnf e
     trace[Meta.debug] "{e}"
-
+       
 set_option trace.Meta.debug true in
 #eval ex5

doc/examples/NFM2022/nfm8.lean

@@ -4,16 +4,16 @@ 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 x y => (x, y)
+termination_by ack x y => (x, y)
 
 def sum (a : Array Int) : Int :=
   let rec go (i : Nat) :=
-     if _ : i < a.size then
+     if i < a.size then
         a[i] + go (i+1)
      else
         0
-  termination_by a.size - i
   go 0
+termination_by go i => a.size - i
 
 set_option pp.proofs true
 #print sum.go

doc/examples/bintree.lean

@@ -5,7 +5,7 @@ If the type of keys can be totally ordered -- that is, it supports a well-behave
 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 ["Software Foundations"](https://softwarefoundations.cis.upenn.edu/vfa-current/SearchTree.html)
+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).
 -/
 
@@ -81,9 +81,9 @@ def Tree.toList (t : Tree β) : List (Nat × β) :=
       |>.toList
 
 /-!
-The implementation of `Tree.toList` is inefficient because of how it uses the `++` operator.
+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
-concatenations at each level of the tree. On an unbalanced tree it's quadratic time.
+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 × β) :=
@@ -114,9 +114,9 @@ concatenating all goals produced by `tac'`. In this theorem, we use it to apply
 
 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 `*` instructs the simplifier to use any equation in a goal as rewriting rules.
+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` instructs the simplifier to use the
+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 β)
@@ -186,7 +186,7 @@ local macro "have_eq " lhs:term:max rhs:term:max : tactic =>
 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 simplifier uses the `h` to rewrite `e` to `True`
+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.
 -/
@@ -277,13 +277,14 @@ theorem BinTree.find_insert (b : BinTree β) (k : Nat) (v : β)
     . by_cases' key < k
       cases h; apply ihr; assumption
 
-theorem BinTree.find_insert_of_ne (b : BinTree β) (ne : k ≠ k') (v : β)
+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 =>
-    intros le
-    exact Nat.lt_of_le_of_ne le ne
+    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

doc/examples/compiler/.gitignore

@@ -1 +0,0 @@
-build

doc/examples/deBruijn.lean

@@ -149,10 +149,10 @@ We now define the constant folding optimization that traverses a term if replace
 /-!
 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/simplifications rules.
+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 simplifier to use the equation as a rewriting rule in
+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

doc/examples/interp.lean

@@ -12,17 +12,17 @@ Remark: this example is based on an example found in the Idris manual.
 Vectors
 --------
 
-A `Vec` is a list of size `n` whose elements belong to a type `α`.
+A `Vector` is a list of size `n` whose elements belong to a type `α`.
 -/
 
-inductive Vec (α : Type u) : Nat → Type u
-  | nil : Vec α 0
-  | cons : α → Vec α n → Vec α (n+1)
+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 `Vec`s.
+We can overload the `List.cons` notation `::` and use it to create `Vector`s.
 -/
-infix:67 " :: " => Vec.cons
+infix:67 " :: " => Vector.cons
 
 /-!
 Now, we define the types of our simple functional language.
@@ -50,11 +50,11 @@ the builtin instance for `Add Int` as the solution.
 /-!
 Expressions are indexed by the types of the local variables, and the type of the expression itself.
 -/
-inductive HasType : Fin n → Vec Ty n → Ty → Type where
+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 : Vec Ty n → Ty → Type where
+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)
@@ -83,7 +83,7 @@ In practice, this means we use `stop` to refer to the most recently defined vari
 
 A value `Expr.val` carries a concrete representation of an integer.
 
-A lambda `Expr.lam` creates a function. In the scope of a function of type `Ty.fn a ty`, there is a
+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`.
@@ -102,8 +102,8 @@ indexed over the types in scope. Since an environment is just another form of li
 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 : Vec Ty n → Type where
-  | nil  : Env Vec.nil
+inductive Env : Vector Ty n → Type where
+  | nil  : Env Vector.nil
   | cons : Ty.interp a → Env ctx → Env (a :: ctx)
 
 infix:67 " :: " => Env.cons
@@ -139,7 +139,7 @@ def add : Expr ctx (Ty.fn Ty.int (Ty.fn Ty.int Ty.int)) :=
 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 viewed as
+`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.
 -/
 
@@ -149,4 +149,4 @@ def fact : Expr ctx (Ty.fn Ty.int Ty.int) :=
            (op (·*·) (delay fun _ => app fact (op (·-·) (var stop) (val 1))) (var stop)))
   decreasing_by sorry
 
-#eval! fact.interp Env.nil 10
+#eval fact.interp Env.nil 10

doc/examples/palindromes.lean

@@ -82,7 +82,7 @@ theorem List.palindrome_ind (motive : List α → Prop)
     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.length
+termination_by _ as => as.length
 
 /-!
 We use our new induction principle to prove that if `as.reverse = as`, then `Palindrome as` holds.

doc/examples/phoas.lean

@@ -225,10 +225,10 @@ We now define the constant folding optimization that traverses a term if replace
 /-!
 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/simplifications rules.
+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 simplifier to use the equation as a rewriting rule in
+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

doc/examples/tc.lean

@@ -29,7 +29,7 @@ inductive HasType : Expr → Ty → Prop
 
 /-!
 We can easily show that if `e` has type `t₁` and type `t₂`, then `t₁` and `t₂` must be equal
-by using the `cases` tactic. This tactic creates a new subgoal for every constructor,
+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.
@@ -38,7 +38,7 @@ theorem HasType.det (h₁ : HasType e t₁) (h₂ : HasType e t₂) : t₁ = t
   cases h₁ <;> cases h₂ <;> rfl
 
 /-!
-The inductive type `Maybe p` has two constructors: `found a h` and `unknown`.
+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".
 -/
@@ -82,7 +82,9 @@ theorem Expr.typeCheck_correct (h₁ : HasType e ty) (h₂ : e.typeCheck ≠ .un
 /-!
 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. Note that the tactic `simp [typeCheck]` is applied to all goal generated by the `induction` tactic, and closes
+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

doc/examples/test_single.sh

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

doc/examples/widgets.lean

@@ -4,97 +4,76 @@ open Lean Widget
 /-!
 # The user-widgets system
 
-Proving and programming are inherently interactive tasks.
-Lots of mathematical objects and data structures are visual in nature.
-*User widgets* let you associate custom interactive UIs
-with sections of a Lean document.
-User widgets are rendered in the Lean infoview.
+Proving and programming are inherently interactive tasks. Lots of mathematical objects and data
+structures are visual in nature. *User widgets* let you associate custom interactive UIs with
+sections of a Lean document. User widgets are rendered in the Lean infoview.
 
 ![Rubik's cube](../images/widgets_rubiks.png)
 
 ## Trying it out
 
-To try it out, type in the following code and place your cursor over the `#widget` command.
-You can also [view this manual entry in the online editor](https://live.lean-lang.org/#url=https%3A%2F%2Fraw.githubusercontent.com%2Fleanprover%2Flean4%2Fmaster%2Fdoc%2Fexamples%2Fwidgets.lean).
+To try it out, simply type in the following code and place your cursor over the `#widget` command.
 -/
 
-@[widget_module]
-def helloWidget : Widget.Module where
+@[widget]
+def helloWidget : UserWidgetDefinition where
+  name := "Hello"
   javascript := "
     import * as React from 'react';
     export default function(props) {
       const name = props.name || 'world'
-      return React.createElement('p', {}, 'Hello ' + name + '!')
+      return React.createElement('p', {}, name + '!')
     }"
 
-#widget helloWidget
+#widget helloWidget .null
 
 /-!
 If you want to dive into a full sample right away, check out
-[`Rubiks`](https://github.com/leanprover-community/ProofWidgets4/blob/main/ProofWidgets/Demos/Rubiks.lean).
-This sample uses higher-level widget components from the ProofWidgets library.
-
+[`RubiksCube`](https://github.com/leanprover/lean4-samples/blob/main/RubiksCube/).
 Below, we'll explain the system piece by piece.
 
 ⚠️ WARNING: All of the user widget APIs are **unstable** and subject to breaking changes.
 
-## Widget modules and instances
+## Widget sources and instances
 
-A [widget module](https://leanprover-community.github.io/mathlib4_docs/Lean/Widget/UserWidget.html#Lean.Widget.Module)
-is a valid JavaScript [ESModule](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Modules)
-that can execute in the Lean infoview.
-Most widget modules export a [React component](https://reactjs.org/docs/components-and-props.html)
-as the piece of user interface to be rendered.
-To access React, the module can use `import * as React from 'react'`.
-Our first example of a widget module is `helloWidget` above.
-Widget modules must be registered with the `@[widget_module]` attribute.
+A *widget source* is a valid JavaScript [ESModule](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Modules)
+which exports a [React component](https://reactjs.org/docs/components-and-props.html). To access
+React, the module must use `import * as React from 'react'`. Our first example of a widget source
+is of course the value of `helloWidget.javascript`.
 
-A [widget instance](https://leanprover-community.github.io/mathlib4_docs/Lean/Widget/Types.html#Lean.Widget.WidgetInstance)
-is then the identifier of a widget module (e.g. `` `helloWidget ``)
-bundled with a value for its props.
-This value is passed as the argument to the React component.
-In our first invocation of `#widget`, we set it to `.null`.
-Try out what happens when you type in:
+We can register a widget source with the `@[widget]` attribute, giving it a friendlier name
+in the `name` field. This is bundled together in a `UserWidgetDefinition`.
+
+A *widget instance* is then the identifier of a `UserWidgetDefinition` (so `` `helloWidget ``,
+not `"Hello"`) associated with a range of positions in the Lean source code. Widget instances
+are stored in the *infotree* in the same manner as other information about the source file
+such as the type of every expression. In our example, the `#widget` command stores a widget instance
+with the entire line as its range. We can think of a widget instance as an instruction for the
+infoview: "when the user places their cursor here, please render the following widget".
+
+Every widget instance also contains a `props : Json` value. This value is passed as an argument
+to the React component. In our first invocation of `#widget`, we set it to `.null`. Try out what
+happens when you type in:
 -/
 
-structure HelloWidgetProps where
-  name? : Option String := none
-  deriving Server.RpcEncodable
-
-#widget helloWidget with { name? := "<your name here>" : HelloWidgetProps }
+#widget helloWidget (Json.mkObj [("name", "<your name here>")])
 
 /-!
-Under the hood, widget instances are associated with a range of positions in the source file.
-Widget instances are stored in the *infotree*
-in the same manner as other information about the source file
-such as the type of every expression.
-In our example, the `#widget` command stores a widget instance
-with the entire line as its range.
-One can think of the infotree entry as an instruction for the infoview:
-"when the user places their cursor here, please render the following widget".
--/
+💡 NOTE: The RPC system presented below does not depend on JavaScript. However the primary use case
+is the web-based infoview in VSCode.
 
-/-!
 ## Querying the Lean server
 
-💡 NOTE: The RPC system presented below does not depend on JavaScript.
-However, the primary use case is the web-based infoview in VSCode.
+Besides enabling us to create cool client-side visualizations, user widgets come with the ability
+to communicate with the Lean server. Thanks to this, they have the same metaprogramming capabilities
+as custom elaborators or the tactic framework. To see this in action, let's implement a `#check`
+command as a web input form. This example assumes some familiarity with React.
 
-Besides enabling us to create cool client-side visualizations,
-user widgets have the ability to communicate with the Lean server.
-Thanks to this, they have the same metaprogramming capabilities
-as custom elaborators or the tactic framework.
-To see this in action, let's implement a `#check` command as a web input form.
-This example assumes some familiarity with React.
-
-The first thing we'll need is to create an *RPC method*.
-Meaning "Remote Procedure Call",this is a Lean function callable from widget code
-(possibly remotely over the internet).
+The first thing we'll need is to create an *RPC method*. Meaning "Remote Procedure Call", this
+is basically a Lean function callable from widget code (possibly remotely over the internet).
 Our method will take in the `name : Name` of a constant in the environment and return its type.
-By convention, we represent the input data as a `structure`.
-Since it will be sent over from JavaScript,
-we need `FromJson` and `ToJson` instance.
-We'll see why the position field is needed later.
+By convention, we represent the input data as a `structure`. Since it will be sent over from JavaScript,
+we need `FromJson` and `ToJson`. We'll see below why the position field is needed.
 -/
 
 structure GetTypeParams where
@@ -105,33 +84,25 @@ structure GetTypeParams where
   deriving FromJson, ToJson
 
 /-!
-After its argument structure, we define the `getType` method.
-RPCs method execute in the `RequestM` monad and must return a `RequestTask α`
-where `α` is the "actual" return type.
-The `Task` is so that requests can be handled concurrently.
-As a first guess, we'd use `Expr` as `α`.
-However, expressions in general can be large objects
-which depend on an `Environment` and `LocalContext`.
-Thus we cannot directly serialize an `Expr` and send it to JavaScript.
-Instead, there are two options:
+After its arguments, we define the `getType` method. Every RPC method executes in the `RequestM`
+monad and must return a `RequestTask α` where `α` is its "actual" return type. The `Task` is so
+that requests can be handled concurrently. A first guess for `α` might be `Expr`. However,
+expressions in general can be large objects which depend on an `Environment` and `LocalContext`.
+Thus we cannot directly serialize an `Expr` and send it to the widget. Instead, there are two
+options:
+- One is to send a *reference* which points to an object residing on the server. From JavaScript's
+  point of view, references are entirely opaque, but they can be sent back to other RPC methods for
+  further processing.
+- Two is to pretty-print the expression and send its textual representation called `CodeWithInfos`.
+  This representation contains extra data which the infoview uses for interactivity. We take this
+  strategy here.
 
-- One is to send a *reference* which points to an object residing on the server.
-  From JavaScript's point of view, references are entirely opaque,
-  but they can be sent back to other RPC methods for further processing.
-- The other is to pretty-print the expression and send its textual representation called `CodeWithInfos`.
-  This representation contains extra data which the infoview uses for interactivity.
-  We take this strategy here.
-
-RPC methods execute in the context of a file,
-but not of any particular `Environment`,
-so they don't know about the available `def`initions and `theorem`s.
-Thus, we need to pass in a position at which we want to use the local `Environment`.
-This is why we store it in `GetTypeParams`.
-The `withWaitFindSnapAtPos` method launches a concurrent computation
-whose job is to find such an `Environment` for us,
-in the form of a `snap : Snapshot`.
-With this in hand, we can call `MetaM` procedures
-to find out the type of `name` and pretty-print it.
+RPC methods execute in the context of a file, but not any particular `Environment` so they don't
+know about the available `def`initions and `theorem`s. Thus, we need to pass in a position at which
+we want to use the local `Environment`. This is why we store it in `GetTypeParams`. The `withWaitFindSnapAtPos`
+method launches a concurrent computation whose job is to find such an `Environment` and a bit
+more information for us, in the form of a `snap : Snapshot`. With this in hand, we can call
+`MetaM` procedures to find out the type of `name` and pretty-print it.
 -/
 
 open Server RequestM in
@@ -140,40 +111,37 @@ def getType (params : GetTypeParams) : RequestM (RequestTask CodeWithInfos) :=
   withWaitFindSnapAtPos params.pos fun snap => do
     runTermElabM snap do
       let name ← resolveGlobalConstNoOverloadCore params.name
-      let c ← try getConstInfo name
-        catch _ => throwThe RequestError ⟨.invalidParams, s!"no constant named '{name}'"⟩
+      let some c ← Meta.getConst? name
+        | throwThe RequestError ⟨.invalidParams, s!"no constant named '{name}'"⟩
       Widget.ppExprTagged c.type
 
 /-!
 ## Using infoview components
 
-Now that we have all we need on the server side, let's write the widget module.
-By importing `@leanprover/infoview`, widgets can render UI components used to implement the infoview itself.
-For example, the `<InteractiveCode>` component displays expressions
-with `term : type` tooltips as seen in the goal view.
-We will use it to implement our custom `#check` display.
+Now that we have all we need on the server side, let's write the widget source. By importing
+`@leanprover/infoview`, widgets can render UI components used to implement the infoview itself.
+For example, the `<InteractiveCode>` component displays expressions with `term : type` tooltips
+as seen in the goal view. We will use it to implement our custom `#check` display.
 
 ⚠️ WARNING: Like the other widget APIs, the infoview JS API is **unstable** and subject to breaking changes.
 
-The code below demonstrates useful parts of the API.
-To make RPC method calls, we invoke the `useRpcSession` hook.
-The `useAsync` helper packs the results of an RPC call into an `AsyncState` structure
-which indicates whether the call has resolved successfully,
-has returned an error, or is still in-flight.
-Based on this we either display an `InteractiveCode` component with the result,
-`mapRpcError` the error in order to turn it into a readable message,
-or show a `Loading..` message, respectively.
+The code below demonstrates useful parts of the API. To make RPC method calls, we use the `RpcContext`.
+The `useAsync` helper packs the results of a call into an `AsyncState` structure which indicates
+whether the call has resolved successfully, has returned an error, or is still in-flight. Based
+on this we either display an `InteractiveCode` with the type, `mapRpcError` the error in order
+to turn it into a readable message, or show a `Loading..` message, respectively.
 -/
 
-@[widget_module]
-def checkWidget : Widget.Module where
+@[widget]
+def checkWidget : UserWidgetDefinition where
+  name := "#check as a service"
   javascript := "
 import * as React from 'react';
 const e = React.createElement;
-import { useRpcSession, InteractiveCode, useAsync, mapRpcError } from '@leanprover/infoview';
+import { RpcContext, InteractiveCode, useAsync, mapRpcError } from '@leanprover/infoview';
 
 export default function(props) {
-  const rs = useRpcSession()
+  const rs = React.useContext(RpcContext)
   const [name, setName] = React.useState('getType')
 
   const st = useAsync(() =>
@@ -189,45 +157,45 @@ export default function(props) {
 "
 
 /-!
-We can now try out the widget.
+Finally we can try out the widget.
 -/
 
-#widget checkWidget
+#widget checkWidget .null
 
 /-!
 ![`#check` as a service](../images/widgets_caas.png)
 
 ## Building widget sources
 
-While typing JavaScript inline is fine for a simple example,
-for real developments we want to use packages from NPM, a proper build system, and JSX.
-Thus, most actual widget sources are built with Lake and NPM.
-They consist of multiple files and may import libraries which don't work as ESModules by default.
-On the other hand a widget module must be a single, self-contained ESModule in the form of a string.
-Readers familiar with web development may already have guessed that to obtain such a string, we need a *bundler*.
-Two popular choices are [`rollup.js`](https://rollupjs.org/guide/en/)
-and [`esbuild`](https://esbuild.github.io/).
-If we go with `rollup.js`, to make a widget work with the infoview we need to:
+While typing JavaScript inline is fine for a simple example, for real developments we want to use
+packages from NPM, a proper build system, and JSX. Thus, most actual widget sources are built with
+Lake and NPM. They consist of multiple files and may import libraries which don't work as ESModules
+by default. On the other hand a widget source must be a single, self-contained ESModule in the form
+of a string. Readers familiar with web development may already have guessed that to obtain such a
+string, we need a *bundler*. Two popular choices are [`rollup.js`](https://rollupjs.org/guide/en/)
+and [`esbuild`](https://esbuild.github.io/). If we go with `rollup.js`, to make a widget work with
+the infoview we need to:
 - Set [`output.format`](https://rollupjs.org/guide/en/#outputformat) to `'es'`.
 - [Externalize](https://rollupjs.org/guide/en/#external) `react`, `react-dom`, `@leanprover/infoview`.
   These libraries are already loaded by the infoview so they should not be bundled.
 
-ProofWidgets provides a working `rollup.js` build configuration in
-[rollup.config.js](https://github.com/leanprover-community/ProofWidgets4/blob/main/widget/rollup.config.js).
+In the RubiksCube sample, we provide a working `rollup.js` build configuration in
+[rollup.config.js](https://github.com/leanprover/lean4-samples/blob/main/RubiksCube/widget/rollup.config.js).
 
 ## Inserting text
 
-Besides making RPC calls, widgets can instruct the editor to carry out certain actions.
-We can insert text, copy text to the clipboard, or highlight a certain location in the document.
-To do this, use the `EditorContext` React context.
-This will return an `EditorConnection`
-whose `api` field contains a number of methods that interact with the editor.
+We can also instruct the editor to insert text, copy text to the clipboard, or
+reveal a certain location in the document.
+To do this, use the `React.useContext(EditorContext)` React context.
+This will return an `EditorConnection` whose `api` field contains a number of methods to
+interact with the text editor.
 
-The full API can be viewed [here](https://github.com/leanprover/vscode-lean4/blob/master/lean4-infoview-api/src/infoviewApi.ts#L52).
+You can see the full API for this [here](https://github.com/leanprover/vscode-lean4/blob/master/lean4-infoview-api/src/infoviewApi.ts#L52)
 -/
 
-@[widget_module]
-def insertTextWidget : Widget.Module where
+@[widget]
+def insertTextWidget : UserWidgetDefinition where
+  name := "textInserter"
   javascript := "
 import * as React from 'react';
 const e = React.createElement;
@@ -243,4 +211,6 @@ export default function(props) {
 }
 "
 
-#widget insertTextWidget
+/-! Finally, we can try this out: -/
+
+#widget insertTextWidget .null

doc/expressions.md

@@ -396,7 +396,7 @@ Every expression in Lean has a natural computational interpretation, unless it i
 
 * *β-reduction* : An expression ``(λ x, t) s`` β-reduces to ``t[s/x]``, that is, the result of replacing ``x`` by ``s`` in ``t``.
 * *ζ-reduction* : An expression ``let x := s in t`` ζ-reduces to ``t[s/x]``.
-* *δ-reduction* : If ``c`` is a defined constant with definition ``t``, then ``c`` δ-reduces to ``t``.
+* *δ-reduction* : If ``c`` is a defined constant with definition ``t``, then ``c`` δ-reduces to to ``t``.
 * *ι-reduction* : When a function defined by recursion on an inductive type is applied to an element given by an explicit constructor, the result ι-reduces to the specified function value, as described in [Inductive Types](inductive.md).
 
 The reduction relation is transitive, which is to say, is ``s`` reduces to ``s'`` and ``t`` reduces to ``t'``, then ``s t`` reduces to ``s' t'``, ``λ x, s`` reduces to ``λ x, s'``, and so on. If ``s`` and ``t`` reduce to a common term, they are said to be *definitionally equal*. Definitional equality is defined to be the smallest equivalence relation that satisfies all these properties and also includes α-equivalence and the following two relations:
@@ -406,7 +406,7 @@ The reduction relation is transitive, which is to say, is ``s`` reduces to ``s'`
 
 This last fact reflects the intuition that once we have proved a proposition ``p``, we only care that is has been proved; the proof does nothing more than witness the fact that ``p`` is true.
 
-Definitional equality is a strong notion of equality of values. Lean's logical foundations sanction treating definitionally equal terms as being the same when checking that a term is well-typed and/or that it has a given type.
+Definitional equality is a strong notion of equalty of values. Lean's logical foundations sanction treating definitionally equal terms as being the same when checking that a term is well-typed and/or that it has a given type.
 
 The reduction relation is believed to be strongly normalizing, which is to say, every sequence of reductions applied to a term will eventually terminate. The property guarantees that Lean's type-checking algorithm terminates, at least in principle. The consistency of Lean and its soundness with respect to set-theoretic semantics do not depend on either of these properties.
 

doc/faq.md

@@ -7,6 +7,15 @@ Lean is a new open source theorem prover being developed at Microsoft Research.
 It is a research project that aims to bridge the gap between interactive and automated theorem proving.
 Lean can be also used as a programming language. Actually, some Lean features are implemented in Lean itself.
 
+### Are pull requests welcome?
+
+In the past, we accepted most pull requests. This practice produced hard to maintain code, performance problems, and bugs.
+It takes time to review a pull request and make sure it is correct, useful and is not in conflict with our plans.
+Small bug fixes (few lines of code) are always welcome. Any other kind of unrequested pull request is not.
+Thus, before implementing a feature or modifying the system, please ask whether the change is welcome or not.
+We have issues tagged with ["help wanted"](https://github.com/leanprover/lean4/issues?q=is%3Aissue+is%3Aopen+label%3A%22help+wanted%22), if you want to contribute to the project, please take a look at them.
+If you are interested in one of them, post comments, ask questions, and engage with the core developers there.
+
 ### Should I use Lean?
 
 Lean is under heavy development, and we are constantly trying new
@@ -27,7 +36,7 @@ It is a good place to interact with other Lean users.
 ### Should I use Lean to teach a course?
 
 Lean has been used to teach courses on logic, type theory and programming languages at CMU and the University of Washington.
-The lecture notes for the CMU course [Logic and Proof](https://lean-lang.org/logic_and_proof) are available online,
+The lecture notes for the CMU course [Logic and Proof](https://leanprover.github.io/logic_and_proof) are available online,
 but they are for Lean 3.
 If you decide to teach a course using Lean, we suggest you prepare all material before the beginning of the course, and
 make sure that Lean attends all your needs. You should not expect we will fix bugs and/or add features needed for your course.
@@ -47,7 +56,7 @@ We expect similar independent checkers will be built for Lean 4.
 
 We use [GitHub](https://github.com/leanprover/lean4/issues) to track bugs and new features.
 Bug reports are always welcome, but nitpicking issues are not (e.g., the error message is confusing).
-See also our [contribution guidelines](https://github.com/leanprover/lean4/blob/master/CONTRIBUTING.md).
+See also our [contribution guidelines](../CONTRIBUTING.md).
 
 ### Is it Lean, LEAN, or L∃∀N?
 

doc/flake.lock

@@ -18,15 +18,12 @@
       }
     },
     "flake-utils": {
-      "inputs": {
-        "systems": "systems"
-      },
       "locked": {
-        "lastModified": 1710146030,
-        "narHash": "sha256-SZ5L6eA7HJ/nmkzGG7/ISclqe6oZdOZTNoesiInkXPQ=",
+        "lastModified": 1656928814,
+        "narHash": "sha256-RIFfgBuKz6Hp89yRr7+NR5tzIAbn52h8vT6vXkYjZoM=",
         "owner": "numtide",
         "repo": "flake-utils",
-        "rev": "b1d9ab70662946ef0850d488da1c9019f3a9752a",
+        "rev": "7e2a3b3dfd9af950a856d66b0a7d01e3c18aa249",
         "type": "github"
       },
       "original": {
@@ -38,12 +35,13 @@
     "lean": {
       "inputs": {
         "flake-utils": "flake-utils",
-        "nixpkgs": "nixpkgs",
-        "nixpkgs-old": "nixpkgs-old"
+        "lean4-mode": "lean4-mode",
+        "nix": "nix",
+        "nixpkgs": "nixpkgs_2"
       },
       "locked": {
         "lastModified": 0,
-        "narHash": "sha256-saRAtQ6VautVXKDw1XH35qwP0KEBKTKZbg/TRa4N9Vw=",
+        "narHash": "sha256-YnYbmG0oou1Q/GE4JbMNb8/yqUVXBPIvcdQQJHBqtPk=",
         "path": "../.",
         "type": "path"
       },
@@ -52,20 +50,51 @@
         "type": "path"
       }
     },
-    "leanInk": {
+    "lean4-mode": {
       "flake": false,
       "locked": {
-        "lastModified": 1704976501,
-        "narHash": "sha256-FSBUsbX0HxakSnYRYzRBDN2YKmH9EkA0q9p7TSPEJTI=",
+        "lastModified": 1659020985,
+        "narHash": "sha256-+dRaXB7uvN/weSZiKcfSKWhcdJVNg9Vg8k0pJkDNjpc=",
         "owner": "leanprover",
-        "repo": "LeanInk",
-        "rev": "51821e3c2c032c88e4b2956483899d373ec090c4",
+        "repo": "lean4-mode",
+        "rev": "37d5c99b7b29c80ab78321edd6773200deb0bca6",
         "type": "github"
       },
       "original": {
         "owner": "leanprover",
-        "ref": "refs/pull/57/merge",
+        "repo": "lean4-mode",
+        "type": "github"
+      }
+    },
+    "leanInk": {
+      "flake": false,
+      "locked": {
+        "lastModified": 1666154782,
+        "narHash": "sha256-0ELqEca6jZT4BW/mqkDD+uYuxW5QlZUFlNwZkvugsg8=",
+        "owner": "digama0",
         "repo": "LeanInk",
+        "rev": "12a2aec9b5f4aa84e84fb01a9af1da00d8aaff4e",
+        "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"
       }
     },
@@ -85,13 +114,65 @@
         "type": "github"
       }
     },
+    "nix": {
+      "inputs": {
+        "lowdown-src": "lowdown-src",
+        "nixpkgs": "nixpkgs",
+        "nixpkgs-regression": "nixpkgs-regression"
+      },
+      "locked": {
+        "lastModified": 1657097207,
+        "narHash": "sha256-SmeGmjWM3fEed3kQjqIAO8VpGmkC2sL1aPE7kKpK650=",
+        "owner": "NixOS",
+        "repo": "nix",
+        "rev": "f6316b49a0c37172bca87ede6ea8144d7d89832f",
+        "type": "github"
+      },
+      "original": {
+        "owner": "NixOS",
+        "repo": "nix",
+        "type": "github"
+      }
+    },
     "nixpkgs": {
       "locked": {
-        "lastModified": 1710889954,
-        "narHash": "sha256-Pr6F5Pmd7JnNEMHHmspZ0qVqIBVxyZ13ik1pJtm2QXk=",
+        "lastModified": 1653988320,
+        "narHash": "sha256-ZaqFFsSDipZ6KVqriwM34T739+KLYJvNmCWzErjAg7c=",
         "owner": "NixOS",
         "repo": "nixpkgs",
-        "rev": "7872526e9c5332274ea5932a0c3270d6e4724f3b",
+        "rev": "2fa57ed190fd6c7c746319444f34b5917666e5c1",
+        "type": "github"
+      },
+      "original": {
+        "owner": "NixOS",
+        "ref": "nixos-22.05-small",
+        "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": 1657208011,
+        "narHash": "sha256-BlIFwopAykvdy1DYayEkj6ZZdkn+cVgPNX98QVLc0jM=",
+        "owner": "NixOS",
+        "repo": "nixpkgs",
+        "rev": "2770cc0b1e8faa0e20eb2c6aea64c256a706d4f2",
         "type": "github"
       },
       "original": {
@@ -101,23 +182,6 @@
         "type": "github"
       }
     },
-    "nixpkgs-old": {
-      "flake": false,
-      "locked": {
-        "lastModified": 1581379743,
-        "narHash": "sha256-i1XCn9rKuLjvCdu2UeXKzGLF6IuQePQKFt4hEKRU5oc=",
-        "owner": "NixOS",
-        "repo": "nixpkgs",
-        "rev": "34c7eb7545d155cc5b6f499b23a7cb1c96ab4d59",
-        "type": "github"
-      },
-      "original": {
-        "owner": "NixOS",
-        "ref": "nixos-19.03",
-        "repo": "nixpkgs",
-        "type": "github"
-      }
-    },
     "root": {
       "inputs": {
         "alectryon": "alectryon",
@@ -129,21 +193,6 @@
         "leanInk": "leanInk",
         "mdBook": "mdBook"
       }
-    },
-    "systems": {
-      "locked": {
-        "lastModified": 1681028828,
-        "narHash": "sha256-Vy1rq5AaRuLzOxct8nz4T6wlgyUR7zLU309k9mBC768=",
-        "owner": "nix-systems",
-        "repo": "default",
-        "rev": "da67096a3b9bf56a91d16901293e51ba5b49a27e",
-        "type": "github"
-      },
-      "original": {
-        "owner": "nix-systems",
-        "repo": "default",
-        "type": "github"
-      }
     }
   },
   "root": "root",

doc/flake.nix

@@ -4,20 +4,20 @@
   inputs.lean.url = path:../.;
   inputs.flake-utils.follows = "lean/flake-utils";
   inputs.mdBook = {
-    url = "github:leanprover/mdBook";
+    url = github:leanprover/mdBook;
     flake = false;
   };
   inputs.alectryon = {
-    url = "github:Kha/alectryon/typeid";
+    url = github:Kha/alectryon/typeid;
     flake = false;
   };
   inputs.leanInk = {
-    url = "github:leanprover/LeanInk/refs/pull/57/merge";
+    url = github:leanprover/LeanInk;
     flake = false;
   };
 
   outputs = inputs@{ self, ... }: inputs.flake-utils.lib.eachDefaultSystem (system:
-    with inputs.lean.packages.${system}.deprecated; with nixpkgs;
+    with inputs.lean.packages.${system}; with nixpkgs;
     let
       doc-src = lib.sourceByRegex ../. ["doc.*" "tests(/lean(/beginEndAsMacro.lean)?)?"];
     in {
@@ -27,7 +27,7 @@
         src = inputs.mdBook;
         cargoDeps = drv.cargoDeps.overrideAttrs (_: {
           inherit src;
-          outputHash = "sha256-CO3A9Kpp4sIvkT9X3p+GTidazk7Fn4jf0AP2PINN44A=";
+          outputHash = "sha256-mhTWHs/bsmm3FH59SkUxBTl5lEH2Rlz/aF9CuBTu1TE=";
         });
         doCheck = false;
       });
@@ -44,6 +44,21 @@
           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;
@@ -83,6 +98,7 @@
         src = ./.;
         roots = [
           { mod = "examples"; glob = "submodules"; }
+          { mod = "monads"; glob = "submodules"; }
         ];
       };
       inked = renderPackage literate;

doc/float.md

@@ -0,0 +1 @@
+# Float

doc/fplean.md

@@ -1,7 +1,7 @@
 Functional Programming in Lean
 =======================
 
-The goal of [this book](https://lean-lang.org/functional_programming_in_lean/) is to be an accessible introduction to using Lean 4 as a programming language.
+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

@@ -0,0 +1,153 @@
+# Functions
+
+Functions are the fundamental unit of program execution in any programming language.
+As in other languages, a Lean function has a name, can have parameters and take arguments, and has a body.
+Lean also supports functional programming constructs such as treating functions as values,
+using unnamed functions in expressions, composition of functions to form new functions,
+curried functions, and the implicit definition of functions by way of
+the partial application of function arguments.
+
+You define functions by using the `def` keyword followed by its name, a parameter list, return type and its body.
+The parameter list consists of successive parameters that are separated by spaces.
+You can specify an explicit type for each parameter.
+If you do not specify a specific argument type, the compiler tries to infer the type from the function body.
+An error is returned when it cannot be inferred.
+The expression that makes up the function body is typically a compound expression consisting of a number of expressions
+that culminate in a final expression that is the return value.
+The return type is a colon followed by a type and is optional.
+If you do not specify the type of the return value explicitly,
+the compiler tries to determine the return type from the final expression.
+
+```lean
+def f x := x + 1
+```
+In the previous example, the function name is `f`, the argument is `x`, which has type `Nat`,
+the function body is `x + 1`, and the return value is of type `Nat`.
+The following example defines the factorial recursive function using pattern matching.
+```lean
+def fact x :=
+  match x with
+  | 0   => 1
+  | n+1 => (n+1) * fact n
+
+#eval fact 100
+```
+By default, Lean only accepts total functions. The `partial` keyword should be used when Lean cannot
+establish that a function always terminates.
+```lean
+partial def g (x : Nat) (p : Nat -> Bool) : Nat :=
+  if p x then
+    x
+  else
+    g (x+1) p
+
+#eval g 0 (fun x => x > 10)
+```
+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.
+You define lambda expressions by using the `fun` keyword. A lambda expression resembles a function definition, except that instead of the `:=` token,
+the `=>` token is used to separate the argument list from the function body. As in a regular function definition,
+the argument types can be inferred or specified explicitly, and the return type of the lambda expression is inferred from the type of the
+last expression in the body.
+
+```lean
+def twice (f : Nat -> Nat) (x : Nat) : Nat :=
+  f (f x)
+
+#eval twice (fun x => x + 1) 3
+#eval twice (fun (x : Nat) => x * 2) 3
+
+#eval List.map (fun x => x + 1) [1, 2, 3]
+-- [2, 3, 4]
+
+#eval List.map (fun (x, y) => x + y) [(1, 2), (3, 4)]
+-- [3, 7]
+```
+
+# Syntax sugar for simple lambda expressions
+
+Simple functions can be defined using parentheses and `·` as a placeholder.
+```lean
+#check (· + 1)
+-- fun a => a + 1
+#check (2 - ·)
+-- fun a => 2 - a
+#eval [1, 2, 3, 4, 5].foldl (· * ·) 1
+-- 120
+
+def h (x y z : Nat) :=
+  x + y + z
+
+#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`.
+
+# Pipelining
+
+Pipelining enables function calls to be chained together as successive operations. Pipelining works as follows:
+
+```lean
+def add1 x := x + 1
+def times2 x := x * 2
+
+#eval times2 (add1 100)
+#eval 100 |> add1 |> times2
+#eval times2 <| add1 <| 100
+```
+The result of the previous `#eval` commands is 202.
+The forward pipeline `|>` operator takes a function and an argument and return a value.
+In contrast, the backward pipeline `<|` operator takes an argument and a function and returns a value.
+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))
+
+#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)
+
+#eval add1Times3FilterEven' [1, 2, 3, 4]
+-- [6, 12]
+```
+Lean also supports the operator `|>.` which combines forward pipeline `|>` operator with the `.` field notation.
+```lean
+-- Define the same function using pipes
+def add1Times3FilterEven'' (xs : List Nat) :=
+  xs.map (· + 1) |>.map (· * 3) |>.filter (· % 2 == 0)
+
+#eval add1Times3FilterEven'' [1, 2, 3, 4]
+-- [6, 12]
+```
+
+For users familiar with the Haskell programming language,
+Lean also supports the notation `f $ a` for the backward pipeline `f <| a`.

doc/implicit.md

@@ -0,0 +1,142 @@
+## Implicit Arguments
+
+Suppose we define the `compose` function as.
+
+```lean
+def compose (α β γ : Type) (g : β → γ) (f : α → β) (x : α) : γ :=
+  g (f x)
+```
+
+The function `compose` takes three types, ``α``, ``β``, and ``γ``, and two functions, ``g : β → γ`` and ``f : α → β``, a value `x : α`, and
+returns ``g (f x)``, the composition of ``g`` and ``f``.
+We say `compose` is polymorphic over types ``α``, ``β``, and ``γ``. Now, let's use `compose`:
+
+```lean
+# def compose (α β γ : Type) (g : β → γ) (f : α → β) (x : α) : γ :=
+#   g (f x)
+def double (x : Nat) := 2*x
+def triple (x : Nat) := 3*x
+
+#check compose Nat Nat Nat double triple 10 -- Nat
+#eval  compose Nat Nat Nat double triple 10 -- 60
+
+def appendWorld (s : String) := s ++ "world"
+#check String.length -- String → Nat
+
+#check compose String String Nat String.length appendWorld "hello" -- Nat
+#eval  compose String String Nat String.length appendWorld "hello" -- 10
+```
+
+Because `compose` is polymorphic over types ``α``, ``β``, and ``γ``, we have to provide them in the examples above.
+But this information is redundant: one can infer the types from the arguments ``g`` and ``f``.
+This is a central feature of dependent type theory: terms carry a lot of information, and often some of that information can be inferred from the context.
+In Lean, one uses an underscore, ``_``, to specify that the system should fill in the information automatically.
+
+```lean
+# def compose (α β γ : Type) (g : β → γ) (f : α → β) (x : α) : γ :=
+#  g (f x)
+# def double (x : Nat) := 2*x
+# def triple (x : Nat) := 3*x
+#check compose _ _ _ double triple 10 -- Nat
+#eval  compose Nat Nat Nat double triple 10 -- 60
+# def appendWorld (s : String) := s ++ "world"
+# #check String.length -- String → Nat
+#check compose _ _ _ String.length appendWorld "hello" -- Nat
+#eval  compose _ _ _ String.length appendWorld "hello" -- 10
+```
+It is still tedious, however, to type all these underscores. When a function takes an argument that can generally be inferred from context,
+Lean allows us to specify that this argument should, by default, be left implicit. This is done by putting the arguments in curly braces, as follows:
+
+```lean
+def compose {α β γ : Type} (g : β → γ) (f : α → β) (x : α) : γ :=
+  g (f x)
+# def double (x : Nat) := 2*x
+# def triple (x : Nat) := 3*x
+#check compose double triple 10 -- Nat
+#eval  compose double triple 10 -- 60
+# def appendWorld (s : String) := s ++ "world"
+# #check String.length -- String → Nat
+#check compose String.length appendWorld "hello" -- Nat
+#eval  compose String.length appendWorld "hello" -- 10
+```
+All that has changed are the braces around ``α β γ: Type``.
+It makes these three arguments implicit. Notationally, this hides the specification of the type,
+making it look as though ``compose`` simply takes 3 arguments.
+
+Variables can also be specified as implicit when they are declared with
+the ``variable`` command:
+
+```lean
+universe u
+
+section
+  variable {α : Type u}
+  variable (x : α)
+  def ident := x
+end
+
+variable (α β : Type u)
+variable (a : α) (b : β)
+
+#check ident
+#check ident a
+#check ident b
+```
+
+This definition of ``ident`` here has the same effect as the one above.
+
+Lean has very complex mechanisms for instantiating implicit arguments, and we will see that they can be used to infer function types, predicates, and even proofs.
+The process of instantiating these "holes," or "placeholders," in a term is part of a bigger process called *elaboration*.
+The presence of implicit arguments means that at times there may be insufficient information to fix the meaning of an expression precisely.
+An expression like ``ident`` is said to be *polymorphic*, because it can take on different meanings in different contexts.
+
+One can always specify the type ``T`` of an expression ``e`` by writing ``(e : T)``.
+This instructs Lean's elaborator to use the value ``T`` as the type of ``e`` when trying to elaborate it.
+In the following example, this mechanism is used to specify the desired types of the expressions ``ident``.
+
+```lean
+def ident {α : Type u} (a : α) : α := a
+
+#check (ident : Nat → Nat) -- Nat → Nat
+```
+
+Numerals are overloaded in Lean, but when the type of a numeral cannot be inferred, Lean assumes, by default, that it is a natural number.
+So the expressions in the first two ``#check`` commands below are elaborated in the same way, whereas the third ``#check`` command interprets ``2`` as an integer.
+
+```lean
+#check 2         -- Nat
+#check (2 : Nat) -- Nat
+#check (2 : Int) -- Int
+```
+
+Sometimes, however, we may find ourselves in a situation where we have declared an argument to a function to be implicit,
+but now want to provide the argument explicitly. If ``foo`` is such a function, the notation ``@foo`` denotes the same function with all
+the arguments made explicit.
+
+```lean
+# def ident {α : Type u} (a : α) : α := a
+variable (α β : Type)
+
+#check @ident           -- {α : Type u} → α → α
+#check @ident α         -- α → α
+#check @ident β         -- β → β
+#check @ident Nat       -- Nat → Nat
+#check @ident Bool true -- Bool
+```
+
+Notice that now the first ``#check`` command gives the type of the identifier, ``ident``, without inserting any placeholders.
+Moreover, the output indicates that the first argument is implicit.
+
+Named arguments enable you to specify an argument for a parameter by matching the argument with
+its name rather than with its position in the parameter list. You can use them to specify explicit *and* implicit arguments.
+If you don't remember the order of the parameters but know their names, you can send the arguments in any order.
+You may also provide the value for an implicit parameter when
+Lean failed to infer it. Named arguments also improve the readability of your code by identifying what
+each argument represents.
+
+```lean
+# def ident {α : Type u} (a : α) : α := a
+
+#check ident (α := Nat)  -- Nat → Nat
+#check ident (α := Bool) -- Bool → Bool
+```

doc/inductive.md

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

doc/int.md

@@ -0,0 +1,37 @@
+# Integers
+
+The `Int` type represents the arbitrary-precision integers. There are no overflows.
+```lean
+#eval (100000000000000000 : Int) * 200000000000000000000 * 1000000000000000000000
+```
+Recall that nonnegative numerals are considered to be a `Nat` if there are no typing constraints.
+```lean
+#check 1 -- Nat
+#check -1 -- Int
+#check (1:Int) -- Int
+```
+
+The operator `/` for `Int` implements integer division.
+```lean
+#eval -10 / 4 -- -2
+```
+
+Similar to `Nat`, the internal representation of `Int` is optimized. Small integers are
+represented by a single machine word. Big integers are implemented using [GMP](https://gmplib.org/manual/) numbers.
+We recommend you use fixed precision numeric types only in performance critical code.
+
+The Lean kernel does not have special support for reducing `Int` during type checking.
+However, since `Int` is defined as
+```lean
+# namespace hidden
+inductive Int : Type where
+  | ofNat   : Nat → Int
+  | negSucc : Nat → Int
+# end hidden
+```
+the type checker will be able reduce `Int` expressions efficiently by relying on the special support for `Nat`.
+
+```lean
+theorem ex : -2000000000 * 1000000000 = -2000000000000000000 :=
+ rfl
+```

doc/latex/lean4.py

@@ -0,0 +1,100 @@
+# -*- coding: utf-8 -*-
+"""
+    pygments.lexers.theorem
+    ~~~~~~~~~~~~~~~~~~~~~~~
+
+    Lexers for theorem-proving languages.
+
+    :copyright: Copyright 2006-2017 by the Pygments team, see AUTHORS.
+    :license: BSD, see LICENSE for details.
+"""
+
+import re
+
+from pygments.lexer import RegexLexer, default, words
+from pygments.token import Text, Comment, Operator, Keyword, Name, String, \
+    Number, Punctuation, Generic
+
+__all__ = ['Lean4Lexer']
+
+class Lean4Lexer(RegexLexer):
+    """
+    For the `Lean 4 <https://github.com/leanprover/lean4>`_
+    theorem prover.
+
+    .. versionadded:: 2.0
+    """
+    name = 'Lean4'
+    aliases = ['lean4']
+    filenames = ['*.lean']
+    mimetypes = ['text/x-lean']
+
+    flags = re.MULTILINE | re.UNICODE
+
+    keywords1 = (
+        'import', 'abbreviation', 'opaque_hint', 'tactic_hint', 'definition',
+        'renaming', 'inline', 'hiding', 'parameter', 'lemma', 'variable',
+        'theorem', 'axiom', 'inductive', 'structure', 'universe', 'alias',
+        'help', 'options', 'precedence', 'postfix', 'prefix',
+        'infix', 'infixl', 'infixr', 'notation', '#eval',
+        '#check', '#reduce', '#exit', 'coercion', 'end', 'private', 'using', 'namespace',
+        'including', 'instance', 'section', 'context', 'protected', 'expose',
+        'export', 'set_option', 'extends', 'open', 'example',
+        'constant', 'constants', 'print', 'opaque', 'reducible', 'irreducible',
+        'def', 'macro', 'elab', 'syntax', 'macro_rules', 'reduce', 'where',
+        'abbrev', 'noncomputable', 'class', 'attribute', 'synth', 'mutual',
+    )
+
+    keywords2 = (
+        'forall', 'fun', 'Pi', 'obtain', 'from', 'have', 'show', 'assume',
+        'take', 'let', 'if', 'else', 'then', 'by', 'in', 'with', 'begin',
+        'proof', 'qed', 'calc', 'match', 'nomatch', 'do', 'at',
+    )
+
+    keywords3 = (
+        # Sorts
+        'Type', 'Prop', 'Sort',
+    )
+
+    operators = (
+        u'!=', u'#', u'&', u'&&', u'*', u'+', u'-', u'/', u'@', u'!', u'`',
+        u'-.', u'->', u'.', u'..', u'...', u'::', u':>', u';', u';;', u'<',
+        u'<-', u'=', u'==', u'>', u'_', u'|', u'||', u'~', u'=>', u'<=', u'>=',
+        u'/\\', u'\\/', u'∀', u'Π', u'λ', u'↔', u'∧', u'∨', u'≠', u'≤', u'≥',
+        u'¬', u'⁻¹', u'⬝', u'▸', u'→', u'∃', u'ℕ', u'ℤ', u'≈', u'×', u'⌞',
+        u'⌟', u'≡', u'⟨', u'⟩',
+    )
+
+    punctuation = (u'(', u')', u':', u'{', u'}', u'[', u']', u'⦃', u'⦄',
+                   u':=', u',')
+
+    tokens = {
+        'root': [
+            (r'\s+', Text),
+            (r'/-', Comment, 'comment'),
+            (r'--.*?$', Comment.Single),
+            (words(keywords1, prefix=r'\b', suffix=r'\b'), Keyword.Namespace),
+            (words(keywords2, prefix=r'\b', suffix=r'\b'), Keyword),
+            (words(keywords3, prefix=r'\b', suffix=r'\b'), Keyword.Type),
+            (words(operators), Name.Builtin.Pseudo),
+            (words(punctuation), Operator),
+            (u"[A-Za-z_\u03b1-\u03ba\u03bc-\u03fb\u1f00-\u1ffe\u2100-\u214f]"
+             u"[A-Za-z_'\u03b1-\u03ba\u03bc-\u03fb\u1f00-\u1ffe\u2070-\u2079"
+             u"\u207f-\u2089\u2090-\u209c\u2100-\u214f0-9]*", Name),
+            (r'\d+', Number.Integer),
+            (r'"', String.Double, 'string'),
+            (r'[~?][a-z][\w\']*:', Name.Variable)
+        ],
+        'comment': [
+            # Multiline Comments
+            (r'[^/-]', Comment.Multiline),
+            (r'/-', Comment.Multiline, '#push'),
+            (r'-/', Comment.Multiline, '#pop'),
+            (r'[/-]', Comment.Multiline)
+        ],
+        'string': [
+            (r'[^\\"]+', String.Double),
+            (r'\\[n"\\]', String.Escape),
+            ('"', String.Double, '#pop'),
+        ],
+    }

doc/latex/lstlean.tex

@@ -4,7 +4,7 @@
 
 \lstdefinelanguage{lean} {
 
-% Anything between $ becomes LaTeX math mode
+% Anything betweeen $ becomes LaTeX math mode
 mathescape=false,
 % Comments may or not include Latex commands
 texcl=false,
@@ -201,7 +201,6 @@ literate=
 
 {ₙ}{{\ensuremath{_n}}}1
 {ₘ}{{\ensuremath{_m}}}1
-{ₚ}{{\ensuremath{_p}}}1
 {↑}{{\ensuremath{\uparrow}}}1
 {↓}{{\ensuremath{\downarrow}}}1
 
@@ -265,7 +264,7 @@ columns=[l]fullflexible,
 % Style for (listings') identifiers
 identifierstyle={\ttfamily\color{black}},
 % Note : highlighting of Coq identifiers is done through a new
-% delimiter definition through an lstset at the beginning of the
+% delimiter definition through an lstset at the begining of the
 % document. Don't know how to do better.
 
 % Style for declaration keywords

doc/lean3changes.md

@@ -85,7 +85,7 @@ def id5 : {α : Type} → α → α :=
 
 ## 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:
+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:
 
 ```lean
 # namespace ex3
@@ -196,8 +196,6 @@ example (f : Nat → Nat) (a b c : Nat) : f (a + b + c) = f (a + (b + c)) :=
   congrArg f (Nat.add_assoc ..)
 ```
 
-In Lean 4, writing `f(x)` in place of `f x` is no longer allowed, you must use whitespace between the function and its arguments (e.g., `f (x)`).
-
 ## Dependent function types
 
 Given `α : Type` and `β : α → Type`, `(x : α) → β x` denotes the type of functions `f` with the property that,

doc/lexical_structure.md

@@ -8,7 +8,7 @@ A Lean program consists of a stream of UTF-8 tokens where each token
 is one of the following:
 
 ```
-   token: symbol | command | ident | string | raw_string | char | numeral |
+   token: symbol | command | ident | string | char | numeral |
         : decimal | doc_comment | mod_doc_comment | field_notation
 ```
 
@@ -79,35 +79,15 @@ special characters:
 [Unicode table](https://unicode-table.com/en/) so "\xA9 Copyright 2021" is "© Copyright 2021".
 - `\uHHHH` puts the character represented by the 4 digit hexadecimal into the string, so the following
 string "\u65e5\u672c" will become "日本" which means "Japan".
-- `\` followed by a newline and then any amount of whitespace is a "gap" that is equivalent to the empty string,
-useful for letting a string literal span across multiple lines. Gaps spanning multiple lines can be confusing,
-so the parser raises an error if the trailing whitespace contains any newlines.
 
 So the complete syntax is:
 
 ```
    string       : '"' string_item '"'
-   string_item  : string_char | char_escape | string_gap
-   string_char  : [^"\\]
-   char_escape  : "\" ("\" | '"' | "'" | "n" | "t" | "x" hex_char{2} | "u" hex_char{4})
+   string_item  : string_char | string_escape
+   string_char  : [^\\]
+   string_escape: "\" ("\" | '"' | "'" | "n" | "t" | "x" hex_char{2} | "u" hex_char{4} )
    hex_char     : [0-9a-fA-F]
-   string_gap   : "\" newline whitespace*
-```
-
-Raw String Literals
-===================
-
-Raw string literals are string literals without any escape character processing.
-They begin with `r##...#"` (with zero or more `#` characters) and end with `"#...##` (with the same number of `#` characters).
-The contents of a raw string literal may contain `"##..#` so long as the number of `#` characters
-is less than the number of `#` characters used to begin the raw string literal.
-
-```
-   raw_string          : raw_string_aux(0) | raw_string_aux(1) | raw_string_aux(2) | ...
-   raw_string_aux(n)   : 'r' '#'{n} '"' raw_string_item '"' '#'{n}
-   raw_string_item(n)  : raw_string_char | raw_string_quote(n)
-   raw_string_char     : [^"]
-   raw_string_quote(n) : '"' '#'{0..n-1}
 ```
 
 Char Literals
@@ -116,9 +96,7 @@ Char Literals
 Char literals are enclosed by single quotes (``'``).
 
 ```
-   char      : "'" char_item "'"
-   char_item : char_char | char_escape
-   char_char : [^'\\]
+   char: "'" string_item "'"
 ```
 
 Numeric Literals
@@ -128,16 +106,16 @@ Numeric literals can be specified in various bases.
 
 ```
    numeral    : numeral10 | numeral2 | numeral8 | numeral16
-   numeral10  : [0-9]+ ("_"+ [0-9]+)*
-   numeral2   : "0" [bB] ("_"* [0-1]+)+
-   numeral8   : "0" [oO] ("_"* [0-7]+)+
-   numeral16  : "0" [xX] ("_"* hex_char+)+
+   numeral10  : [0-9]+
+   numeral2   : "0" [bB] [0-1]+
+   numeral8   : "0" [oO] [0-7]+
+   numeral16  : "0" [xX] hex_char+
 ```
 
 Floating point literals are also possible with optional exponent:
 
 ```
-   float    : numeral10 "." numeral10? [eE[+-]numeral10]
+   float    : [0-9]+ "." [0-9]+ [[eE[+-][0-9]+]
 ```
 
 For example:
@@ -147,7 +125,6 @@ constant w : Int := 55
 constant x : Nat := 26085
 constant y : Nat := 0x65E5
 constant z : Float := 2.548123e-05
-constant b : Bool := 0b_11_01_10_00
 ```
 
 Note: that negative numbers are created by applying the "-" negation prefix operator to the number, for example:

doc/list.md

@@ -0,0 +1 @@
+# List

doc/macro_overview.md

@@ -0,0 +1,393 @@
+
+# Macro Overview
+
+The offical paper describing the mechanics behind Lean 4's macro system can be
+found in [Beyond Notations: Hygienic Macro Expansion for Theorem Proving
+Languages](https://arxiv.org/abs/2001.10490) by Sebastian Ullrich and Leonardo
+de Moura, and the accompanying repo with example code can be found in the
+paper's code [supplement](https://github.com/Kha/macro-supplement). The
+supplement also includes a working implementation of the macro expander, so it's
+a good case study for people interested in the details.
+
+## What is a macro in Lean?
+
+A macro is a function that takes in a syntax tree and produces a new syntax
+tree. Macros are useful for many reasons, but two of the big ones are a)
+allowing users to extend the language with new syntactic constructs without
+having to actually expand the core language, and b) allowing users to automate
+tasks that would otherwise be extremely repetitive, time-consuming, and/or
+error-prone.
+
+A motivating example is set builder notation. We would like to be able to write
+the set of natural numbers 0, 1, and 2 as just `{0, 1, 2}`. However, Lean does
+not natively support this syntax, and the actual definition of a set in Mathlib
+does not let us just declare sets in this manner; naively using the set API
+would force us to write `Set.insert 1 (Set.insert 2 (Set.singleton 3))`.
+Instead, we can teach Lean's macro system to recognize `{0, 1, 2}` as a
+shorthand for a composition of existing methods and let it do the repetitive
+work of creating the `Set.insert...` invocation for us. In this way, we can have
+our more readable and more convenient syntax without having to extend Lean
+itself, and while retaining the simple insert/singleton API.
+
+## How macros are handled
+
+The general procedure is as follows:
+
+1. Lean parses a command, creating a Lean syntax tree which contains any
+   unexpanded macros.
+
+2. Lean repeats the cycle (elaboration ~> (macro hygiene and expansion) ~>
+   elaboration...)
+
+The cycle in step 2 repeats until there are no more macros which need to be
+expanded, and elaboration can finish normally. This repetition is required since
+macros can expand to other macros, and may expand to code that needs information
+from the elaborator. As you can see, the process of macro parsing and expansion
+is interleaved with the parsing and elaboration of non-macro code.
+
+By default, macros in Lean are hygienic, which means the system avoids
+accidental name capture when reusing the same name inside and outside the macro.
+Users may occasionally want to disable hygiene, which can be accomplished with
+the command `set_option hygiene false`. More in-depth information about hygiene
+and how it's implemented in the official paper and supplement linked at the top
+of this guide.
+
+## Elements of "a" macro (important types)
+
+
+In the big picture, a macro has two components that must be implemented by the
+user, parsers and syntax transformers, where the latter is a function that says
+what the input syntax should expand to. There is a third component, syntax
+categories, such as `term`, `tactic`, and `command`, but declaring a new syntax
+category is not always necessary. When we say "parser" in the context of a
+macro, we refer to the core type `Lean.ParserDescr`, which parses elements of
+type `Lean.Syntax`, where `Lean.Syntax` represents elements of a Lean syntax
+tree. Syntax transformers are functions of type `Syntax -> MacroM Syntax`. Lean
+has a synonym for this type, which is simply `Macro`. `MacroM` is a monad that
+carries state needed for macro expansion to work nicely, including the info
+needed to implement hygiene.
+
+As an example, we again refer to Mathlib's set builder notation:
+```lean
+/- Declares a parser -/
+syntax (priority := high) "{" term,+ "}" : term
+
+/- Declares two expansions/syntax transformers -/
+macro_rules
+  | `({$x}) => `(Set.singleton $x)
+  | `({$x, $xs:term,*}) => `(Set.insert $x {$xs,*})
+
+/- Provided `Set` has been imported (from Mathlib4), these are all we need for `{1, 2, 3}` to be valid notation to create a literal set -/
+
+```
+
+This example should also make clear the reason why macros (and pretty much all
+of Lean 4's metaprogramming facilities) are functions that take an argument of
+type `Syntax` e.g. `Syntax -> MacroM Syntax`; the leading syntax element is the
+thing that actually triggers the macro expansion by matching with the declared
+parser, and as a user, you will almost always be interested in inspecting and
+transforming that initial syntax element (though there are cases in which it can
+just be ignored, as in the parameter-less exfalso tactic).
+
+Returning briefly to the API provided by Lean, `Lean.Syntax`, is pretty much
+what you would expect a basic syntax tree type to look like. Below is a slightly
+simplified representation which omits details in the `atom` and `ident`
+constructors; users can create atoms and idents which comport with this
+simplified representation using the `mkAtom` and `mkIdent` methods provided in
+the `Lean` namespace.
+```lean
+# open Lean
+inductive Syntax where
+  | missing : Syntax
+  | node (kind : SyntaxNodeKind) (args : Array Syntax) : Syntax
+  | atom : String -> Syntax
+  | ident : Name -> Syntax
+```
+
+
+
+For those interested, `MacroM` is a `ReaderT`:
+```lean
+# open Lean
+abbrev MacroM := ReaderT Macro.Context (EStateM Macro.Exception Macro.State)
+```
+
+The other relevant components are defined as follows:
+```lean
+# open Lean
+structure Context where
+  methods        : MethodsRef
+  mainModule     : Name
+  currMacroScope : MacroScope
+  currRecDepth   : Nat := 0
+  maxRecDepth    : Nat := defaultMaxRecDepth
+  ref            : Syntax
+
+inductive Exception where
+  | error             : Syntax → String → Exception
+  | unsupportedSyntax : Exception
+
+structure State where
+  macroScope : MacroScope
+  traceMsgs  : List (Prod Name String) := List.nil
+  deriving Inhabited
+```
+
+As a review/checklist, the three (sometimes only two depending on whether you
+need a new syntax category) components users need to be concerned with are:
+
+0. You may or may not need to declare a new syntax category using
+   `declare_syntax_cat`
+1. Declare a parser with either `syntax` or `macro`
+2. Declare an expansion/syntax transformer with either `macro_rules` or `macro`
+
+Parsers and syntax transformers can be declared manually, but use of the pattern
+language and `syntax`, `macro_rules`, and `macro` is recommended.
+
+## syntax categories with declare_syntax_cat
+
+`declare_syntax_cat` declares a new syntax category, like `command`, `tactic`,
+or mathlib4's `binderterm`. These are the different categories of things that
+can be referred to in a quote/antiquote. `declare_syntax_cat` results in a call
+to `registerParserCategory` and produces a new parser descriptor:
+
+```lean
+set_option trace.Elab.definition true in
+declare_syntax_cat binderterm
+
+/-
+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.cat `binderterm 0)
+      (Lean.ParserDescr.symbol ")")))
+-/
+```
+
+Declaring a new syntax category like this one automatically declares a quotation
+operator `` `(binderterm| ...)``. These pipe prefixes `<thing>|` are used in
+syntax quotations to say what category a given quotation is expected to be an
+element of. The pipe prefixes are *not* used for elements in the `term` and
+`command` categories (since they're considered the default), but need to be used
+for everything else.
+
+## Parsers and the `syntax` keyword
+
+Internally, elements of type `Lean.ParserDescr` are implemented as parser
+combinators. However, Lean offers the ability to write parsers using the
+macro/pattern language by way of the `syntax` keyword. This is the recommended
+means of writing parsers. As an example, the parser for the `rwa` (rewrite, then
+use assumption) tactic is:
+
+```lean
+# open Lean.Parser.Tactic
+set_option trace.Elab.definition true in
+syntax "rwa " rwRuleSeq (location)? : tactic
+
+/-
+which expands to:
+[Elab.definition.body] tacticRwa__ : Lean.ParserDescr :=
+Lean.ParserDescr.node `tacticRwa__ 1022
+  (Lean.ParserDescr.binary `andthen
+    (Lean.ParserDescr.binary `andthen (Lean.ParserDescr.nonReservedSymbol "rwa " false) Lean.Parser.Tactic.rwRuleSeq)
+    (Lean.ParserDescr.unary `optional Lean.Parser.Tactic.location))
+
+-/
+
+```
+
+Literals are written as double-quoted strings (`"rwa "` expects the literal
+sequence of characters `rwa`, while the trailing space provides a hint to the
+formatter that it should add a space after `rwa` when pretty printing this
+syntax); `rwRuleSeq` and `location` are themselves `ParserDescr`s, and we finish
+with `: tactic` specifying that the preceding parser is for an element in the
+`tactic` syntax category. The parentheses around `(location)?` are necessary
+(rather than `location?`) because Lean 4 allows question marks to be used in
+identifiers, so `location?` is one single identifier that ends with a question
+mark, which is not what we want.
+
+The name `tacticRwa__` is automatically generated. You can name parser
+descriptors declared with the `syntax` keyword like so:
+
+```lean
+set_option trace.Elab.definition true in
+syntax (name := introv) "introv " (colGt ident)* : tactic
+
+/-
+[Elab.definition.body] introv : Lean.ParserDescr :=
+Lean.ParserDescr.node `introv 1022
+  (Lean.ParserDescr.binary `andthen (Lean.ParserDescr.nonReservedSymbol "introv " false)
+    (Lean.ParserDescr.unary `many
+      (Lean.ParserDescr.binary `andthen (Lean.ParserDescr.const `colGt) (Lean.ParserDescr.const `ident))))
+-/
+```
+
+## The pattern language
+
+Available quantifiers are `?` (one or zero occurrences, see note below), `*`
+(zero or more occurrences), and `+` (one or more occurrences).
+
+Keep in mind that Lean makes `?` available for use in identifiers, so if we want
+a parser to look for an optional `location`, we would need to write
+`(location)?` with parenthesis acting as a separator, since `location?` would
+look for something under the identifier `location?` (where the `?` is part of
+the identifier).
+
+Parentheses can be used as delimiters.
+
+Separated lists can be constructed like so: `$ts,*` for a comma separated list.
+
+"extended splices" can be constructed as `$[..]`. See the official paper (p. 12)
+for more details.
+
+Literals are written as double-quoted strings. A literal may use trailing
+whitespace (see e.g. the `rwa` or `introv` tactics) to tell the pretty-printer
+how it should be displayed, but such whitespace will not prevent a literal with
+no trailing whitespace from matching. The spaces are relevant, but not
+interpreted literally. When the ParserDescr is turned into a Parser, the actual
+token matcher [uses the .trim of the provided
+string](https://github.com/leanprover/lean4/blob/53ec43ff9b8f55989b12c271e368287b7b997b54/src/Lean/Parser/Basic.lean#L1193),
+but the generated formatter [uses the spaces as
+specified](https://github.com/leanprover/lean4/blob/8d370f151f7c88a687152a5b161dcb484c446ce2/src/Lean/PrettyPrinter/Formatter.lean#L328),
+that is, turning the atom "rwa" in the syntax into the string rwa as part of the
+pretty printed output.
+
+## Syntax expansions with `macro_rules`, and how it desugars.
+
+`macro_rules` lets you declare expansions for a given `Syntax` element using a
+syntax simlar to a `match` statement. The left-hand side of a match arm is a
+quotation (with a leading `<cat>|` for categories other than `term` and
+`command`) in which users can specify the pattern they'd like to write an
+expansion for. The right-hand side returns a syntax quotation which is the
+output the user wants to expand to.
+
+A feature of Lean's macro system is that if there are multiple expansions for a
+particular match, Lean will try the most recently declared expansion first, and
+will retry with other matching expansions if the previous attempt failed. This
+is particularly useful for extending existing tactics.
+
+The following example shows both the retry behavior, and the fact that macros
+declared using the shorthand `macro` syntax can still have additional expansions
+declared with `macro_rules`. This `transitivity` tactic is implemented such that
+it will work for either Nat.le or Nat.lt. The Nat.lt version was declared "most
+recently", so it will be tried first, but if it fails (for example, if the
+actual term in question is Nat.le) the next potential expansion will be tried:
+```lean
+macro "transitivity" e:(colGt term) : tactic => `(tactic| apply Nat.le_trans (m := $e))
+macro_rules
+  | `(tactic| transitivity $e) => `(tactic| apply Nat.lt_trans (m := $e))
+
+example (a b c : Nat) (h0 : a < b) (h1 : b < c) : a < c := by
+  transitivity b <;>
+  assumption
+
+example (a b c : Nat) (h0 : a <= b) (h1 : b <= c) : a <= c := by
+  transitivity b <;>
+  assumption
+
+/- This will fail, but is interesting in that it exposes the "most-recent first" behavior, since the
+  error message complains about being unable to unify mvar1 <= mvar2, rather than mvar1 < mvar2. -/
+/-
+example (a b c : Nat) (h0 : a <= b) (h1 : b <= c) : False := by
+  transitivity b <;>
+  assumption
+-/
+```
+
+To see the desugared definition of the actual expansion, we can again use
+`set_option trace.Elab.definition true in` and observe the output of the humble
+`exfalso` tactic defined in Mathlib4:
+```lean
+
+set_option trace.Elab.definition true in
+macro "exfalso" : tactic => `(tactic| apply False.elim)
+
+/-
+Results in the expansion:
+
+[Elab.definition.body] _aux___macroRules_tacticExfalso_1 : Lean.Macro :=
+fun x =>
+  let discr := x;
+  /- This is where Lean tries to actually identify that it's an invocation of the exfalso tactic -/
+  if Lean.Syntax.isOfKind discr `tacticExfalso = true then
+    let discr := Lean.Syntax.getArg discr 0;
+    let x := discr;
+    do
+      /- Lean getting scope/meta info from the macro monad -/
+      let info ← Lean.MonadRef.mkInfoFromRefPos
+      let scp ← Lean.getCurrMacroScope
+      let mainModule ← Lean.getMainModule
+      pure
+          (Lean.Syntax.node Lean.SourceInfo.none `Lean.Parser.Tactic.seq1
+            #[Lean.Syntax.node Lean.SourceInfo.none `null
+                #[Lean.Syntax.node Lean.SourceInfo.none `Lean.Parser.Tactic.apply
+                    #[Lean.Syntax.atom info "apply",
+                      Lean.Syntax.ident info (String.toSubstring "False.elim")
+                        (Lean.addMacroScope mainModule `False.elim scp) [(`False.elim, [])]]]])
+  else
+    /- If this wasn't actually an invocation of the exfalso tactic, throw the "unsupportedSyntax" error -/
+    let discr := x;
+    throw Lean.Macro.Exception.unsupportedSyntax
+-/
+```
+
+We can also create the syntax transformer declaration ourselves instead of using
+`macro_rules`. We'll need to name our parser and use the attribute `@[macro
+myExFalsoParser]` to associate our declaration with the parser:
+```lean
+# open Lean
+syntax (name := myExfalsoParser) "myExfalso" : tactic
+
+-- remember that `Macro` is a synonym for `Syntax -> TacticM Unit`
+@[macro myExfalsoParser] def implMyExfalso : Macro :=
+fun stx => `(tactic| apply False.elim)
+
+example (p : Prop) (h : p) (f : p -> False) : 3 = 2 := by
+  myExfalso
+  exact f h
+```
+
+In the above example, we're still using the sugar Lean provides for creating
+quotations, as it feels more intuitive and saves us some work. It is possible to
+forego the sugar altogether:
+```lean
+syntax (name := myExfalsoParser) "myExfalso" : tactic
+
+@[macro myExfalsoParser] def implMyExfalso : Lean.Macro :=
+  fun stx => pure (Lean.mkNode `Lean.Parser.Tactic.apply
+    #[Lean.mkAtomFrom stx "apply", Lean.mkCIdentFrom stx ``False.elim])
+
+example (p : Prop) (h : p) (f : p -> False) : 3 = 2 := by
+  myExfalso
+  exact f h
+```
+
+## The `macro` keyword
+
+`macro` is a shortcut which allows users to declare both a parser and an
+expansion at the same time as a matter of convenience. Additional expansions for
+the parser generated by the `macro` invocation can be added with a separate
+`macro_rules` block (see the example in the `macro_rules` section).
+
+## Unexpanders
+
+TODO; for now, see the unexpander in Mathlib.Set for an example.
+
+## More illustrative examples:
+
+The
+[Tactic.Basic](https://github.com/leanprover-community/mathlib4/blob/master/Mathlib/Tactic/Basic.lean)
+file in Mathlib4 contains many good examples to learn from.
+
+## Practical tips:
+
+You can observe the output of commands and functions that in some way use the
+macro system by setting this option to true : `set_option trace.Elab.definition
+true`
+
+Lean also offers the option of limiting the region in which option is set with
+the syntax `set_option ... in`):
+
+Hygiene can be disabled with the command option `set_option hygiene false`

doc/make/index.md

@@ -1,48 +1,58 @@
-These are instructions to set up a working development environment for those who wish to make changes to Lean itself. It is part of the [Development Guide](../dev/index.md).
-
-We strongly suggest that new users instead follow the [Quickstart](../quickstart.md) to get started using Lean, since this sets up an environment that can automatically manage multiple Lean toolchain versions, which is necessary when working within the Lean ecosystem.
-
 Requirements
 ------------
 
 - C++14 compatible compiler
 - [CMake](http://www.cmake.org)
 - [GMP (GNU multiprecision library)](http://gmplib.org/)
-- [LibUV](https://libuv.org/)
 
 Platform-Specific Setup
 -----------------------
 
 - [Linux (Ubuntu)](ubuntu.md)
 - [Windows (msys2)](msys2.md)
+- [Windows (Visual Studio)](msvc.md)
 - [Windows (WSL)](wsl.md)
 - [macOS (homebrew)](osx-10.9.md)
-- Linux/macOS/WSL via [Nix](https://nixos.org/nix/): Call `nix develop` in the project root. That's it.
+- Linux/macOS/WSL via [Nix](https://nixos.org/nix/): Call `nix-shell` in the project root. That's it.
+- There is also an [**experimental** setup based purely on Nix](nix.md) that works fundamentally differently from the
+  make/CMake setup described on this page.
 
 Generic Build Instructions
 --------------------------
 
-Setting up a basic parallelized release build:
+Setting up a basic release build:
 
 ```bash
-git clone https://github.com/leanprover/lean4
+git clone https://github.com/leanprover/lean4 --recurse-submodules
 cd lean4
-cmake --preset release
-make -C build/release -j$(nproc || sysctl -n hw.logicalcpu)
+mkdir -p build/release
+cd build/release
+cmake ../..
+make
 ```
-You can replace `$(nproc || sysctl -n hw.logicalcpu)` with the desired parallelism amount.
+
+For regular development, we recommend running
+```bash
+git config submodule.recurse true
+```
+in the checkout so that `--recurse-submodules` doesn't have to be
+specified with `git pull/checkout/...`.
 
 The above commands will compile the Lean library and binaries into the
-`stage1` subfolder; see below for details.
+`stage1` subfolder; see below for details. Add `-j N` for an
+appropriate `N` to `make` for a parallel build.
 
-You should not usually run `cmake --install` after a successful build.
+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.
+
+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
 -----------------------------------
 
-Pass these along with the `cmake --preset release` command.
-There are also two alternative presets that combine some of these options you can use instead of `release`: `debug` and `sandebug` (sanitize + debug).
+Pass these along with the `cmake ../..` command.
 
 * `-D CMAKE_BUILD_TYPE=`\
   Select the build type. Valid values are `RELEASE` (default), `DEBUG`,

doc/make/msvc.md

@@ -0,0 +1,39 @@
+# Compiling Lean with Visual Studio
+
+WARNING: Compiling Lean with Visual Studio doesn't currently work.
+There's an ongoing effort to port Lean to Visual Studio.
+The instructions below are for VS 2017.
+
+In the meantime you can use [MSYS2](msys2.md) or [WSL](wsl.md).
+
+## Installing dependencies
+
+First, install `vcpkg` from https://github.com/Microsoft/vcpkg if you haven't
+done so already.
+Then, open a console in the directory you cloned `vcpkg` to, and type:
+`vcpkg install mpir` for the 32-bit library or
+`vcpkg install mpir:x64-windows` for the x64 one.
+
+In Visual Studio, use the "open folder" feature and open the Lean directory.
+Go to the `CMake->Change CMake Settings` menu. File `CMakeSettings.json` opens.
+In each of the targets, add the following snippet (i.e., after every
+`ctestCommandArgs`):
+
+```json
+    "variables": [
+      {
+        "name": "CMAKE_TOOLCHAIN_FILE",
+        "value": "C:\\path\\to\\vcpkg\\scripts\\buildsystems\\vcpkg.cmake"
+      }
+    ]
+```
+
+## Enable Intellisense
+
+In Visual Studio, press Ctrl+Q and type `CppProperties.json` and press Enter.
+Ensure `includePath` variables include `"${workspaceRoot}\\src"`.
+
+
+## Build Lean
+
+Press F7.

doc/make/msys2.md

@@ -15,24 +15,17 @@ Mode](https://docs.microsoft.com/en-us/windows/apps/get-started/enable-your-devi
 which will allow Lean to create symlinks that e.g. enable go-to-definition in
 the stdlib.
 
-## Installing the Windows SDK
-
-Install the Windows SDK from [Microsoft](https://developer.microsoft.com/en-us/windows/downloads/windows-sdk/).
-The oldest supported version is 10.0.18362.0. If you installed the Windows SDK to the default location,
-then there should be a directory with the version number at `C:\Program Files (x86)\Windows Kits\10\Include`.
-If there are multiple directories, only the highest version number matters.
-
 ## Installing dependencies
 
 [The official webpage of MSYS2][msys2] provides one-click installers.
-Once installed, you should run the "MSYS2 CLANG64" shell from the start menu (the one that runs `clang64.exe`).
-Do not run "MSYS2 MSYS" or "MSYS2 MINGW64" instead!
-MSYS2 has a package management system, [pacman][pacman].
+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.
 
 Here are the commands to install all dependencies needed to compile Lean on your machine.
 
 ```bash
-pacman -S make python mingw-w64-clang-x86_64-cmake mingw-w64-clang-x86_64-clang mingw-w64-clang-x86_64-ccache mingw-w64-clang-x86_64-libuv mingw-w64-clang-x86_64-gmp git unzip diffutils binutils
+pacman -S make python mingw-w64-x86_64-cmake mingw-w64-x86_64-clang mingw-w64-x86_64-ccache git unzip diffutils binutils
 ```
 
 You should now be able to run these commands:
@@ -45,9 +38,10 @@ cmake --version
 Then follow the [generic build instructions](index.md) in the MSYS2
 MinGW shell, using:
 ```
-cmake --preset release -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++
+cmake ../.. -G "Unix Makefiles"  -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++
 ```
-instead of `cmake --preset release`. This will use the clang compiler instead of gcc, which is required with msys2.
+instead of `cmake ../..`. This ensures that cmake will call `sh` instead of `cmd.exe`
+for script tasks and it will use the clang compiler instead of gcc, which is required.
 
 ## Install lean
 
@@ -68,9 +62,9 @@ If you want a version that can run independently of your MSYS install
 then you need to copy the following dependent DLL's from where ever
 they are installed in your MSYS setup:
 
-- libc++.dll
+- libgcc_s_seh-1.dll
+- libstdc++-6.dll
 - libgmp-10.dll
-- libuv-1.dll
 - libwinpthread-1.dll
 
 The following linux command will do that:
@@ -88,6 +82,6 @@ version clang to your path.
 
 **-bash: gcc: command not found**
 
-Make sure `/clang64/bin` is in your PATH environment.  If it is not then
-check you launched the MSYS2 CLANG64 shell from the start menu.
-(The one that runs `clang64.exe`).
+Make sure `/mingw64/bin` is in your PATH environment.  If it is not then
+check you launched the MSYS2 MinGW 64-bit shell from the start menu.
+(The one that runs `mingw64.exe`).

doc/make/nix.md

@@ -0,0 +1,110 @@
+# Building with Nix
+
+While [Nix](https://nixos.org/nix/) can be used to quickly open a shell with all dependencies for the [standard setup](index.md) installed, the user-facing [Nix Setup](../setup.md#nix-setup) can also be used to work *on* Lean.
+
+## Setup
+
+Follow the setup in the link above; to open the Lean shell inside a Lean checkout, you can also use
+```bash
+# in the Lean root directory
+$ nix-shell -A nix
+```
+
+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
+```
+Then set up that directory as follows:
+```bash
+sudo mkdir -m0770 -p /nix/var/cache/ccache
+# macOS standard chown doesn't support --reference
+nix shell .#nixpkgs.coreutils -c sudo chown --reference=/nix/store /nix/var/cache/ccache
+```
+
+## Basic Build Commands
+
+From the Lean root directory inside the Lean shell:
+```bash
+nix build .#stage1  # build this stage's stdlib & executable
+nix build .#stage1.test  # run all tests
+nix run .#stage1.update-stage0  # update ./stage0 from this stage
+nix run .#stage1.update-stage0-commit  # ...and commit the results
+```
+The `stage1.` part in each command is optional:
+```bash
+nix build .#test  # run tests for stage 1
+nix build .  # build stage 1
+nix build  # ditto
+```
+
+## Build Process Description
+
+The Nix build process conceptually works the same as described in [Lean Build Pipeline](index.md#lean-build-pipeline).
+However, there are two important differences in practice apart from the standard Nix properties (hermeneutic, reproducible builds stored in a global hash-indexed store etc.):
+* Only files tracked by git (using `git add` or at least `git add --intent-to-add`) are compiled.
+This is actually a general property of Nix flakes, and has the benefit of making it basically impossible to forget to commit a file (at least in `src/`).
+* Only files reachable from `src/Lean.lean` are compiled.
+This is because modules are discovered not from a directory listing anymore but by recursively compiling all dependencies of that top module.
+
+## Editor Integration
+
+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:
+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):
+```bash
+nix run github:leanprover/lean4/7e4edeb#emacs-package
+```
+
+Open a shell with `lean` and `LEAN_PATH` set up for compiling a specific module (this is exactly what `emacs-dev` is doing internally):
+```bash
+nix develop .#mods.\"Lean.Parser.Basic\"
+# alternatively, directly pass a command to execute:
+nix develop .#stage2.mods.\"Init.Control.Basic\" -c bash -c 'lean $src -Dtrace.Elab.command=true'
+```
+
+Not sure what you just broke? Run Lean from (e.g.) the previous commit on a file:
+```bash
+nix run .\?rev=$(git rev-parse @^) scratch.lean
+```
+
+Work on two adjacent stages at the same time without the need for repeatedly updating and reverting `stage0/`:
+```bash
+# open an editor that will use only committed changes (so first commit them when changing files)
+nix run .#HEAD-as-stage1.emacs-dev&
+# open a second editor that will use those commited changes as stage 0
+# (so don't commit changes done here until you are done and ran a final `update-stage0-commit`)
+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 --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.
+
+...more surely to come...
+
+## Debugging
+
+Since Nix copies all source files before compilation, you will need to map debug symbols back to the original path using `set substitute-path` in GDB.
+For example, for a build on Linux with the Nix sandbox activated:
+```bash
+(gdb) f
+#1  0x0000000000d23a4f in lean_inc (o=0x1) at /build/source/build/include/lean/lean.h:562
+562	/build/source/build/include/lean/lean.h: No such file or directory.
+(gdb) set substitute-path /build/source/build src
+(gdb) f
+#1  0x0000000000d23a4f in lean_inc (o=0x1) at /build/source/build/include/lean/lean.h:562
+562	static inline void lean_inc(lean_object * o) { if (!lean_is_scalar(o)) lean_inc_ref(o); }
+```

doc/make/osx-10.9.md

@@ -1,4 +1,4 @@
-# Install Packages on OS X 14.5
+# Install Packages on OS X 10.9
 
 We assume that you are using [homebrew][homebrew] as a package manager.
 
@@ -22,7 +22,7 @@ brew install gcc
 ```
 To install clang++-3.5 via homebrew, please execute:
 ```bash
-brew install llvm
+brew install llvm --with-clang --with-asan
 ```
 To use compilers other than the default one (Apple's clang++), you
 need to use `-DCMAKE_CXX_COMPILER` option to specify the compiler
@@ -32,16 +32,15 @@ following to use `g++`.
 cmake -DCMAKE_CXX_COMPILER=g++ ...
 ```
 
-## Required Packages: CMake, GMP, libuv
+## Required Packages: CMake, GMP
 
 ```bash
 brew install cmake
 brew install gmp
-brew install libuv
 ```
 
 ## Recommended Packages: CCache
 
 ```bash
 brew install ccache
-```
+```

doc/make/ubuntu.md

@@ -8,5 +8,5 @@ follow the [generic build instructions](index.md).
 ## Basic packages
 
 ```bash
-sudo apt-get install git libgmp-dev libuv1-dev cmake ccache clang
+sudo apt-get install git libgmp-dev cmake ccache clang
 ```

doc/metaprogramming-arith.md

@@ -60,7 +60,7 @@ While parsing `a * (b + c)`, `(b + c)` is assigned a precedence `60` by the addi
 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](./notation.md#notations-and-precedence).
+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

doc/monads/.gitignore

@@ -0,0 +1 @@
+*.lean.md

doc/monads/applicatives.lean

@@ -0,0 +1,334 @@
+/-!
+# Applicative Functors
+
+Building on [Functors](functors.lean.md) is the [Applicative
+Functor](https://en.wikipedia.org/wiki/Applicative_functor). For simplicity, you can refer to these
+simply as "Applicatives". These are a little tricker than functors, but still simpler than monads.
+Let's see how they work!
+
+## What is an Applicative Functor?
+
+An applicative functor defines a default or "base" construction for an object and allows
+function application to be chained across multiple instances of the structure. All applicative
+functors are functors, meaning they must also support the "map" operation.
+
+## How are Applicatives represented in Lean?
+
+An [applicative functor](https://en.wikipedia.org/wiki/Applicative_functor) is an intermediate
+structure between `Functor` and `Monad`. It mainly consists of two operations:
+
+* `pure : α → F α`
+* `seq : F (α → β) → F α → F β` (written as `<*>`)
+
+The `pure` operator specifies how you can wrap a normal object `α` into an instance of this structure `F α`.
+This is the "default" mechanism mentioned above.
+
+The `seq` operator allows you to chain operations by wrapping a function in a structure. The name
+"applicative" comes from the fact that you "apply" functions from within the structure, rather than
+simply from outside the structure, as was the case with `Functor.map`.
+
+Applicative in Lean is built on some helper type classes, `Functor`, `Pure` and `Seq`:
+
+-/
+namespace hidden -- hidden
+class Applicative (f : Type u → Type v) extends Functor f, Pure f, Seq f, SeqLeft f, SeqRight f where
+  map      := fun x y => Seq.seq (pure x) fun _ => y
+  seqLeft  := fun a b => Seq.seq (Functor.map (Function.const _) a) b
+  seqRight := fun a b => Seq.seq (Functor.map (Function.const _ id) a) b
+end hidden -- hidden
+/-!
+Notice that as with `Functor` it is also a type transformer `(f : Type u → Type v)` and notice the
+`extends Functor f` is ensuring the base `Functor` also performs that same type transformation.
+
+As stated above, all applicatives are then functors. This means you can assume that `map` already
+exists for all these types.
+
+The `Pure` base type class is a very simple type class that supplies the `pure` function.
+
+-/
+namespace hidden -- hidden
+class Pure (f : Type u → Type v) where
+   pure {α : Type u} : α → f α
+end hidden -- hidden
+/-!
+
+You can think of it as lifting the result of a pure value to some monadic type. The simplest example
+of `pure` is the `Option` type:
+
+-/
+#eval (pure 10 : Option Nat)  -- some 10
+/-!
+
+Here we used the `Option` implementation of `pure` to wrap the `Nat 10` value in an `Option Nat`
+type resulting in the value `some 10`, and in fact if you look at the Monad instance of `Option` , you
+will see that `pure` is indeed implemented using `Option.some`:
+
+-/
+instance : Monad Option where
+    pure := Option.some
+/-!
+
+The `Seq` type class is also a simple type class that provides the `seq` operator which can
+also be written using the special syntax `<*>`.
+
+-/
+namespace hidden -- hidden
+class Seq (f : Type u → Type v) : Type (max (u+1) v) where
+  seq : {α β : Type u} → f (α → β) → (Unit → f α) → f β
+end hidden -- hidden
+/-!
+
+
+## Basic Applicative Examples
+
+Many of the basic functors also have instances of `Applicative`.
+For example, `Option` is also `Applicative`.
+
+So let's take a look and what the `seq` operator can do.  Suppose you want to multiply two `Option Nat`
+objects.  Your first attempt might be this:
+
+-/
+#check_failure (some 4) * (some 5)      -- failed to synthesize instance
+/-!
+
+You then might wonder how to use the `Functor.map` to solve this since you could do these before:
+
+-/
+#eval (some 4).map (fun x => x * 5)  -- some 20
+
+#eval (some 4).map (· * 5)  -- some 20
+
+#eval (· * 5) <$> (some 4)   -- some 20
+/-!
+
+Remember that `<$>` is the infix notation for `Functor.map`.
+
+The functor `map` operation can apply a multiplication to the value in the `Option` and then lift the
+result back up to become a new `Option` , but this isn't what you need here.
+
+The `Seq.seq` operator `<*>` can help since it can apply a function to the items inside a
+container and then lift the result back up to the desired type, namely `Option` .
+
+There are two ways to do this:
+
+-/
+#eval pure (.*.) <*> some 4 <*> some 5 -- some 20
+
+#eval (.*.) <$> some 4 <*> some 5 -- some 20
+/-!
+
+In the first way, we start off by wrapping the function in an applicative using pure. Then we apply
+this to the first `Option` , and again to the second `Option`  in a chain of operations.  So  you can see
+how `Seq.seq` can be chained in fact, `Seq.seq` is really all about chaining of operations.
+
+But in this case there is a simpler way.  In the second way, you can see that "applying" a single
+function to a container is the same as using `Functor.map`. So you use `<$>` to "transform" the first
+option into an `Option` containing a function, and then apply this function over the second value.
+
+Now if either side is `none`, the result is `none`, as expected, and in this case the
+`seq` operator was able to eliminate the multiplication:
+
+-/
+#eval (.*.) <$> none <*> some 5  -- none
+#eval (.*.) <$> some 4 <*> none  -- none
+/-!
+
+For a more interesting example, let's make `List` an applicative by adding the following
+definition:
+
+-/
+instance : Applicative List where
+  pure := List.pure
+  seq f x := List.bind f fun y => Functor.map y (x ())
+/-!
+
+Notice you can now sequence a _list_ of functions and a _list_ of items.
+The trivial case of sequencing a singleton list is in fact the same as `map`, as you saw
+earlier with the `Option`  examples:
+
+-/
+#eval [ (·+2)] <*> [4, 6] -- [6, 8]
+#eval (·+2) <$> [4,6]    -- [6, 8]
+/-!
+
+But now with list it is easier to show the difference when you do this:
+
+-/
+#eval [(·+2), (· *3)] <*> [4, 6] -- [6, 8, 12, 18]
+/-!
+
+Why did this produce 4 values?  The reason is because `<*>` applies _every_ function to _every_
+value in a pairwise manner.  This makes sequence really convenient for solving certain problems. For
+example, how do you get the pairwise combinations of all values from two lists?
+
+-/
+#eval Prod.mk <$> [1, 2, 3] <*> [4, 5, 6]
+-- [(1, 4), (1, 5), (1, 6), (2, 4), (2, 5), (2, 6), (3, 4), (3, 5), (3, 6)]
+/-!
+
+How do you get the sum of these pairwise values?
+-/
+#eval (·+·) <$> [1, 2, 3] <*> [4, 5, 6]
+-- [5, 6, 7, 6, 7, 8, 7, 8, 9]
+/-!
+
+Here you can use `<$>` to "transform" each element of the first list into a function, and then apply
+these functions over the second list.
+
+If you have 3 lists, and want to find all combinations of 3 values across those lists you
+would need helper function that can create a tuple out of 3 values, and Lean provides a
+very convenient syntax for that `(·,·,·)`:
+
+-/
+#eval (·,·,·) <$> [1, 2] <*> [3, 4] <*> [5, 6]
+-- [(1, 3, 5), (1, 3, 6), (1, 4, 5), (1, 4, 6), (2, 3, 5), (2, 3, 6), (2, 4, 5), (2, 4, 6)]
+/-!
+
+And you could sum these combinations if you first define a sum function that takes three inputs and
+then you could chain apply this over the three lists.  Again lean can create such a function
+with the expression `(·+·+·)`:
+
+-/
+#eval (·+·+·) <$> [1, 2] <*> [3, 4] <*> [5, 6]
+-- [9, 10, 10, 11, 10, 11, 11, 12]
+/-!
+
+And indeed each sum here matches the expected values if you manually sum the triples we
+show above.
+
+**Side note:** there is another way to combine lists with a function that does not do the pairwise
+combinatorics, it is called `List.zipWith`:
+
+-/
+#eval List.zipWith (·+·) [1, 2, 3] [4, 5, 6]
+-- [5, 7, 9]
+/-!
+
+And there is a helper function named `List.zip` that calls `zipWith` using the function `Prod.mk`
+so you get a nice zipped list like this:
+
+-/
+#eval List.zip [1, 2, 3] [4, 5, 6]
+-- [(1, 4), (2, 5), (3, 6)]
+/-!
+
+And of couse, as you would expect, there is an `unzip` also:
+
+-/
+#eval List.unzip (List.zip [1, 2, 3] [4, 5, 6])
+-- ([1, 2, 3], [4, 5, 6])
+/-!
+
+## Example: A Functor that is not Applicative
+
+From the chapter on [functors](functors.lean.md) you might remember this example of `LivingSpace`
+that had a `Functor` instance:
+
+-/
+structure LivingSpace (α : Type) where
+  totalSize : α
+  numBedrooms : Nat
+  masterBedroomSize : α
+  livingRoomSize : α
+  kitchenSize : α
+  deriving Repr, BEq
+
+def LivingSpace.map (f : α → β) (s : LivingSpace α) : LivingSpace β :=
+  { totalSize := f s.totalSize
+    numBedrooms := s.numBedrooms
+    masterBedroomSize := f s.masterBedroomSize
+    livingRoomSize := f s.livingRoomSize
+    kitchenSize := f s.kitchenSize }
+
+instance : Functor LivingSpace where
+  map := LivingSpace.map
+/-!
+
+It wouldn't really make sense to make an `Applicative` instance here. How would you write `pure` in
+the `Applicative` instance? By taking a single value and plugging it in for total size _and_ the
+master bedroom size _and_ the living room size? That wouldn't really make sense. And what would the
+numBedrooms value be for the default? What would it mean to "chain" two of these objects together?
+
+If you can't answer these questions very well, then it suggests this type isn't really an
+Applicative functor.
+
+## SeqLeft and SeqRight
+
+You may remember seeing the `SeqLeft` and `SeqRight` base types on `class Applicative` earlier.
+These provide the `seqLeft` and `seqRight` operations which also have some handy notation
+shorthands `<*` and `*>` respectively. Where: `x <* y` evaluates `x`, then `y`, and returns the
+result of `x` and `x *> y` evaluates `x`, then `y`,  and returns the result of `y`.
+
+To make it easier to remember, notice that it returns that value that the `<*` or `*>` notation is
+pointing at.  For example:
+
+-/
+#eval (some 1) *> (some 2) -- Some 2
+#eval (some 1) <* (some 2) -- Some 1
+/-!
+
+So these are a kind of "discard" operation.  Run all the actions, but only return the values that you
+care about. It will be easier to see these in action when you get to full Monads, but they are used
+heavily in the Lean `Parsec` parser combinator library where you will find parsing functions like
+this one which parses the XML declaration `<?xml version="1.0" encoding='utf-8' standalone="yes">`:
+
+```lean
+def XMLdecl : Parsec Unit := do
+  skipString "<?xml"
+  VersionInfo
+  optional EncodingDecl *> optional SDDecl *> optional S *> skipString "?>"
+```
+
+But you will need to understand full Monads before this will make sense.
+
+## Lazy Evaluation
+
+Diving a bit deeper, (you can skip this and jump to the [Applicative
+Laws](laws.lean.md#what-are-the-applicative-laws) if don't want to dive into this implementation detail right
+now). But, if you write a simple `Option` example `(.*.) <$> some 4 <*> some 5` that produces `some 20`
+using `Seq.seq` you will see somthing interesting:
+
+-/
+#eval Seq.seq ((.*.) <$> some 4) (fun (_ : Unit) => some 5) -- some 20
+/-!
+
+This may look a bit cumbersome, specifically, why did we need to invent this funny looking function
+`fun (_ : Unit) => (some 5)`?
+
+Well if you take a close look at the type class definition:
+```lean
+class Seq (f : Type u → Type v) where
+  seq : {α β : Type u} → f (α → β) → (Unit → f α) → f β
+```
+
+You will see this function defined here: `(Unit → f α)`, this is a function that takes `Unit` as input
+and produces the output of type `f α` where `f` is the container type `Type u -> Type v`, in this example `Option`
+and `α` is the element type `Nat`, so `fun (_ : Unit) => some 5` matches this definition because
+it is taking an input of type Unit and producing `some 5` which is type `Option Nat`.
+
+The that `seq` is defined this way is because Lean is an eagerly evaluated language
+(call-by-value), you have to use this kind of Unit function whenever you want to explicitly delay
+evaluation and `seq` wants that so it can eliminate unnecessary function evaluations whenever
+possible.
+
+Fortunately the `<*>` infix notation hides this from you by creating this wrapper function for you.
+If you look up the notation using F12 in VS Code you will find it contains `(fun _ : Unit => b)`.
+
+Now to complete this picture you will find the default implementation of `seq` on the Lean `Monad`
+type class:
+
+```lean
+class Monad (m : Type u → Type v) extends Applicative m, Bind m where
+  seq      f x := bind f fun y => Functor.map y (x ())
+```
+
+Notice here that `x` is the `(Unit → f α)` function, and it is calling that function by passing the
+Unit value `()`, which is the Unit value (Unit.unit).  All this just to ensure delayed evaluation.
+
+## How do Applicatives help with Monads?
+
+Applicatives are helpful for the same reasons as functors. They're a relatively simple abstract
+structure that has practical applications in your code. Now that you understand how chaining
+operations can fit into a structure definition, you're in a good position to start learning about
+[Monads](monads.lean.md)!
+-/

doc/monads/except.lean

@@ -0,0 +1,178 @@
+/-!
+# Except
+
+The `Except` Monad adds exception handling behavior to your functions.  Exception handling
+in other languages like Python or Java is done with a built in `throw` method that you
+can use anywhere.  In `Lean` you can only `throw` an exception when your function is
+executing in the context of an `Except` monad.
+
+-/
+def divide (x y: Float): Except String Float :=
+  if y == 0 then
+    throw "can't divide by zero"
+  else
+    pure (x / y)
+
+#eval divide 5 2  -- Except.ok 2.500000
+#eval divide 5 0  -- Except.error "can't divide by zero"
+
+/-!
+
+Just as the `read` operation was available from the `ReaderM` monad and the `get` and `set`
+operations came with the `StateM` monad, here you can see a `throw` operation is provided by the
+`Except` monad.
+
+So in Lean, `throw` is not available everywhere like it is in most imperative programming languages.
+You have to declare your function can throw by changing the type signature to `Except String Float`.
+This creates a function that might return an error of type `String` or it might return a value of
+type `Float` in the non-error case.
+
+Once your function is monadic you also need to use the `pure` constructor of the `Except` monad to
+convert the pure non-monadic value `x / y` into the required `Except` object.  See
+[Applicatives](applicatives.lean.md) for details on `pure`.
+
+Now this return typing would get tedious if you had to include it everywhere that you call this
+function, however, Lean type inference can clean this up. For example, you can define a test
+function can calls the `divide` function and you don't need to say anything here about the fact that
+it might throw an error, because that is inferred:
+-/
+def test := divide 5 0
+
+#check test     -- Except String Float
+/-!
+
+Notice the Lean compiler infers the required `Except String Float` type information for you.
+And now you can run this test and get the expected exception:
+
+-/
+#eval test      -- Except.error "can't divide by zero"
+/-!
+
+
+## Chaining
+
+Now as before you can build a chain of monadic actions that can be composed together using `bind (>>=)`:
+-/
+def square (x : Float) : Except String Float :=
+  if x >= 100 then
+    throw "it's absolutely huge"
+  else
+    pure (x * x)
+
+#eval divide 6 2 >>= square  -- Except.ok 9.000000
+#eval divide 6 0 >>= square  -- Except.error "can't divide by zero"
+#eval divide 100 1 >>= square  -- Except.error "it's absolutely huge"
+
+def chainUsingDoNotation := do
+  let r ← divide 6 0
+  square r
+
+#eval chainUsingDoNotation  -- Except.error "can't divide by zero"
+
+/-!
+Notice in the second `divide 6 0` the exception from that division was nicely propagated along
+to the final result and the square function was ignored in that case.  You can see why the
+`square` function was ignored if you look at the implementation of `Except.bind`:
+-/
+def bind (ma : Except ε α) (f : α → Except ε β) : Except ε β :=
+  match ma with
+  | Except.error err => Except.error err
+  | Except.ok v      => f v
+/-!
+
+Specifically notice that it only calls the next function `f v` in the `Except.ok`, and
+in the error case it simply passes the same error along.
+
+Remember also that you can chain the actions with implicit binding by using the `do` notation
+as you see in the `chainUsingDoNotation` function above.
+
+## Try/Catch
+
+Now with all good exception handling you also want to be able to catch exceptions so your program
+can continue on or do some error recovery task, which you can do like this:
+-/
+def testCatch :=
+  try
+    let r ← divide 8 0  -- 'r' is type Float
+    pure (toString r)
+  catch e =>
+    pure s!"Caught exception: {e}"
+
+#check testCatch -- Except String String
+/-!
+
+Note that the type inferred by Lean for this function is `Except String String` so unlike the
+`test` function earlier, this time Lean type inference has figured out that since the pure
+value `(toString r)` is of type `String`, then this function must have type `Except String String`
+so you don't have to explicitly state this. You can always hover your mouse over `testCatch`
+or use `#check testCatch` to query Lean interactively to figure out what type inference
+has decided.  Lean type inference makes life easy for you, so it's good to use it
+when you can.
+
+You can now see the try/catch working in this eval:
+-/
+#eval testCatch -- Except.ok "Caught exception: can't divide by zero"
+/-!
+
+Notice the `Caught exception:` wrapped message is returned, and that it is returned as an
+`Except.ok` value, meaning `testCatch` eliminated the error result as expected.
+
+So you've interleaved a new concept into your functions (exception handling) and the compiler is still
+able to type check everything just as well as it does for pure functions and it's been able to infer
+some things along the way to make it even easier to manage.
+
+Now you might be wondering why `testCatch` doesn't infer the return type `String`? Lean does this as a
+convenience since you could have a rethrow in or after the catch block. If you really want to stop
+the `Except` type from bubbling up you can unwrap it like this:
+
+-/
+def testUnwrap : String := Id.run do
+  let r ← divide 8 0 -- r is type Except String Float
+  match r with
+  | .ok a => toString a -- 'a' is type Float
+  | .error e => s!"Caught exception: {e}"
+
+#check testUnwrap -- String
+#eval testUnwrap -- "Caught exception: can't divide by zero"
+
+/-!
+
+The `Id.run` function is a helper function that executes the `do` block and returns the result where
+`Id` is the _identity monad_.  So `Id.run do` is a pattern you can use to execute monads in a
+function that is not itself monadic.  This works for all monads except `IO` which, as stated earlier,
+you cannot invent out of thin air, you must use the `IO` monad given to your `main` function.
+
+## Monadic functions
+
+You can also write functions that are designed to operate in the context of a monad.
+These functions typically end in upper case M like `List.forM` used below:
+-/
+
+def validateList (x : List Nat) (max : Nat): Except String Unit := do
+  x.forM fun a => do
+    if a > max then throw "illegal value found in list"
+
+#eval validateList [1, 2, 5, 3, 8] 10 -- Except.ok ()
+#eval validateList [1, 2, 5, 3, 8] 5 -- Except.error "illegal value found in list"
+
+/-!
+Notice here that the `List.forM` function passes the monadic context through to the inner function
+so it can use the `throw` function from the `Except` monad.
+
+The `List.forM` function is defined like this where `[Monad m]` means "in the context of a monad `m`":
+
+-/
+def forM [Monad m] (as : List α) (f : α → m PUnit) : m PUnit :=
+  match as with
+  | []      => pure ⟨⟩
+  | a :: as => do f a; List.forM as f
+/-!
+
+## Summary
+
+Now that you know all these different monad constructs, you might be wondering how you can combine
+them. What if there was some part of your state that you wanted to be able to modify (using the
+State monad), but you also needed exception handling. How can you get multiple monadic capabilities
+in the same function. To learn the answer, head to [Monad Transformers](transformers.lean.md).
+
+-/