packages feed

idris 1.3.2 → 1.3.3

raw patch · 1291 files changed

+6002/−25318 lines, 1291 filesdep +faildep ~ansi-terminaldep ~base64-bytestringdep ~blaze-markupsetup-changednew-uploader

Dependencies added: fail

Dependency ranges changed: ansi-terminal, base64-bytestring, blaze-markup, cheapskate, fsnotify, megaparsec, network, optparse-applicative, text, time

Files

− .gitattributes 
@@ -1,1 +0,0 @@-* text=auto
− .github/ISSUE_TEMPLATE.md 
@@ -1,9 +0,0 @@-Please attach complete source files that exhibit the issue in addition-to quoting from them here.--# Steps to Reproduce--# Expected Behavior--# Observed Behavior-
− .gitignore 
@@ -1,55 +0,0 @@-# Build artefacts-dist-dist-newstyle-*.ibc-*.o-*.a-*.so-*.dll-*.dylib-src/Version_idris.hs--# Doc generation artefacts-libs/base/base_doc/-libs/effects/effects_doc/-libs/prelude/prelude_doc/-libs/contrib/contrib_doc/-libs/pruviloj/pruviloj_doc/-libs/oldeffects/oldeffects_doc/--# Test artefacts-test/output-test/*[0-9][0-9][0-9]/output-test/*[0-9][0-9][0-9]/*.exe-test/runtest.exe-test/runtest-.tasty-rerun-log--# Haskell build tools-cabal-dev/-.cabal-sandbox-cabal.sandbox.config-cabal.config-.stack-work-.hsenv--# For convenience-custom.mk-\#*-.\#*-tags-TAGS--# IDE and editors-*.swp-*~-.DS_Store-.hpc-*.orig-*.tix-*.dSYM-.projectile-.dir-locals.el-.vscode-.idea-
− .hlint.yaml 
@@ -1,61 +0,0 @@-# HLint configuration file-# https://github.com/ndmitchell/hlint-##########################--# This file contains a template configuration file, which is typically-# placed as .hlint.yaml in the root of your project---# Specify additional command line arguments-#-# - arguments: [--color, --cpp-simple, -XQuasiQuotes]---# Control which extensions/flags/modules/functions can be used-#-# - extensions:-#   - default: false # all extension are banned by default-#   - name: [PatternGuards, ViewPatterns] # only these listed extensions can be used-#   - {name: CPP, within: CrossPlatform} # CPP can only be used in a given module-#-# - flags:-#   - {name: -w, within: []} # -w is allowed nowhere-#-# - modules:-#   - {name: [Data.Set, Data.HashSet], as: Set} # if you import Data.Set qualified, it must be as 'Set'-#   - {name: Control.Arrow, within: []} # Certain modules are banned entirely-#-# - functions:-#   - {name: unsafePerformIO, within: []} # unsafePerformIO can only appear in no modules---# Add custom hints for this project-#-# Will suggest replacing "wibbleMany [myvar]" with "wibbleOne myvar"-# - error: {lhs: "wibbleMany [x]", rhs: wibbleOne x}---# Turn on hints that are off by default-#-# Ban "module X(module X) where", to require a real export list-# - warn: {name: Use explicit module export list}-#-# Replace a $ b $ c with a . b $ c-# - group: {name: dollar, enabled: true}-#-# Generalise map to fmap, ++ to <>-# - group: {name: generalise, enabled: true}---# Ignore some builtin hints-# - ignore: {name: Use let}-# - ignore: {name: Use const, within: SpecialModule} # Only within certain modules-- ignore: {name: Use camelCase}-- ignore: {name: Reduce duplication}--# Define some custom infix operators-# - fixity: infixr 3 ~^#^~---# To generate a suitable file for HLint do:-# $ hlint --default > .hlint.yaml
− .stylish-haskell.yaml 
@@ -1,154 +0,0 @@-# stylish-haskell configuration file-# ==================================--# The stylish-haskell tool is mainly configured by specifying steps. These steps-# are a list, so they have an order, and one specific step may appear more than-# once (if needed). Each file is processed by these steps in the given order.-steps:-  # Convert some ASCII sequences to their Unicode equivalents. This is disabled-  # by default.-  # - unicode_syntax:-  #     # In order to make this work, we also need to insert the UnicodeSyntax-  #     # language pragma. If this flag is set to true, we insert it when it's-  #     # not already present. You may want to disable it if you configure-  #     # language extensions using some other method than pragmas. Default:-  #     # true.-  #     add_language_pragma: true--  # Import cleanup-  - imports:-      # There are different ways we can align names and lists.-      #-      # - global: Align the import names and import list throughout the entire-      #   file.-      #-      # - file: Like global, but don't add padding when there are no qualified-      #   imports in the file.-      #-      # - group: Only align the imports per group (a group is formed by adjacent-      #   import lines).-      #-      # - none: Do not perform any alignment.-      #-      # Default: global.-      align: none--      # Folowing options affect only import list alignment.-      #-      # List align has following options:-      #-      # - after_alias: Import list is aligned with end of import including-      #   'as' and 'hiding' keywords.-      #-      #   > import qualified Data.List      as List (concat, foldl, foldr, head,-      #   >                                          init, last, length)-      #-      # - with_alias: Import list is aligned with start of alias or hiding.-      #-      #   > import qualified Data.List      as List (concat, foldl, foldr, head,-      #   >                                 init, last, length)-      #-      # - new_line: Import list starts always on new line.-      #-      #   > import qualified Data.List      as List-      #   >     (concat, foldl, foldr, head, init, last, length)-      #-      # Default: after_alias-      list_align: after_alias--      # Long list align style takes effect when import is too long. This is-      # determined by 'columns' setting.-      #-      # - inline: This option will put as much specs on same line as possible.-      #-      # - new_line: Import list will start on new line.-      #-      # - new_line_multiline: Import list will start on new line when it's-      #   short enough to fit to single line. Otherwise it'll be multiline.-      #-      # - multiline: One line per import list entry.-      #   Type with contructor list acts like single import.-      #-      #   > import qualified Data.Map as M-      #   >     ( empty-      #   >     , singleton-      #   >     , ...-      #   >     , delete-      #   >     )-      #-      # Default: inline-      long_list_align: inline--      # List padding determines indentation of import list on lines after import.-      # This option affects 'list_align' and 'long_list_align'.-      list_padding: 4--      # Separate lists option affects formating of import list for type-      # or class. The only difference is single space between type and list-      # of constructors, selectors and class functions.-      #-      # - true: There is single space between Foldable type and list of it's-      #   functions.-      #-      #   > import Data.Foldable (Foldable (fold, foldl, foldMap))-      #-      # - false: There is no space between Foldable type and list of it's-      #   functions.-      #-      #   > import Data.Foldable (Foldable(fold, foldl, foldMap))-      #-      # Default: true-      separate_lists: false--  # Language pragmas-  - language_pragmas:-      # We can generate different styles of language pragma lists.-      #-      # - vertical: Vertical-spaced language pragmas, one per line.-      #-      # - compact: A more compact style.-      #-      # - compact_line: Similar to compact, but wrap each line with-      #   `{-#LANGUAGE #-}'.-      #-      # Default: vertical.-      style: compact--      # Align affects alignment of closing pragma brackets.-      #-      # - true: Brackets are aligned in same collumn.-      #-      # - false: Brackets are not aligned together. There is only one space-      #   between actual import and closing bracket.-      #-      # Default: true-      align: true--      # stylish-haskell can detect redundancy of some language pragmas. If this-      # is set to true, it will remove those redundant pragmas. Default: true.-      remove_redundant: true--  # Align the types in record declarations-  # - records: {}--  # Replace tabs by spaces. This is disabled by default.-  - tabs:-  #     # Number of spaces to use for each tab. Default: 8, as specified by the-  #     # Haskell report.-      spaces: 8--  # Remove trailing whitespace-  - trailing_whitespace: {}--# A common setting is the number of columns (parts of) code will be wrapped-# to. Different steps take this into account. Default: 80.-columns: 80--# Sometimes, language extensions are specified in a cabal file or from the-# command line instead of using language pragmas in the file. stylish-haskell-# needs to be aware of these, so it can parse the file correctly.-#-# No language extensions are enabled by default.-# language_extensions:-  # - TemplateHaskell-  # - QuasiQuotes
− .travis.yml 
@@ -1,158 +0,0 @@-dist: trusty-sudo: false--language: c--env:-  global:-    - PKGNAME=idris--matrix:-  include:-    - env: CABALVER="2.2" GHCVER="8.4.1" STACKVER="7.14" STYLISH=YES-      addons: {apt: {packages: [cabal-install-2.2,ghc-8.4.1,hscolour], sources: [hvr-ghc]}}-    - env: CABALVER="2.2" GHCVER="7.10.3" TESTS="test_c"-      compiler: ": #GHC 7.10.3"-      addons: {apt: {packages: [cabal-install-2.2,ghc-7.10.3,cppcheck,hscolour], sources: [hvr-ghc]}}-# Disabled because it's always timing out-#    - env: CABALVER="1.24" GHCVER="8.0.1" TESTS="test_c"-#      compiler: ": #GHC 8.0.1"-#      addons: {apt: {packages: [cabal-install-1.24,ghc-8.0.1,cppcheck,hscolour], sources: [hvr-ghc]}}-    - env: CABALVER="2.0" GHCVER="8.2.2" TESTS="lib_doc doc"-      compiler: ": #GHC 8.2.2"-      addons: {apt: {packages: [cabal-install-2.0,ghc-8.2.2,cppcheck,hscolour], sources: [hvr-ghc]}}-    - env: CABALVER="2.0" GHCVER="8.2.2" TESTS="test_js"-      compiler: ": #GHC 8.2.2"-      addons: {apt: {packages: [cabal-install-2.0,ghc-8.2.2,cppcheck,hscolour], sources: [hvr-ghc]}}-    - env: CABALVER="2.0" GHCVER="8.2.2" TESTS="test_c"-      compiler: ": #GHC 8.2.2"-      addons: {apt: {packages: [cabal-install-2.0,ghc-8.2.2,cppcheck,hscolour], sources: [hvr-ghc]}}-#TODO: The idris built with those fails due to libffi dynamic linking version mismatch.-#      Caused by the GHC backport to Trusty?-#    - env: CABALVER="2.2" GHCVER="8.4.1" TESTS="lib_doc doc"-#      compiler: ": #GHC 8.4.1"-#      addons: {apt: {packages: [cabal-install-2.2,ghc-8.4.1,cppcheck,hscolour], sources: [hvr-ghc]}}-#    - env: CABALVER="2.2" GHCVER="8.4.1" TESTS="test_js"-#      compiler: ": #GHC 8.4.1"-#      addons: {apt: {packages: [cabal-install-2.2,ghc-8.4.1,cppcheck,hscolour], sources: [hvr-ghc]}}-#    - env: CABALVER="2.2" GHCVER="8.4.1" TESTS="test_c"-#      compiler: ": #GHC 8.4.1"-#      addons: {apt: {packages: [cabal-install-2.2,ghc-8.4.1,cppcheck,hscolour], sources: [hvr-ghc]}}-  fast-finish: true--cache:-  directories:-    - $HOME/.cabsnap-    - $HOME/.cabal/packages-    - $HOME/.stack--before_cache:-  - rm -fv $HOME/.cabal/packages/hackage.haskell.org/build-reports.log-  - rm -fv $HOME/.cabal/packages/hackage.haskell.org/00-index.tar--before_install:-  - nvm install 6-  - nvm use 6-  - unset CC-  - if [[ $TRAVIS_OS_NAME == 'linux' ]];-    then-        export PATH=/opt/ghc/$GHCVER/bin:/opt/cabal/$CABALVER/bin:$HOME/.cabal/bin:$PATH;-        export SED=sed;-        export ZCAT=zcat;-    fi-  - env-  - if [[ $TRAVIS_OS_NAME == 'osx' ]];-    then-        brew outdated pkgconfig || brew install pkgconfig;-        brew install ghc cabal-install libffi cppcheck gnu-sed;-        export PATH=$HOME/.cabal/bin:$PATH;-        export SED=gsed;-        export ZCAT=gzcat;-        export PKG_CONFIG_PATH=/usr/local/opt/libffi/lib/pkgconfig:$PKG_CONFIG_PATH;-    fi-  - if [ -n "$STYLISH" ]; then ./stylize.sh; exit $?; fi--install:-  - which cabal-  - which ghc-  - cabal --version-  - echo "$(ghc --version) [$(ghc --print-project-git-commit-id 2> /dev/null || echo '?')]"-  - if [ -f $HOME/.cabal/packages/hackage.haskell.org/00-index.tar.gz ];-    then-      $ZCAT $HOME/.cabal/packages/hackage.haskell.org/00-index.tar.gz >-              $HOME/.cabal/packages/hackage.haskell.org/00-index.tar;-    fi-  - travis_retry cabal update -v-  # Run build with 2 parallel jobs-  # The container environment reports 16 cores,-  # causing cabal's default configuration (jobs: $ncpus)-  # to run into the GHC #9221 bug which can result in longer build-times.-  - $SED -i -r 's/(^jobs:).*/\1 2/' $HOME/.cabal/config-  - cabal install -f FFI --only-dependencies --enable-tests --dry -v > installplan.txt-  - $SED -i -e '1,/^Resolving /d' installplan.txt; cat installplan.txt-  # check whether current requested install-plan matches cached package-db snapshot-  - if diff -u installplan.txt $HOME/.cabsnap/installplan.txt;-    then-      echo "cabal build-cache HIT";-      rm -rfv .ghc;-      cp -a $HOME/.cabsnap/ghc $HOME/.ghc;-      cp -a $HOME/.cabsnap/lib $HOME/.cabsnap/share $HOME/.cabsnap/bin $HOME/.cabal/;-    else-      echo "cabal build-cache MISS";-      rm -rf $HOME/.cabsnap;-      mkdir -p $HOME/.ghc $HOME/.cabal/lib $HOME/.cabal/share $HOME/.cabal/bin;-      cabal install -f FFI --only-dependencies --enable-tests;-    fi-  # snapshot package-db on cache miss-  - if [ ! -d $HOME/.cabsnap ];-    then-      echo "snapshotting package-db to build-cache";-      mkdir $HOME/.cabsnap;-      cp -a $HOME/.ghc $HOME/.cabsnap/ghc;-      cp -a $HOME/.cabal/lib $HOME/.cabal/share $HOME/.cabal/bin installplan.txt $HOME/.cabsnap/;-    fi--before_script:-  - ORIGINAL_DIR=$(pwd)-  - cabal sdist-  - cd ..-  - tar -xf ${ORIGINAL_DIR}/dist/${PKGNAME}*.tar.gz-  - cd ${PKGNAME}*-script:-###-  - echo 'Configure...' && echo -en 'travis_fold:start:script.configure\\r'-  - cabal configure -f FFI -f CI --enable-tests-  - echo -en 'travis_fold:end:script.configure\\r'-###-  - echo 'Build...' && echo -en 'travis_fold:start:script.build\\r'-  - cabal build-  - echo -en 'travis_fold:end:script.build\\r'-###-  - echo 'Copy...' && echo -en 'travis_fold:start:script.copy\\r'-  - cabal copy-  - echo -en 'travis_fold:end:script.copy\\r'-###-  - echo 'Register...' && echo -en 'travis_fold:start:script.register\\r'-  - cabal register-  - echo -en 'travis_fold:end:script.register\\r'-###-  - echo 'Cppcheck...' && echo -en 'travis_fold:start:script.cppcheck\\r'-  - if [[ "$TESTS" == "test_c" ]]; then-      cppcheck -i 'mini-gmp.c' rts;-    fi-  - echo -en 'travis_fold:end:script.cppcheck\\r'-###-  - echo 'Tests...' && echo -en 'travis_fold:start:script.tests\\r'-  - for test in $TESTS; do-      echo "make TEST-JOBS=2 $test";-      travis_wait make TEST-JOBS=2 $test;-    done-  - echo -en 'travis_fold:end:script.tests\\r'-###-  - echo 'Benchmarks...' && echo -en 'travis_fold:start:script.benchmarks\\r'-  - if [[ "$TESTS" == "test_c" ]]; then-      cd benchmarks && ./build.pl && ./run.pl && cd ..;-    fi-  - echo -en 'travis_fold:end:script.benchmarks\\r'-###-# EOF
CHANGELOG.md view
@@ -1,3 +1,9 @@+# New since last release++# New in 1.3.3++ Updated to work with GHC 8.8 and cabal 3.0++ Bugfixes and documentation updates+ # New in 1.3.2 + Documentation added to proof section
CITATION.md view
@@ -17,7 +17,7 @@   pages = {552--593},   numpages = {42},   doi = {10.1017/S095679681300018X},-  URL = {http://journals.cambridge.org/article_S095679681300018X},+  URL = {https://journals.cambridge.org/article_S095679681300018X}, } ```
CONTRIBUTING.md view
@@ -6,9 +6,9 @@  ## Getting Started -1. Make sure you are familiar with [Git](http://git-scm.com/book).+1. Make sure you are familiar with [Git](https://git-scm.com/book). 1. Make sure you have a [GitHub account](https://github.com/signup/free).-1. Make sure you are familiar with: [Idris](http://eb.host.cs.st-andrews.ac.uk/writings/idris-tutorial.pdf).+1. Make sure you are familiar with: [Idris](https://eb.host.cs.st-andrews.ac.uk/writings/idris-tutorial.pdf). 1. Make sure you can install Idris:   * [Mac OS X](https://github.com/idris-lang/Idris-dev/wiki/Idris-on-OS-X-using-Homebrew)   * [Ubuntu](https://github.com/idris-lang/Idris-dev/wiki/Idris-on-Ubuntu)@@ -72,7 +72,7 @@  ## Making Changes -Idris developers and hackers try to adhere to something similar to the [successful git branching model](http://nvie.com/posts/a-successful-git-branching-model/).+Idris developers and hackers try to adhere to something similar to the [successful git branching model](https://nvie.com/posts/a-successful-git-branching-model/). The steps are described below.  ### New contributors@@ -175,8 +175,8 @@ * Idris FAQs: [Official](https://idris.readthedocs.io/en/latest/faq/faq.html); [Unofficial](https://github.com/idris-lang/Idris-dev/wiki/Unofficial-FAQ); * [Idris Manual](https://github.com/idris-lang/Idris-dev/wiki/Manual); * [Idris Tutorial](https://idris.readthedocs.io/en/latest/tutorial/index.html);-* [Idris News](http://www.idris-lang.org/news/);-* [other Idris docs](http://www.idris-lang.org/documentation/).+* [Idris News](https://www.idris-lang.org/news/);+* [other Idris docs](https://www.idris-lang.org/documentation/). * [Using Pull Requests](https://help.github.com/articles/using-pull-requests) * [General GitHub Documentation](https://help.github.com/).
− INSTALL.md 
@@ -1,144 +0,0 @@-# Idris Installation Guide--Copyright (C) 2015, The Idris Community--## Installing Idris from Hackage--This repository represents the latest development version of the-language, and may contain bugs that are being actively worked on.  For-those who wish to use a more stable version of Idris please consider-installing the latest version that has been released on Hackage.-Installation instructions for various platforms can be-[found on the Idris Wiki](https://github.com/idris-lang/Idris-dev/wiki/Installation-Instructions).--## Installing Development Versions--If you like to work against the latest development version, please-consider using Cabal Sandboxes to minimise disruption to your local-Haskell setup.  Instructions for installing Idris HEAD within a cabal-sandbox are-[available on the Idris Wiki](https://github.com/idris-lang/Idris-dev/wiki/Installing-an-Idris-Development-version-in-a-sandbox).--To configure, edit config.mk. The default values should work for most-people.--Idris is built using a Makefile common targets include:--* `make` This will install everything using cabal and typecheck the-  libraries.-* `make test` This target execute the test suite.-* `make relib` This target will typecheck and recompile the standard-  library.--Idris has an optional dependency on the `C` library `libffi`. If you-would like to use the features that it enables, make sure that it is-compiled for the same architecture as your Haskell compiler (e.g. 64-bit libraries for 64 bit ghc). By default, Idris builds without it. To-build with it, pass the flag `-f FFI`.--A secondary optional dependency is on `libGMP`, this allows better-support for numeric operations. As with `libFFI` Idris builds with out-it, to enable `GMP` support use the flag `-f GMP`--To build with `libffi` and `libGMP` by default, create a `custom.mk`-file and add the following line to it:--`CABALFLAGS += -f FFI -f GMP`--The file `custom.mk-alldeps` is a suitable example.--The continuous integration builds on travis-ci.org are built using the-ghc-flag -Werror. To enable this behaviour locally also, please-compile using `make CI=true` or adding the following line into-`custom.mk`:--`CI = true`--If you are only compiling for installing the most current version, you-can omit the CI flag, but please make sure you use it if you want to-contribute.--## Experimental Support for Building with Stack--[Stack](https://github.com/commercialhaskell/stack) is a new-cross-platform program for developing Haskell projects, that enhances-the functionality provided by Cabal. There is experimental support for-building Idris from source with stack.--This installation has been tested on Ubuntu 16.04.1 LTS, and the current-NixOS unstable.--*Important* Stack will not install any external dependencies required-to build Idris. Before you try stack please ensure you have the-correct depenencies.--To build Idris with stack use the following command:--* `stack build`--To install Idris:--* `stack install`--Stack will install Idris (and related executables) into `$HOME/.local/bin/`-on Unix based systems and an appropriate place on Windows. The libraries that-are included with Idris (e.g. Builtins, Prelude) will 'install' into `<source-dir>/.stack_work/install/...` so you'll need to keep your source directory-around after you've installed Idris using Stack.--Of note: If you haven't used stack before commands will also setup the-related infrastructure. For more information about Stack please visit-the [Stack website](https://github.com/commercialhaskell/stack).--On NixOS, please use the following command instead, to make sure-the required libraries and header files are available:--* `stack build --nix`--### before rebuilding new pulls-the default build will currently just reuse `.ibc` files which can result-in build-failures in the `Building libraries...` phase.--A safer way to do this is therefore to recursively delete all the `*.ibc`-files from the `libs/` folder.--On Linux(or similar) you can do this with--    find . -name "*.ibc" -exec rm -rf {} \;--### System GHC--The flag `--system-ghc` can be added to enforce use of your system's-version of GHC.--### `libGMP` and `libFFI`--By default the stack configuration in `stack.yaml` will build with-support for `libGMP` and `libFFI`.  To turn this support off, the-option flags needs to be fully commented out.--There have been reports in the past over building Idris on Mac OS X,-using stack, and linking to a HomeBrew installation of `libFFI`. The-build has failed to find the correct `libFFI` installation. If you-encounter this then the fix is to augment the `PKG_CONFIG_PATH` for-`libFFI`. For example:--```-PKG_CONFIG_PATH=/usr/local/opt/libffi/lib/pkgconfig stack build-```--## Issue with GHC on Ubuntu/Fedora--There is an upstream issue with GHC on some Ubuntu and Fedora machines.-The issue is that for GHC versions greater than 8.4.X linking to libFFI is broken.-See the following GHC issue page for more information:--  <https://gitlab.haskell.org/ghc/ghc/issues/15397>--This means that an Idris built with `libFFI` support will fail at runtime as the executable would not be able to find the correct `libffi` shared object.-This will cause the build to fail.-Specifically, one will see an error message along the lines of:--> error while loading shared libraries: libffi.so.7: cannot open shared object file: No such file or directory--We have supplied an alternative stack configuration file (`stack-alt.yaml`) that will use a version of GHC prior to the upstream issue being introduced.
Makefile view
@@ -15,14 +15,14 @@ endif  install:-	$(CABAL) install $(CABALFLAGS)+	$(CABAL) v1-install $(CABALFLAGS)  pinstall: CABALFLAGS += --enable-executable-profiling pinstall: dist/setup-config-	$(CABAL) install $(CABALFLAGS)+	$(CABAL) v1-install $(CABALFLAGS)  build: dist/setup-config-	$(CABAL) build $(CABALFLAGS)+	$(CABAL) v1-build $(CABALFLAGS)  test: doc test_c stylize @@ -30,15 +30,15 @@ 	./stylize.sh  test_c:-	$(CABAL) test $(ARGS) --test-options \+	$(CABAL) v1-test $(ARGS) --test-options \ 		"$(TEST-ARGS) --rerun-update +RTS -N$(TEST-JOBS) -RTS"  test_js:-	$(CABAL) test $(ARGS) --test-options \+	$(CABAL) v1-test $(ARGS) --test-options \ 		"$(TEST-ARGS) --node --rerun-update +RTS -N$(TEST-JOBS) -RTS"  test_update:-	$(CABAL) test $(ARGS) --test-options \+	$(CABAL) v1-test $(ARGS) --test-options \ 		"$(TEST-ARGS) --accept +RTS -N$(TEST-JOBS) -RTS"  test_clean:@@ -49,14 +49,14 @@ 	$(MAKE) -C libs IDRIS=../../dist/build/idris/idris RTS=../../dist/build/rts/libidris_rts clean  relib: lib_clean-	$(CABAL) install $(CABALFLAGS)+	$(CABAL) v1-install $(CABALFLAGS)  linecount: 	wc -l src/Idris/*.hs src/Idris/Elab/*.hs src/Idris/Core/*.hs src/IRTS/*.hs src/Pkg/*.hs src/Util/*.hs  #Note: this doesn't yet link to Hackage properly doc: dist/setup-config-	$(CABAL) haddock --hyperlink-source --html --hoogle --html-location="http://hackage.haskell.org/packages/archive/\$$pkg/latest/doc/html" --haddock-options="--title Idris"+	$(CABAL) v1-haddock --hyperlink-source --html --hoogle --html-location="https://hackage.haskell.org/packages/archive/\$$pkg/latest/doc/html" --haddock-options="--title Idris"  lib_doc: 	$(MAKE) -C libs IDRIS=../../dist/build/idris/idris doc@@ -76,7 +76,7 @@ 	$(MAKE) -C docs latexpdf  fast:-	$(CABAL) install $(CABALFLAGS) --ghc-option=-O0+	$(CABAL) v1-install $(CABALFLAGS) --ghc-option=-O0  dist/setup-config:-	$(CABAL) configure $(CABALFLAGS)+	$(CABAL) v1-configure $(CABALFLAGS)
README.md view
@@ -4,11 +4,11 @@ [![Appveyor build](https://ci.appveyor.com/api/projects/status/xi8yu81oy1134g7o/branch/master?svg=true)](https://ci.appveyor.com/project/idrislang/idris-dev) [![Documentation Status](https://readthedocs.org/projects/idris/badge/?version=latest)](https://readthedocs.org/projects/idris/?badge=latest) [![Hackage](https://img.shields.io/hackage/v/idris.svg)](https://hackage.haskell.org/package/idris)-[![Stackage LTS](http://stackage.org/package/idris/badge/lts)](http://stackage.org/lts/package/idris)-[![Stackage Nightly](http://stackage.org/package/idris/badge/nightly)](http://stackage.org/nightly/package/idris)+[![Stackage LTS](https://stackage.org/package/idris/badge/lts)](https://stackage.org/lts/package/idris)+[![Stackage Nightly](https://stackage.org/package/idris/badge/nightly)](https://stackage.org/nightly/package/idris) [![IRC](https://img.shields.io/badge/IRC-%23idris-1e72ff.svg?style=flat)](https://www.irccloud.com/invite?channel=%23idris&hostname=irc.freenode.net&port=6697&ssl=1) -Idris (http://idris-lang.org/) is a general-purpose functional programming+Idris (https://idris-lang.org/) is a general-purpose functional programming language with dependent types.  ## Installation Guides.@@ -28,7 +28,7 @@ is a C code generator to compile executables, and a JavaScript code generator with support for node.js and browser JavaScript. -More information about [code generators can be found on the wiki](http://idris.readthedocs.io/en/latest/reference/codegen.html).+More information about [code generators can be found on the wiki](https://idris.readthedocs.io/en/latest/reference/codegen.html).  ## More Information @@ -44,3 +44,6 @@  For those interested in contributing to Idris directly we kindly ask that prospective developers please consult the [Contributing Guide](CONTRIBUTING.md) first.++[Idris 2](https://github.com/edwinb/Idris2) is an early preview of the next generation+of Idris, implemented in Idris.
Setup.hs view
@@ -215,36 +215,6 @@       autogenComponentModulesDir lbi _ = autogenModulesDir lbi #endif -idrisPreSDist args flags = do-  let dir = S.fromFlag (S.sDistDirectory flags)-  let verb = S.fromFlag (S.sDistVerbosity flags)-  generateVersionModule verb "src" True-  generateBuildFlagsModule verb "src" []-  generateTargetModule verb "src" "./libs"-  generateToolchainModule verb "src" Nothing-  preSDist simpleUserHooks args flags--idrisSDist sdist pkgDesc bi hooks flags = do-  pkgDesc' <- addGitFiles pkgDesc-  sdist pkgDesc' bi hooks flags-    where-      addGitFiles :: PackageDescription -> IO PackageDescription-      addGitFiles pkgDesc = do-        files <- gitFiles-        return $ pkgDesc { extraSrcFiles = extraSrcFiles pkgDesc ++ files}-      gitFiles :: IO [FilePath]-      gitFiles = liftM lines (readProcess "git" ["ls-files"] "")--idrisPostSDist args flags desc lbi = do-  Control.Exception.catch (do let file = "src" </> "Version_idris" Px.<.> "hs"-                              let targetFile = "src" </> "Target_idris" Px.<.> "hs"-                              putStrLn $ "Removing generated modules:\n "-                                        ++ file ++ "\n" ++ targetFile-                              removeFile file-                              removeFile targetFile)-             (\e -> let e' = (e :: SomeException) in return ())-  postSDist simpleUserHooks args flags desc lbi- #if !(MIN_VERSION_Cabal(2,0,0)) rewriteFileEx :: Verbosity -> FilePath -> String -> IO () rewriteFileEx _ = rewriteFile@@ -353,8 +323,5 @@    , postInst = \_ flags pkg local ->                   idrisInstall (S.fromFlag $ S.installVerbosity flags)                                NoCopyDest pkg local-   , preSDist = idrisPreSDist-   , sDistHook = idrisSDist (sDistHook simpleUserHooks)-   , postSDist = idrisPostSDist    , testHook = idrisTestHook    }
− appveyor.yml 
@@ -1,27 +0,0 @@-version: 1.0.{build}-init:-- ps: >--    choco install cabal --no-progress--    mkdir C:\ghc--    Invoke-WebRequest "http://downloads.haskell.org/~ghc/8.4.3/ghc-8.4.3-x86_64-unknown-mingw32.tar.xz" -OutFile C:\ghc\ghc.tar.xz -UserAgent "Curl"--    7z x C:\ghc\ghc.tar.xz -oC:\ghc--    7z x C:\ghc\ghc.tar -oC:\ghc--    $env:PATH="$env:PATH;c:\ghc\ghc-8.4.3\bin;$HOME\AppData\Roaming\cabal\bin"--    cabal v1-update--    $env:current_posix=c:\msys64\usr\bin\cygpath -u $(pwd)--environment:-  MSYSTEM: MINGW64-  MSYS2_PATH_TYPE: inherit-build_script:-- ps: >--    c:\msys64\usr\bin\bash -l -c "cd $env:current_posix && cabal v1-install -fffi --enable-tests 2>&1"-test_script:-- ps: c:\msys64\usr\bin\bash -l -c "cd $env:current_posix && make test_c 2>&1"
− azure-pipelines.yml 
@@ -1,143 +0,0 @@-# Starter pipeline-# Start with a minimal pipeline that you can customize to build and deploy your code.-# Add steps that build, run tests, deploy, and more:-# https://aka.ms/yaml-jobs:-  # Test a configuration with the oldest supported GHC-  - job: Linux_GHC_710-    pool:-      vmImage: 'Ubuntu 16.04'-    steps:-    - script: |-        sudo add-apt-repository ppa:hvr/ghc-        sudo apt-get update-        sudo apt-get install ghc-7.10.3 cabal-install-2.2-        sudo update-alternatives --config opt-ghc-        sudo update-alternatives --config opt-cabal-      displayName: 'Prepare system'-    - script: |-        export PATH=/opt/ghc/bin:$HOME/.cabal/bin:$PATH-        cabal update-        CABALFLAGS="-fffi -fci" make-      displayName: 'Build Idris'-    - script: |-        export PATH=/opt/ghc/bin:$HOME/.cabal/bin:$PATH-        make test_c-      displayName: 'Run tests'-  # Test on Linux-  - job: Linux-    pool:-      vmImage: 'Ubuntu 16.04'-    steps:-    - script: |-        sudo add-apt-repository ppa:hvr/ghc-        sudo apt-get update-        sudo apt-get install ghc-8.2.2 cabal-install-2.2-        sudo update-alternatives --config opt-ghc-        sudo update-alternatives --config opt-cabal-      displayName: 'Prepare system'-    - script: |-        export PATH=/opt/ghc/bin:$HOME/.cabal/bin:$PATH-        cabal update-        CABALFLAGS="-fffi -fci" make-      displayName: 'Build Idris'-    - script: |-        export PATH=/opt/ghc/bin:$HOME/.cabal/bin:$PATH-        make test_c-      displayName: 'Run tests'-  # Test on MacOS -  - job: macOS-    pool:-      vmImage: 'xcode9-macos10.13'-    steps:-    - script: |-        brew install ghc cabal-install libffi pkgconfig-        export PKG_CONFIG_PATH=/usr/local/opt/libffi/lib/pkgconfig:$PKG_CONFIG_PATH-        export PATH=$HOME/.cabal/bin:$PATH-        cabal update-        CABALFLAGS="-fffi -fci" make-        make test_c-      displayName: 'Build idris and run tests'-  # Test on Windows-  - job: Windows-    pool:-      vmImage: 'vs2017-win2016'-    steps:-    - powershell: |-        choco install cabal -y --no-progress-        choco install 7zip.portable -y --no-progress-        choco install msys2 -y --no-progress --params "/InstallDir=C:/msys64/"-        mkdir C:\ghc-        Invoke-WebRequest "http://downloads.haskell.org/~ghc/8.4.3/ghc-8.4.3-x86_64-unknown-mingw32.tar.xz" -OutFile C:\ghc\ghc.tar.xz -UserAgent "Curl"-        7z x C:\ghc\ghc.tar.xz -oC:\ghc-        7z x C:\ghc\ghc.tar -oC:\ghc-      displayName: "Setting up environment"-    - powershell: |-        cabal update-        $env:PATH="$env:PATH;$HOME\AppData\Roaming\cabal\bin;c:\ghc\ghc-8.4.3\bin"-        $env:current_posix=c:\msys64\usr\bin\cygpath -u $(pwd)-        c:\msys64\usr\bin\bash -l -c "echo `$MSYSTEM && echo `$PATH"-        c:\msys64\usr\bin\bash -l -c "pacman -S make mingw-w64-x86_64-gcc mingw-w64-x86_64-pkg-config mingw-w64-x86_64-libffi --noconfirm 2>&1"-        c:\msys64\usr\bin\bash -l -c "cd $env:current_posix && cabal install -fffi --enable-test 2>&1"-        c:\msys64\usr\bin\bash -l -c "cd $env:current_posix && make test_c 2>&1"-      env:-        MSYSTEM: MINGW64-        MSYS2_PATH_TYPE: inherit-      displayName: "Build and test Idris"-  # Check styling-  - job: Stylize-    pool:-      vmImage: 'Ubuntu 16.04'-    steps:-    - script: |-        sudo add-apt-repository ppa:hvr/ghc-        sudo apt-get update-        sudo apt-get install ghc-8.2.2 cabal-install-2.2-        sudo update-alternatives --config opt-ghc-        sudo update-alternatives --config opt-cabal-      displayName: 'Prepare system'-    - script: |-        export PATH=/opt/ghc/bin:$HOME/.cabal/bin:$PATH-        cabal update-        cabal install stylish-haskell-        ./stylize.sh-      displayName: 'Run stylish'-  # Run tests on the node backend-  - job: JS-    pool:-      vmImage: 'Ubuntu 16.04'-    steps:-    - script: |-        sudo add-apt-repository ppa:hvr/ghc-        sudo apt-get update-        sudo apt-get install ghc-8.2.2 cabal-install-2.2-        sudo update-alternatives --config opt-ghc-        sudo update-alternatives --config opt-cabal-      displayName: 'Prepare system'-    - script: |-        export PATH=/opt/ghc/bin:$HOME/.cabal/bin:$PATH-        cabal update-        CABALFLAGS="-fffi -fci" make-      displayName: 'Build Idris'-    - script: |-        export PATH=/opt/ghc/bin:$HOME/.cabal/bin:$PATH-        make test_js-      displayName: 'Run tests'-  # Build docs-  - job: Docs-    pool:-      vmImage: 'Ubuntu 16.04'-    steps:-    - script: |-        sudo add-apt-repository ppa:hvr/ghc-        sudo apt-get update-        sudo apt-get install ghc-8.2.2 cabal-install-2.2-        sudo update-alternatives --config opt-ghc-        sudo update-alternatives --config opt-cabal-      displayName: 'Prepare system'-    - script: |-        export PATH=/opt/ghc/bin:$HOME/.cabal/bin:$PATH-        cabal update-        CABALFLAGS="-fffi -fci" make-        make lib_doc doc-      displayName: 'Build Docs'
− benchmarks/ALL 
@@ -1,4 +0,0 @@-trivial/sortvec 2000-quasigroups/qgsolve board-fasta/fasta 1-pidigits/pidigits 3000
− benchmarks/README 
@@ -1,21 +0,0 @@-Benchmarks-------------To run:--$ ./build.pl   -- builds all benchmark binaries-$ ./run.pl     -- runs all benchmarks--Adding a test ----------------Add a line to the 'ALL' file of the following form:--dir/main   arg--where 'dir' is the directory the benchmark lives in, 'main' is the name of the-ipkg file and executable (these must be the same), 'arg' is the input to give-to the binary. --It is assumed that all benchmarks take exactly one argument, which helps to-ensure that they are not simply doing all the work at compile time.
benchmarks/pidigits/pidigits.idr view
@@ -3,7 +3,7 @@  {- Toy program that outputs the n first digits of Pi. -   Inspired from http://www.haskell.org/haskellwiki/Shootout/Pidigits.+   Inspired from https://www.haskell.org/haskellwiki/Shootout/Pidigits.    The original ns and str lazy lists have been replaced by strict functions.     Memory usage seems to be excessive. One of the branches of str is tail recursive, and
− docs/.gitignore 
@@ -1,3 +0,0 @@-*~-UnicodeData.txt-_build/
− docs/LICENSE 
@@ -1,10 +0,0 @@-#+TITLE: Licensing Information--The documentation for Idris has been published under the Creative-Commons CC0 License. As such to the extent possible under law, /The-Idris Community/ has waived all copyright and related or neighboring-rights to Documentation for Idris.--More information concerning the CC0 can be found online at:--    http://creativecommons.org/publicdomain/zero/1.0/
− docs/Makefile 
@@ -1,183 +0,0 @@-# Makefile for Sphinx documentation-#--# You can set these variables from the command line.-SPHINXOPTS    =-SPHINXBUILD   = sphinx-build-PAPER         =-BUILDDIR      = _build--# User-friendly check for sphinx-build-ifeq ($(shell which $(SPHINXBUILD) >/dev/null 2>&1; echo $$?), 1)-$(error The '$(SPHINXBUILD)' command was not found. Make sure you have Sphinx installed, then set the SPHINXBUILD environment variable to point to the full path of the '$(SPHINXBUILD)' executable. Alternatively you can add the directory with the executable to your PATH. If you don't have Sphinx installed, grab it from http://sphinx-doc.org/)-endif--# Internal variables.-PAPEROPT_a4     = -D latex_paper_size=a4-PAPEROPT_letter = -D latex_paper_size=letter-ALLSPHINXOPTS   = -d $(BUILDDIR)/doctrees $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) .-# the i18n builder cannot share the environment and doctrees with the others-I18NSPHINXOPTS  = $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) .--.PHONY: help clean html dirhtml singlehtml pickle json htmlhelp qthelp devhelp epub latex latexpdf text man changes linkcheck doctest coverage gettext--help:-	@echo "Please use \`make <target>' where <target> is one of"-	@echo "  html       to make standalone HTML files"-	@echo "  dirhtml    to make HTML files named index.html in directories"-	@echo "  singlehtml to make a single large HTML file"-	@echo "  pickle     to make pickle files"-	@echo "  json       to make JSON files"-	@echo "  htmlhelp   to make HTML files and a HTML help project"-	@echo "  qthelp     to make HTML files and a qthelp project"-	@echo "  devhelp    to make HTML files and a Devhelp project"-	@echo "  epub       to make an epub"-	@echo "  latex      to make LaTeX files, you can set PAPER=a4 or PAPER=letter"-	@echo "  latexpdf   to make LaTeX files and run them through pdflatex"-	@echo "  latexpdfja to make LaTeX files and run them through platex/dvipdfmx"-	@echo "  text       to make text files"-	@echo "  man        to make manual pages"-	@echo "  texinfo    to make Texinfo files"-	@echo "  info       to make Texinfo files and run them through makeinfo"-	@echo "  gettext    to make PO message catalogs"-	@echo "  changes    to make an overview of all changed/added/deprecated items"-	@echo "  xml        to make Docutils-native XML files"-	@echo "  pseudoxml  to make pseudoxml-XML files for display purposes"-	@echo "  linkcheck  to check all external links for integrity"-	@echo "  doctest    to run all doctests embedded in the documentation (if enabled)"-	@echo "  coverage   to run coverage check of the documentation (if enabled)"--clean:-	rm -rf $(BUILDDIR)/*--html:-	$(SPHINXBUILD) -b html $(ALLSPHINXOPTS) $(BUILDDIR)/html-	@echo-	@echo "Build finished. The HTML pages are in $(BUILDDIR)/html."--dirhtml:-	$(SPHINXBUILD) -b dirhtml $(ALLSPHINXOPTS) $(BUILDDIR)/dirhtml-	@echo-	@echo "Build finished. The HTML pages are in $(BUILDDIR)/dirhtml."--singlehtml:-	$(SPHINXBUILD) -b singlehtml $(ALLSPHINXOPTS) $(BUILDDIR)/singlehtml-	@echo-	@echo "Build finished. The HTML page is in $(BUILDDIR)/singlehtml."--pickle:-	$(SPHINXBUILD) -b pickle $(ALLSPHINXOPTS) $(BUILDDIR)/pickle-	@echo-	@echo "Build finished; now you can process the pickle files."--json:-	$(SPHINXBUILD) -b json $(ALLSPHINXOPTS) $(BUILDDIR)/json-	@echo-	@echo "Build finished; now you can process the JSON files."--htmlhelp:-	$(SPHINXBUILD) -b htmlhelp $(ALLSPHINXOPTS) $(BUILDDIR)/htmlhelp-	@echo-	@echo "Build finished; now you can run HTML Help Workshop with the" \-	      ".hhp project file in $(BUILDDIR)/htmlhelp."--qthelp:-	$(SPHINXBUILD) -b qthelp $(ALLSPHINXOPTS) $(BUILDDIR)/qthelp-	@echo-	@echo "Build finished; now you can run "qcollectiongenerator" with the" \-	      ".qhcp project file in $(BUILDDIR)/qthelp, like this:"-	@echo "# qcollectiongenerator $(BUILDDIR)/qthelp/IdrisManual.qhcp"-	@echo "To view the help file:"-	@echo "# assistant -collectionFile $(BUILDDIR)/qthelp/IdrisManual.qhc"--devhelp:-	$(SPHINXBUILD) -b devhelp $(ALLSPHINXOPTS) $(BUILDDIR)/devhelp-	@echo-	@echo "Build finished."-	@echo "To view the help file:"-	@echo "# mkdir -p $$HOME/.local/share/devhelp/IdrisManual"-	@echo "# ln -s $(BUILDDIR)/devhelp $$HOME/.local/share/devhelp/IdrisManual"-	@echo "# devhelp"--epub:-	$(SPHINXBUILD) -b epub $(ALLSPHINXOPTS) $(BUILDDIR)/epub-	@echo-	@echo "Build finished. The epub file is in $(BUILDDIR)/epub."--latex:-	$(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex-	@echo-	@echo "Build finished; the LaTeX files are in $(BUILDDIR)/latex."-	@echo "Run \`make' in that directory to run these through (pdf)latex" \-	      "(use \`make latexpdf' here to do that automatically)."--latexpdf:-	$(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex-	@echo "Running LaTeX files through pdflatex..."-	$(MAKE) -C $(BUILDDIR)/latex all-pdf-	@echo "pdflatex finished; the PDF files are in $(BUILDDIR)/latex."--latexpdfja:-	$(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex-	@echo "Running LaTeX files through platex and dvipdfmx..."-	$(MAKE) -C $(BUILDDIR)/latex all-pdf-ja-	@echo "pdflatex finished; the PDF files are in $(BUILDDIR)/latex."--text:-	$(SPHINXBUILD) -b text $(ALLSPHINXOPTS) $(BUILDDIR)/text-	@echo-	@echo "Build finished. The text files are in $(BUILDDIR)/text."--man:-	$(SPHINXBUILD) -b man $(ALLSPHINXOPTS) $(BUILDDIR)/man-	@echo-	@echo "Build finished. The manual pages are in $(BUILDDIR)/man."--texinfo:-	$(SPHINXBUILD) -b texinfo $(ALLSPHINXOPTS) $(BUILDDIR)/texinfo-	@echo-	@echo "Build finished. The Texinfo files are in $(BUILDDIR)/texinfo."-	@echo "Run \`make' in that directory to run these through makeinfo" \-	      "(use \`make info' here to do that automatically)."--info:-	$(SPHINXBUILD) -b texinfo $(ALLSPHINXOPTS) $(BUILDDIR)/texinfo-	@echo "Running Texinfo files through makeinfo..."-	make -C $(BUILDDIR)/texinfo info-	@echo "makeinfo finished; the Info files are in $(BUILDDIR)/texinfo."--gettext:-	$(SPHINXBUILD) -b gettext $(I18NSPHINXOPTS) $(BUILDDIR)/locale-	@echo-	@echo "Build finished. The message catalogs are in $(BUILDDIR)/locale."--changes:-	$(SPHINXBUILD) -b changes $(ALLSPHINXOPTS) $(BUILDDIR)/changes-	@echo-	@echo "The overview file is in $(BUILDDIR)/changes."--linkcheck:-	$(SPHINXBUILD) -b linkcheck $(ALLSPHINXOPTS) $(BUILDDIR)/linkcheck-	@echo-	@echo "Link check complete; look for any errors in the above output " \-	      "or in $(BUILDDIR)/linkcheck/output.txt."--doctest:-	$(SPHINXBUILD) -b doctest $(ALLSPHINXOPTS) $(BUILDDIR)/doctest-	@echo "Testing of doctests in the sources finished, look at the " \-	      "results in $(BUILDDIR)/doctest/output.txt."--coverage:-	$(SPHINXBUILD) -b coverage $(ALLSPHINXOPTS) $(BUILDDIR)/coverage-	@echo "Testing of coverage in the sources finished, look at the " \-	      "results in $(BUILDDIR)/coverage/python.txt."--xml:-	$(SPHINXBUILD) -b xml $(ALLSPHINXOPTS) $(BUILDDIR)/xml-	@echo-	@echo "Build finished. The XML files are in $(BUILDDIR)/xml."--pseudoxml:-	$(SPHINXBUILD) -b pseudoxml $(ALLSPHINXOPTS) $(BUILDDIR)/pseudoxml-	@echo-	@echo "Build finished. The pseudo-XML files are in $(BUILDDIR)/pseudoxml."
− docs/README.md 
@@ -1,51 +0,0 @@-# Documentation for the Idris Language.---This manual has been prepared using ReStructured Text and the [Sphinx Documentation Generator](http://sphinx-doc.org) for future inclusion on [Read The Docs](http://www.readthedocs.org).--## Dependencies--To build the manual the following dependencies must be met. We assume that you have standard build automation tools already install i.e. `make`.--### Sphinx-Doc--Python should be installed by default on most systems.-Sphinx can be installed either through your hosts package manager or using pip/easy_install.--*Note* [ReadTheDocs](http://www.readthedocs.org) works with Sphinx- `v1.2.2`. If you install a more recent version of sphinx then- 'incorrectly' marked up documentation may get passed the build system- of readthedocs and be ignored. In the past we had several code-blocks- disappear because of that.--The ReadTheDocs theme can be installed using pip as follows:--```sh-pip install sphinx_rtd_theme-```--### LaTeX--LaTeX can be install either using your systems package manager or direct from TeXLive.---## Build Instructions--```sh-make html-make latexpdf-```--## Contributing--The documentation for Idris has been published under the Creative-Commons CC0 License. As such to the extent possible under law, /The-Idris Community/ has waived all copyright and related or neighboring-rights to Documentation for Idris.--More information concerning the CC0 can be found online at:--    http://creativecommons.org/publicdomain/zero/1.0/---When contributing material to the manual please bear in mind that the work will be licensed as above.
− docs/conf.py 
@@ -1,430 +0,0 @@-# -*- coding: utf-8 -*--#-# Idris Manual documentation build configuration file, created by-# sphinx-quickstart on Sat Feb 28 20:41:47 2015.-#-# This file is execfile()d with the current directory set to its-# containing dir.-#-# Note that not all possible configuration values are present in this-# autogenerated file.-#-# All configuration values have a default; values that are commented out-# serve to show the default.--import sys-import os--# True if the readthedocs theme is locally installed-on_rtd = os.environ.get('READTHEDOCS', None) == 'True'--# If extensions (or modules to document with autodoc) are in another directory,-# add these directories to sys.path here. If the directory is relative to the-# documentation root, use os.path.abspath to make it absolute, like shown here.-#sys.path.insert(0, os.path.abspath('.'))--# -- General configuration --------------------------------------------------# If your documentation needs a minimal Sphinx version, state it here.-#needs_sphinx = '1.0'--# Add any Sphinx extension module names here, as strings. They can be-# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom-# ones.-extensions = [-    'sphinx.ext.todo',-#    'sphinx.ext.pngmath', # imgmath is not supported on readthedocs.-    'sphinx.ext.ifconfig',-]--# Add any paths that contain templates here, relative to this directory.-templates_path = ['_templates']--# The suffix of source filenames.-source_suffix = '.rst'--# The encoding of source files.-#source_encoding = 'utf-8-sig'--# The master toctree document.-master_doc = 'index'--# General information about the project.-project = u'Idris'-copyright = u'2017, The Idris Community'-author = u'The Idris Community'--# The version info for the project you're documenting, acts as replacement for-# |version| and |release|, also used in various other places throughout the-# built documents.-#-# The short X.Y version.-version = '1.3'-# The full version, including alpha/beta/rc tags.-release = '1.3.2'--# The language for content autogenerated by Sphinx. Refer to documentation-# for a list of supported languages.-#-# This is also used if you do content translation via gettext catalogs.-# Usually you set "language" from the command line for these cases.-language = None--# There are two options for replacing |today|: either, you set today to some-# non-false value, then it is used:-#today = ''-# Else, today_fmt is used as the format for a strftime call.-#today_fmt = '%B %d, %Y'--# List of patterns, relative to source directory, that match files and-# directories to ignore when looking for source files.-exclude_patterns = ['_build']--# The reST default role (used for this markup: `text`) to use for all-# documents.-#default_role = None--# If true, '()' will be appended to :func: etc. cross-reference text.-#add_function_parentheses = True--# If true, the current module name will be prepended to all description-# unit titles (such as .. function::).-#add_module_names = True--# If true, sectionauthor and moduleauthor directives will be shown in the-# output. They are ignored by default.-#show_authors = False--# The name of the Pygments (syntax highlighting) style to use.-pygments_style = 'sphinx'--# A list of ignored prefixes for module index sorting.-#modindex_common_prefix = []--# If true, keep warnings as "system message" paragraphs in the built documents.-#keep_warnings = False--# If true, `todo` and `todoList` produce output, else they produce nothing.-todo_include_todos = True---# -- Options for HTML output ------------------------------------------------# The theme to use for HTML and HTML Help pages.  See the documentation for-# a list of builtin themes.-html_theme = "default"--if not on_rtd:  # only import and set the theme if we're building docs locally-    try:-        import sphinx_rtd_theme-        html_theme = 'sphinx_rtd_theme'-        html_theme_path = [sphinx_rtd_theme.get_html_theme_path()]-    except ImportError:-        html_theme = "default"--# Theme options are theme-specific and customize the look and feel of a theme-# further.  For a list of options available for each theme, see the-# documentation.-#html_theme_options = {}--# Add any paths that contain custom themes here, relative to this directory.-#html_theme_path = []--# The name for this set of Sphinx documents.  If None, it defaults to-# "<project> v<release> documentation".-#html_title = None--# A shorter title for the navigation bar.  Default is the same as html_title.-#html_short_title = None--# The name of an image file (relative to this directory) to place at the top-# of the sidebar.-#html_logo = None--# The name of an image file (within the static path) to use as favicon of the-# docs.  This file should be a Windows icon file (.ico) being 16x16 or 32x32-# pixels large.-#html_favicon = None--# Add any paths that contain custom static files (such as style sheets) here,-# relative to this directory. They are copied after the builtin static files,-# so a file named "default.css" will overwrite the builtin "default.css".-html_static_path = ['_static']--# Add any extra paths that contain custom files (such as robots.txt or-# .htaccess) here, relative to this directory. These files are copied-# directly to the root of the documentation.-#html_extra_path = []--# If not '', a 'Last updated on:' timestamp is inserted at every page bottom,-# using the given strftime format.-#html_last_updated_fmt = '%b %d, %Y'--# If true, SmartyPants will be used to convert quotes and dashes to-# typographically correct entities.-#html_use_smartypants = True--# Custom sidebar templates, maps document names to template names.-#html_sidebars = {}--# Additional templates that should be rendered to pages, maps page names to-# template names.-#html_additional_pages = {}--# If false, no module index is generated.-#html_domain_indices = True--# If false, no index is generated.-#html_use_index = True--# If true, the index is split into individual pages for each letter.-#html_split_index = False--# If true, links to the reST sources are added to the pages.-#html_show_sourcelink = True--# If true, "Created using Sphinx" is shown in the HTML footer. Default is True.-#html_show_sphinx = True--# If true, "(C) Copyright ..." is shown in the HTML footer. Default is True.-#html_show_copyright = True--# If true, an OpenSearch description file will be output, and all pages will-# contain a <link> tag referring to it.  The value of this option must be the-# base URL from which the finished HTML is served.-#html_use_opensearch = ''--# This is the file name suffix for HTML files (e.g. ".xhtml").-#html_file_suffix = None--# Language to be used for generating the HTML full-text search index.-# Sphinx supports the following languages:-#   'da', 'de', 'en', 'es', 'fi', 'fr', 'hu', 'it', 'ja'-#   'nl', 'no', 'pt', 'ro', 'ru', 'sv', 'tr'-#html_search_language = 'en'--# A dictionary with options for the search language support, empty by default.-# Now only 'ja' uses this config value-#html_search_options = {'type': 'default'}--# The name of a javascript file (relative to the configuration directory) that-# implements a search results scorer. If empty, the default will be used.-#html_search_scorer = 'scorer.js'--# Output file base name for HTML help builder.-htmlhelp_basename = 'IdrisManualdoc'--# -- Options for LaTeX output -----------------------------------------------latex_title_page = r'''-\begin{titlepage}-    \vspace*{\fill}-    \begin{center}-        \includegraphics[width=0.25\textwidth]{idris-512x512.png}\par-        \vspace{1cm}-        {\huge\sffamily\bfseries \makeatletter\@title\makeatother\par}-        \vspace{1cm}-        {\Large Version \version\par}-    \end{center}-    \vspace*{\fill}-\end{titlepage}-'''--latex_elements = {-# The paper size ('letterpaper' or 'a4paper').-'papersize': 'a4paper',--'fontpkg': '',-'inputenc': '',-'utf8extra': '',-'releasename': 'Version',--# The font size ('10pt', '11pt' or '12pt').-'pointsize': '10pt',--# Additional stuff for the LaTeX preamble.-'preamble': r'''-\usepackage{lmodern}-\usepackage[T1]{fontenc}-\usepackage[utf8x]{inputenc}-\usepackage{titlesec}-%-\usepackage{fancyhdr}-\fancypagestyle{plain}{%-  \renewcommand{\headrulewidth}{0pt}%-  \fancyhf{}%-  \fancyfoot[C]{\textsf{\thepage}}-}-\pagestyle{fancy}-\fancyhf{}-\fancyhead[LE,RO]{\textsf{\bfseries{v\version}}}-\fancyhead[LO,RE]{\textsf{\bfseries\leftmark}}-%\fancyhead[LO]{\textsf{\bfseries{\leftmark}}}-%\fancyhead[RO]{\textsf{\bfseries{v\version}}}-%\fancyhead[RE]{\textsf{\bfseries{\leftmark}}}-%\fancyhead[LE]{\textsf{\bfseries{v\version}}}-\fancyfoot[C]{\textsf{\thepage}}-\renewcommand{\footrulewidth}{0pt}-\renewcommand{\headrulewidth}{0pt}-%-\usepackage[font={small,it}]{caption}-\titleformat{\section}-  {\normalfont\sffamily\Large\bfseries\color{black}}-  {\thesection}{1em}{}-\titleformat{\subsection}-  {\sffamily\large\bfseries\color{black}}-  {\thesubsection}{1em}{}-\titleformat{\subsubsection}-  {\sffamily\normalsize\bfseries\color{black}}-  {\thesubsubsection}{1em}{}-\titleformat{\paragraph}{\normalfont\normalsize\slshape}{\theparagraph}{1em}{}-\setlength{\parskip}{1em}-%-\hypersetup{colorlinks = false}-\definecolor{VerbatimBorderColor}{rgb}{1,1,1}-''',--'maketitle': latex_title_page,-'tableofcontents': "\\tableofcontents"-# Latex figure (float) alignment-#'figure_align': 'htbp',-}--# Grouping the document tree into LaTeX files. List of tuples-# (source start file, target name, title,-#  author, documentclass [howto, manual, or own class]).-latex_documents = [-  ('index',  'idris-documentation-complete.tex',  u'Documentation for the Idris Language',    u'The Idris Community', 'report'),-   ('tutorial/index',  'idris-tutorial.tex',  u'The Idris Tutorial',    u'The Idris Community', 'howto'),-]---latex_show_pagerefs = True-latex_show_url = 'footnote'--# The name of an image file (relative to this directory) to place at the top of-# the title page.-latex_logo = '../icons/idris-512x512.png'--# For "manual" documents, if this is true, then toplevel headings are parts,-# not chapters.-#latex_use_parts = True--# If true, show page references after internal links.-#latex_show_pagerefs = False--# If true, show URL addresses after external links.-#latex_show_urls = False--# Documents to append as an appendix to all manuals.-#latex_appendices = []--# If false, no module index is generated.-#latex_domain_indices = True---# -- Options for manual page output -----------------------------------------# One entry per manual page. List of tuples-# (source start file, name, description, authors, manual section).-man_pages = [-    (master_doc, 'idrismanual', u'Idris Manual Documentation',-     [author], 1)-]--# If true, show URL addresses after external links.-#man_show_urls = False---# -- Options for Texinfo output ---------------------------------------------# Grouping the document tree into Texinfo files. List of tuples-# (source start file, target name, title, author,-#  dir menu entry, description, category)-texinfo_documents = [-  (master_doc, 'IdrisManual', u'Idris Manual Documentation',-   author, 'IdrisManual', 'One line description of project.',-   'Miscellaneous'),-]--# Documents to append as an appendix to all manuals.-#texinfo_appendices = []--# If false, no module index is generated.-#texinfo_domain_indices = True--# How to display URL addresses: 'footnote', 'no', or 'inline'.-#texinfo_show_urls = 'footnote'--# If true, do not generate a @detailmenu in the "Top" node's menu.-#texinfo_no_detailmenu = False---# -- Options for Epub output ------------------------------------------------# Bibliographic Dublin Core info.-epub_title = project-epub_author = author-epub_publisher = author-epub_copyright = copyright--# The basename for the epub file. It defaults to the project name.-#epub_basename = project--# The HTML theme for the epub output. Since the default themes are not optimized-# for small screen space, using the same theme for HTML and epub output is-# usually not wise. This defaults to 'epub', a theme designed to save visual-# space.-#epub_theme = 'epub'--# The language of the text. It defaults to the language option-# or 'en' if the language is not set.-#epub_language = ''--# The scheme of the identifier. Typical schemes are ISBN or URL.-#epub_scheme = ''--# The unique identifier of the text. This can be a ISBN number-# or the project homepage.-#epub_identifier = ''--# A unique identification for the text.-#epub_uid = ''--# A tuple containing the cover image and cover page html template filenames.-#epub_cover = ()--# A sequence of (type, uri, title) tuples for the guide element of content.opf.-#epub_guide = ()--# HTML files that should be inserted before the pages created by sphinx.-# The format is a list of tuples containing the path and title.-#epub_pre_files = []--# HTML files shat should be inserted after the pages created by sphinx.-# The format is a list of tuples containing the path and title.-#epub_post_files = []--# A list of files that should not be packed into the epub file.-epub_exclude_files = ['search.html']--# The depth of the table of contents in toc.ncx.-#epub_tocdepth = 3--# Allow duplicate toc entries.-#epub_tocdup = True--# Choose between 'default' and 'includehidden'.-#epub_tocscope = 'default'--# Fix unsupported image types using the Pillow.-#epub_fix_images = False--# Scale large images.-#epub_max_image_width = 0--# How to display URL addresses: 'footnote', 'no', or 'inline'.-#epub_show_urls = 'inline'--# If false, no index is generated.-#epub_use_index = True
− docs/effects/conclusions.rst 
@@ -1,76 +0,0 @@-.. _sect-further:--***************-Further Reading-***************--This tutorial has given an introduction to writing and reasoning about-side-effecting programs in Idris, using the ``Effects`` library.-More details about the *implementation* of the library, such as how-``run`` works, how handlers are invoked, etc, are given in a separate-paper [1]_.--Some libraries and programs which use ``Effects`` can be found in the-following places:---  https://github.com/edwinb/SDL-idris — some bindings for the SDL media-   library, supporting graphics in particular.---  https://github.com/edwinb/idris-demos — various demonstration-   programs, including several examples from this tutorial, and a “Space-   Invaders” game.---  https://github.com/SimonJF/IdrisNet2 — networking and socket-   libraries.---  https://github.com/edwinb/Protocols — a high level communication-   protocol description language.--The inspiration for the ``Effects`` library was Bauer and Pretnar’s-Eff language [2]_, which describes a language based on algebraic-effects and handlers.  Other recent languages and libraries have also-been built on this ideas, for example [3]_ and [4]_. The theoretical-foundations are also well-studied see [5]_, [6]_, [7]_, [8]_.----.. [1] Edwin Brady. 2013. Programming and reasoning with algebraic-       effects and dependent types. SIGPLAN Not. 48, 9 (September-       2013), 133-144. DOI=10.1145/2544174.2500581-       https://dl.acm.org/citation.cfm?doid=2544174.2500581--.. [2] Andrej Bauer, Matija Pretnar, Programming with algebraic-       effects and handlers, Journal of Logical and Algebraic Methods-       in Programming, Volume 84, Issue 1, January 2015, Pages-       108-123, ISSN 2352-2208,-       http://math.andrej.com/wp-content/uploads/2012/03/eff.pdf---.. [3] Ben Lippmeier. 2009. Witnessing Purity, Constancy and-       Mutability. In Proceedings of the 7th Asian Symposium on-       Programming Languages and Systems (APLAS '09), Zhenjiang Hu-       (Ed.). Springer-Verlag, Berlin, Heidelberg,-       95-110. DOI=10.1007/978-3-642-10672-9_9-       http://link.springer.com/chapter/10.1007%2F978-3-642-10672-9_9---.. [4] Ohad Kammar, Sam Lindley, and Nicolas Oury. 2013. Handlers in-       action. SIGPLAN Not. 48, 9 (September 2013),-       145-158. DOI=10.1145/2544174.2500590-       https://dl.acm.org/citation.cfm?doid=2544174.2500590--.. [5] Martin Hyland, Gordon Plotkin, John Power, Combining effects:-       Sum and tensor, Theoretical Computer Science, Volume 357,-       Issues 1–3, 25 July 2006, Pages 70-99, ISSN 0304-3975,-       (https://www.sciencedirect.com/science/article/pii/S0304397506002659)--.. [6] Paul Blain Levy. 2004. Call-By-Push-Value: A-       Functional/Imperative Synthesis (Semantics Structures in-       Computation, V. 2). Kluwer Academic Publishers, Norwell, MA,-       USA.--.. [7] Plotkin, Gordon, and Matija Pretnar. "Handlers of algebraic-       effects." Programming Languages and Systems. Springer Berlin-       Heidelberg, 2009. 80-94.--.. [8] Pretnar, Matija. "Logic and handling of algebraic effects." (2010).
− docs/effects/depeff.rst 
@@ -1,333 +0,0 @@-.. _sect-depeff:--*****************-Dependent Effects-*****************--In the programs we have seen so far, the available effects have remained-constant. Sometimes, however, an operation can *change* the available-effects. The simplest example occurs when we have a state with a-dependent type—adding an element to a vector also changes its type, for-example, since its length is explicit in the type. In this section, we-will see how the library supports this. Firstly, we will see how states-with dependent types can be implemented. Secondly, we will see how the-effects can depend on the *result* of an effectful operation. Finally,-we will see how this can be used to implement a type-safe and-resource-safe protocol for file management.--Dependent States-================--Suppose we have a function which reads input from the console, converts-it to an integer, and adds it to a list which is stored in a ``STATE``.-It might look something like the following:--.. code-block:: idris--    readInt : Eff () [STATE (List Int), STDIO] -    readInt = do let x = trim !getStr-                 put (cast x :: !get)--But what if, instead of a list of integers, we would like to store a-``Vect``, maintaining the length in the type?--.. code-block:: idris--    readInt : Eff () [STATE (Vect n Int), STDIO]-    readInt = do let x = trim !getStr-                 put (cast x :: !get)--This will not type check! Although the vector has length ``n`` on entry-to ``readInt``, it has length ``S n`` on exit. The library allows us to-express this as follows:--.. code-block:: idris--    readInt : Eff ()[STATE (Vect n Int), STDIO] -                    [STATE (Vect (S n) Int), STDIO]-    readInt = do let x = trim !getStr-                 putM (cast x :: !get)--The type ``Eff a xs xs'`` means that the operation-begins with effects ``xs`` available, and ends with effects ``xs’``-available. We have used ``putM`` to update the state, where the ``M``-suffix indicates that the *type* is being updated as well as the value.-It has the following type:--.. code-block:: idris--    putM : y -> Eff () [STATE x] [STATE y]--Result-dependent Effects-========================--Often, whether a state is updated could depend on the success or-otherwise of an operation. In our ``readInt`` example, we might wish to-update the vector only if the input is a valid integer (i.e. all-digits). As a first attempt, we could try the following, returning a-``Bool`` which indicates success:--.. code-block:: idris--    readInt : Eff Bool [STATE (Vect n Int), STDIO]-                       [STATE (Vect (S n) Int), STDIO]-    readInt = do let x = trim !getStr-                 case all isDigit (unpack x) of-                      False => pure False-                      True => do putM (cast x :: !get)-                                 pure True--Unfortunately, this will not type check because the vector does not get-extended in both branches of the ``case``!--::--    MutState.idr:18:19:When elaborating right hand side of Main.case-    block in readInt:-    Unifying n and S n would lead to infinite value--Clearly, the size of the resulting vector depends on whether or not the-value read from the user was valid. We can express this in the type:--.. code-block:: idris--    readInt : Eff Bool [STATE (Vect n Int), STDIO]-                (\ok => if ok then [STATE (Vect (S n) Int), STDIO]-                              else [STATE (Vect n Int), STDIO])-    readInt = do let x = trim !getStr-                 case all isDigit (unpack x) of-                      False => pureM False-                      True => do putM (cast x :: !get)-                                 pureM True--Using ``pureM`` rather than ``pure`` allows the output effects to be-calculated from the value given. Its type is:--.. code-block:: idris--    pureM : (val : a) -> EffM m a (xs val) xs--When using ``readInt``, we will have to check its return-value in order to know what the new set of effects is. For example, to-read a set number of values into a vector, we could write the following:--.. code-block:: idris--    readN : (n : Nat) ->-            Eff () [STATE (Vect m Int), STDIO]-                   [STATE (Vect (n + m) Int), STDIO]-    readN Z = pure ()-    readN {m} (S k) = case !readInt of-                          True => rewrite plusSuccRightSucc k m in readN k-                          False => readN (S k)--The ``case`` analysis on the result of ``readInt`` means that we know in-each branch whether reading the integer succeeded, and therefore how-many values still need to be read into the vector. What this means in-practice is that the type system has verified that a necessary dynamic-check (i.e. whether reading a value succeeded) has indeed been done.--.. note::-    Only ``case`` will work here. We cannot use ``if/then/else``-    because the ``then`` and ``else`` branches must have the same-    type. The ``case`` construct, however, abstracts over the value-    being inspected in the type of each branch.--File Management-===============--A practical use for dependent effects is in specifying resource usage-protocols and verifying that they are executed correctly. For example,-file management follows a resource usage protocol with the following-(informally specified) requirements:---  It is necessary to open a file for reading before reading it---  Opening may fail, so the programmer should check whether opening was-   successful---  A file which is open for reading must not be written to, and vice-   versa---  When finished, an open file handle should be closed---  When a file is closed, its handle should no longer be used--These requirements can be expressed formally in , by creating a-``FILE_IO`` effect parameterised over a file handle state, which is-either empty, open for reading, or open for writing. The ``FILE_IO``-effect’s definition is given below. Note that this-effect is mainly for illustrative purposes—typically we would also like-to support random access files and better reporting of error conditions.--.. code-block:: idris--    module Effect.File--    import Effects-    import Control.IOExcept--    FILE_IO : Type -> EFFECT--    data OpenFile : Mode -> Type--    open : (fname : String)-           -> (m : Mode)-           -> Eff Bool [FILE_IO ()] -                       (\res => [FILE_IO (case res of-                                               True => OpenFile m-                                               False => ())])-    close : Eff () [FILE_IO (OpenFile m)] [FILE_IO ()]--    readLine  : Eff String [FILE_IO (OpenFile Read)]-    writeLine : String -> Eff () [FILE_IO (OpenFile Write)]-    eof       : Eff Bool [FILE_IO (OpenFile Read)]--    Handler FileIO IO where { ... }--In particular, consider the type of ``open``:--.. code-block:: idris--    open : (fname : String)-           -> (m : Mode)-           -> Eff Bool [FILE_IO ()] -                       (\res => [FILE_IO (case res of-                                               True => OpenFile m-                                               False => ())])--This returns a ``Bool`` which indicates whether opening the file was-successful. The resulting state depends on whether the operation was-successful; if so, we have a file handle open for the stated purpose,-and if not, we have no file handle. By ``case`` analysis on the result,-we continue the protocol accordingly.--.. _eff-readfile:-.. code-block:: idris--    readFile : Eff (List String) [FILE_IO (OpenFile Read)]-    readFile = readAcc [] where-        readAcc : List String -> Eff (List String) [FILE_IO (OpenFile Read)] -        readAcc acc = if (not !eof)-                         then readAcc (!readLine :: acc)-                         else pure (reverse acc)--Given a function ``readFile``, above, which reads from-an open file until reaching the end, we can write a program which opens-a file, reads it, then displays the contents and closes it, as follows,-correctly following the protocol:--.. code-block:: idris--    dumpFile : String -> Eff () [FILE_IO (), STDIO]-    dumpFile name = case !(open name Read) of-                        True => do putStrLn (show !readFile)-                                   close-                        False => putStrLn ("Error!")--The type of ``dumpFile``, with ``FILE_IO ()`` in its effect list,-indicates that any use of the file resource will follow the protocol-correctly (i.e. it both begins and ends with an empty resource). If we-fail to follow the protocol correctly (perhaps by forgetting to close-the file, failing to check that ``open`` succeeded, or opening the file-for writing) then we will get a compile-time error. For example,-changing ``open name Read`` to ``open name Write`` yields a compile-time-error of the following form:--::--    FileTest.idr:16:18:When elaborating right hand side of Main.case-    block in testFile:-    Can't solve goal-            SubList [(FILE_IO (OpenFile Read))]-                    [(FILE_IO (OpenFile Write)), STDIO]--In other words: when reading a file, we need a file which is open for-reading, but the effect list contains a ``FILE_IO`` effect carrying a-file open for writing.--Pattern-matching bind-=====================--It might seem that having to test each potentially failing operation-with a ``case`` clause could lead to ugly code, with lots of-nested case blocks. Many languages support exceptions to improve this,-but unfortunately exceptions may not allow completely clean resource-management—for example, guaranteeing that any ``open`` which did succeed-has a corresponding close.--Idris supports *pattern-matching* bindings, such as the following:--.. code-block:: idris--    dumpFile : String -> Eff () [FILE_IO (), STDIO]-    dumpFile name = do True <- open name Read-                       putStrLn (show !readFile)-                       close--This also has a problem: we are no longer dealing with the case where-opening a file failed! The solution is to extend the pattern-matching-binding syntax to give brief clauses for failing matches. Here, for-example, we could write:--.. code-block:: idris--    dumpFile : String -> Eff () [FILE_IO (), STDIO]-    dumpFile name  = do True <- open name Read | False => putStrLn "Error"-                        putStrLn (show !readFile)-                        close--This is exactly equivalent to the definition with the explicit ``case``.-In general, in a ``do``-block, the syntax:--.. code-block:: idris--    do pat <- val | <alternatives>-       p--is desugared to--.. code-block:: idris--    do x <- val-       case x of-            pat => p-            <alternatives>--There can be several ``alternatives``, separated by a vertical bar-``|``. For example, there is a ``SYSTEM`` effect which supports-reading command line arguments, among other things (see Appendix-:ref:`sect-appendix`). To read command line arguments, we can use-``getArgs``:--.. code-block:: idris--    getArgs : Eff (List String) [SYSTEM]--A main program can read command line arguments as follows, where in the-list which is returned, the first element ``prog`` is the executable-name and the second is an expected argument:--.. code-block:: idris--    emain : Eff () [SYSTEM, STDIO]-    emain = do [prog, arg] <- getArgs-               putStrLn $ "Argument is " ++ arg-               {- ... rest of function ... -}--Unfortunately, this will not fail gracefully if no argument is given, or-if too many arguments are given. We can use pattern matching bind-alternatives to give a better (more informative) error:--.. code-block:: idris--    emain : Eff () [SYSTEM, STDIO]-    emain = do [prog, arg] <- getArgs | [] => putStrLn "Can't happen!"-                                      | [prog] => putStrLn "No arguments!"-                                      | _ => putStrLn "Too many arguments!"-               putStrLn $ "Argument is " ++ arg-               {- ... rest of function ... -}--If ``getArgs`` does not return something of the form ``[prog, arg]`` the-alternative which does match is executed instead, and that value-returned.
− docs/effects/hangman.rst 
@@ -1,329 +0,0 @@-.. _sect-hangman:--***************************************-Example: A “Mystery Word” Guessing Game-***************************************--In this section, we will use the techniques and specific effects-discussed in the tutorial so far to implement a larger example, a simple-text-based word-guessing game. In the game, the computer chooses a word,-which the player must guess letter by letter. After a limited number of-wrong guesses, the player loses [1]_.--We will implement the game by following these steps:--#. Define the game state, in enough detail to express the rules--#. Define the rules of the game (i.e. what actions the player may take,-   and how these actions affect the game state)--#. Implement the rules of the game (i.e. implement state updates for-   each action)--#. Implement a user interface which allows a player to direct actions--Step 2 may be achieved by defining an effect which depends on the state-defined in step 1. Then step 3 involves implementing a ``Handler`` for-this effect. Finally, step 4 involves implementing a program in ``Eff``-using the newly defined effect (and any others required to implement the-interface).--Step 1: Game State-==================--First, we categorise the game states as running games (where there are a-number of guesses available, and a number of letters still to guess), or-non-running games (i.e. games which have not been started, or games-which have been won or lost).--.. code-block:: idris--    data GState = Running Nat Nat | NotRunning--Notice that at this stage, we say nothing about what it means to make a-guess, what the word to be guessed is, how to guess letters, or any-other implementation detail. We are only interested in what is necessary-to describe the game rules.--We will, however, parameterise a concrete game state ``Mystery`` over-this data:--.. code-block:: idris--    data Mystery : GState -> Type--Step 2: Game Rules-==================--We describe the game rules as a dependent effect, where each action has-a *precondition* (i.e. what the game state must be before carrying out-the action) and a *postcondition* (i.e. how the action affects the game-state). Informally, these actions with the pre- and postconditions are:--Guess-    Guess a letter in the word.--    -  Precondition: The game must be running, and there must be both-       guesses still available, and letters still to be guessed.--    -  Postcondition: If the guessed letter is in the word and not yet-       guessed, reduce the number of letters, otherwise reduce the-       number of guesses.--Won-    Declare victory--    -  Precondition: The game must be running, and there must be no-       letters still to be guessed.--    -  Postcondition: The game is no longer running.--Lost-    Accept defeat--    -  Precondition: The game must be running, and there must be no-       guesses left.--    -  Postcondition: The game is no longer running.--NewWord-    Set a new word to be guessed--    -  Precondition: The game must not be running.--    -  Postcondition: The game is running, with 6 guesses available (the-       choice of 6 is somewhat arbitrary here) and the number of unique-       letters in the word still to be guessed.--Get-    Get a string representation of the game state. This is for display-    purposes; there are no pre- or postconditions.--We can make these rules precise by declaring them more formally in an-effect signature:--.. code-block:: idris--    data MysteryRules : Effect where-         Guess : (x : Char) ->-                 sig MysteryRules Bool-                     (Mystery (Running (S g) (S w)))-                     (\inword => if inword-                                 then Mystery (Running (S g) w)-                                 else Mystery (Running g (S w)))-         Won  : sig MysteryRules () (Mystery (Running g 0))-                                    (Mystery NotRunning)-         Lost : sig MysteryRules () (Mystery (Running 0 g))-                                    (Mystery NotRunning)-         NewWord : (w : String) -> -                   sig MysteryRules () (Mystery NotRunning) (Mystery (Running 6 (length (letters w))))-         Get : sig MysteryRules String (Mystery h)--This description says nothing about how the rules are implemented. In-particular, it does not specify *how* to tell whether a guessed letter-was in a word, just that the result of ``Guess`` depends on it.--Nevertheless, we can still create an ``EFFECT`` from this, and use it in-an ``Eff`` program. Implementing a ``Handler`` for ``MysteryRules`` will-then allow us to play the game.--.. code-block:: idris--    MYSTERY : GState -> EFFECT-    MYSTERY h = MkEff (Mystery h) MysteryRules--Step 3: Implement Rules-=======================--To *implement* the rules, we begin by giving a concrete definition of-game state:--.. code-block:: idris--    data Mystery : GState -> Type where-         Init     : Mystery NotRunning-         GameWon  : (word : String) -> Mystery NotRunning-         GameLost : (word : String) -> Mystery NotRunning-         MkG      : (word : String) ->-                    (guesses : Nat) ->-                    (got : List Char) ->-                    (missing : Vect m Char) ->-                    Mystery (Running guesses m)--If a game is ``NotRunning``, that is either because it has not yet-started (``Init``) or because it is won or lost (``GameWon`` and-``GameLost``, each of which carry the word so that showing the game-state will reveal the word to the player). Finally, ``MkG`` captures a-running game’s state, including the target word, the letters-successfully guessed, and the missing letters. Using a ``Vect`` for the-missing letters is convenient since its length is used in the type.--To initialise the state, we implement the following functions:-``letters``, which returns a list of unique letters in a ``String``-(ignoring spaces) and ``initState`` which sets up an initial state-considered valid as a postcondition for ``NewWord``.--.. code-block:: idris--    letters : String -> List Char-    initState : (x : String) -> Mystery (Running 6 (length (letters x)))--When checking if a guess is in the vector of missing letters, it is-convenient to return a *proof* that the guess is in the vector, using-``isElem`` below, rather than merely a ``Bool``:--.. code-block:: idris--    data IsElem : a -> Vect n a -> Type where-         First : IsElem x (x :: xs)-         Later : IsElem x xs -> IsElem x (y :: xs)--    isElem : DecEq a => (x : a) -> (xs : Vect n a) -> Maybe (IsElem x xs)--The reason for returning a proof is that we can use it to remove an-element from the correct position in a vector:--.. code-block:: idris--    shrink : (xs : Vect (S n) a) -> IsElem x xs -> Vect n a--We leave the definitions of ``letters``, ``init``, ``isElem`` and-``shrink`` as exercises. Having implemented these, the ``Handler``-implementation for ``MysteryRules`` is surprisingly straightforward:--.. code-block:: idris--    Handler MysteryRules m where-        handle (MkG w g got []) Won k = k () (GameWon w)-        handle (MkG w Z got m) Lost k = k () (GameLost w)--        handle st Get k = k (show st) st-        handle st (NewWord w) k = k () (initState w)--        handle (MkG w (S g) got m) (Guess x) k =-            case isElem x m of-                 Nothing => k False (MkG w _ got m)-                 (Just p) => k True (MkG w _ (x :: got) (shrink m p))--Each case simply involves directly updating the game state in a way-which is consistent with the declared rules. In particular, in-``Guess``, if the handler claims that the guessed letter is in the word-(by passing ``True`` to ``k``), there is no way to update the state in-such a way that the number of missing letters or number of guesses does-not follow the rules.--Step 4: Implement Interface-===========================--Having described the rules, and implemented state transitions which-follow those rules as an effect handler, we can now write an interface-for the game which uses the ``MYSTERY`` effect:--.. code-block:: idris--    game : Eff () [MYSTERY (Running (S g) w), STDIO]-                  [MYSTERY NotRunning, STDIO]--The type indicates that the game must start in a running state, with-some guesses available, and eventually reach a not-running state (i.e.-won or lost). The only way to achieve this is by correctly following the-stated rules.--Note that the type of ``game`` makes no assumption that there are-letters to be guessed in the given word (i.e. it is ``w`` rather than-``S w``). This is because we will be choosing a word at random from a-vector of ``String``, and at no point have we made it explicit that-those ``String`` are non-empty.--Finally, we need to initialise the game by picking a word at random from-a list of candidates, setting it as the target using ``NewWord``, then-running ``game``:--.. code-block:: idris--    runGame : Eff () [MYSTERY NotRunning, RND, SYSTEM, STDIO]-    runGame = do srand !time-                 let w = index !(rndFin _) words-                 call $ NewWord w-                 game-                 putStrLn !(call Get)--We use the system time (``time`` from the ``SYSTEM`` effect; see-Appendix :ref:`sect-appendix`) to initialise the random number-generator, then pick a random ``Fin`` to index into a list of-``words``. For example, we could initialise a word list as follows:--.. code-block:: idris--    words : ?wtype-    words = with Vect ["idris","agda","haskell","miranda",-             "java","javascript","fortran","basic",-             "coffeescript","rust"]--    wtype = proof search--.. note::-    Rather than have to explicitly declare a type with the vector’s-    length, it is convenient to give a hole ``?wtype`` and let-    Idris’s proof search mechanism find the type. This is a-    limited form of type inference, but very useful in practice.--A possible complete implementation of ``game`` is-presented below:--.. code-block:: idris--    game : Eff () [MYSTERY (Running (S g) w), STDIO]-                  [MYSTERY NotRunning, STDIO]-    game {w=Z} = Won-    game {w=S _}-         = do putStrLn !Get-              putStr "Enter guess: "-              let guess = trim !getStr-              case choose (not (guess == "")) of-                   (Left p) => processGuess (strHead' guess p)-                   (Right p) => do putStrLn "Invalid input!"-                                   game-      where-        processGuess : Char -> Eff () [MYSTERY (Running (S g) (S w)), STDIO]-                                      [MYSTERY NotRunning, STDIO]-        processGuess {g} {w} c-          = case !(Main.Guess c) of-                 True => do putStrLn "Good guess!"-                            case w of-                                 Z => Won-                                 (S k) => game-                 False => do putStrLn "No, sorry"-                             case g of-                                  Z => Lost-                                  (S k) => game--Discussion-==========--Writing the rules separately as an effect, then an implementation-which uses that effect, ensures that the implementation must follow-the rules.  This has practical applications in more serious contexts;-``MysteryRules`` for example can be though of as describing a-*protocol* that a game player most follow, or alternative a-*precisely-typed API*.--In practice, we wouldn’t really expect to write rules first then-implement the game once the rules were complete. Indeed, I didn’t do-so when constructing this example! Rather, I wrote down a set of-likely rules making any assumptions *explicit* in the state-transitions for ``MysteryRules``. Then, when implementing ``game`` at-first, any incorrect assumption was caught as a type error. The-following errors were caught during development:--- Not realising that allowing ``NewWord`` to be an arbitrary string would mean that ``game`` would have to deal with a zero-length word as a starting state.--- Forgetting to check whether a game was won before recursively calling ``processGuess``, thus accidentally continuing a finished game.--- Accidentally checking the number of missing letters, rather than the number of remaining guesses, when checking if a game was lost.--These are, of course, simple errors, but were caught by the type-checker before any testing of the game.--.. [1]-   Readers may recognise this game by the name “Hangman”.
− docs/effects/impleff.rst 
@@ -1,333 +0,0 @@-.. _sect-impleff:--********************-Creating New Effects-********************--We have now seen several side-effecting operations provided by the-``Effects`` library, and examples of their use in Section-:ref:`sect-simpleff`. We have also seen how operations may *modify*-the available effects by changing state in Section-:ref:`sect-depeff`. We have not, however, yet seen how these-operations are implemented. In this section, we describe how a-selection of the available effects are implemented, and show how new-effectful operations may be provided.--State-=====--Effects are described by *algebraic data types*, where the-constructors describe the operations provided when the effect is-available. Stateful operations are described as follows:--.. code-block:: idris--    data State : Effect where-         Get :      State a  a (\x => a)-         Put : b -> State () a (\x => b)--``Effect`` itself is a type synonym, giving the required type for an-effect signature:--.. code-block:: idris--    Effect : Type-    Effect = (result : Type) ->-             (input_resource : Type) ->-             (output_resource : result -> Type) -> Type--Each effect is associated with a *resource*. The second argument to-an effect signature is the resource type on *input* to an operation,-and the third is a function which computes the resource type on-*output*. Here, it means:--- ``Get`` takes no arguments. It has a resource of type ``a``, which is not updated, and running the ``Get`` operation returns something of type ``a``.--- ``Put`` takes a ``b`` as an argument. It has a resource of type ``a`` on input, which is updated to a resource of type ``b``. Running the ``Put`` operation returns the element of the unit type.--The effects library provides an overloaded function ``sig``-which can make effect signatures more concise, particularly when the-result has no effect on the resource type. For ``State``, we can-write:--.. code-block:: idris--    data State : Effect where-         Get :      sig State a  a-         Put : b -> sig State () a b--There are four versions of ``sig``, depending on whether we-are interested in the resource type, and whether we are updating the-resource. Idris will infer the appropriate version from usage.--.. code-block:: idris--    NoResourceEffect.sig : Effect -> Type -> Type-    NoUpdateEffect.sig   : Effect -> (ret : Type) -> -                                     (resource : Type) -> Type-    UpdateEffect.sig     : Effect -> (ret : Type) -> -                                     (resource_in : Type) -> -                                     (resource_out : Type) -> Type-    DepUpdateEffect.sig  : Effect -> (ret : Type) -> -                                     (resource_in : Type) -> -                                     (resource_out : ret -> Type) -> Type--In order to convert ``State`` (of type ``Effect``) into something-usable in an effects list, of type ``EFFECT``, we write the following:--.. code-block:: idris--    STATE : Type -> EFFECT-    STATE t = MkEff t State--``MkEff`` constructs an ``EFFECT`` by taking the resource type (here,-the ``t`` which parameterises ``STATE``) and the effect signature-(here, ``State``). For reference, ``EFFECT`` is declared as follows:--.. code-block:: idris--    data EFFECT : Type where-         MkEff : Type -> Effect -> EFFECT--Recall that to run an effectful program in ``Eff``, we use one of the-``run`` family of functions to run the program in a particular-computation context ``m``. For each effect, therefore, we must explain-how it is executed in a particular computation context for ``run`` to-work in that context. This is achieved with the following interface:--.. code-block:: idris--    interface Handler (e : Effect) (m : Type -> Type) where-          handle : resource -> (eff : e t resource resource') ->-                   ((x : t) -> resource' x -> m a) -> m a--We have already seen some implementation declarations in the effect-summaries in Section :ref:`sect-simpleff`. An implementation of ``Handler e-m`` means that the effect declared with signature ``e`` can be run in-computation context ``m``. The ``handle`` function takes:--- The ``resource`` on input (so, the current value of the state for ``State``)--- The effectful operation (either ``Get`` or ``Put x`` for ``State``)--- A *continuation*, which we conventionally call ``k``, and should be passed the result value of the operation, and an updated resource.--There are two reasons for taking a continuation here: firstly, this is-neater because there are multiple return values (a new resource and-the result of the operation); secondly, and more importantly, the-continuation can be called zero or more times.--A ``Handler`` for ``State`` simply passes on the value of the state,-in the case of ``Get``, or passes on a new state, in the case of-``Put``.  It is defined the same way for all computation contexts:--.. code-block:: idris--    Handler State m where-         handle st Get     k = k st st-         handle st (Put n) k = k () n--This gives enough information for ``Get`` and ``Put`` to be used-directly in ``Eff`` programs. It is tidy, however, to define top level-functions in ``Eff``, as follows:--.. code-block:: idris--    get : Eff x [STATE x]-    get = call Get--    put : x -> Eff () [STATE x]-    put val = call (Put val)--    putM : y -> Eff () [STATE x] [STATE y]-    putM val = call (Put val)--**An implementation detail (aside):** The ``call`` function converts-an ``Effect`` to a function in ``Eff``, given a proof that the effect-is available. This proof can be constructed automatically, since-it is essentially an index into a statically known list of effects:--.. code-block:: idris--    call : {e : Effect} ->-           (eff : e t a b) -> {auto prf : EffElem e a xs} ->-           Eff t xs (\v => updateResTy v xs prf eff)--This is the reason for the ``Can’t solve goal`` error when an effect-is not available: the implicit proof ``prf`` has not been solved-automatically because the required effect is not in the list of-effects ``xs``.--Such details are not important for using the library, or even writing-new effects, however.--Summary----------The following listing summarises what is required to define the-``STATE`` effect:--.. code-block:: idris--    data State : Effect where-         Get :      sig State a  a-         Put : b -> sig State () a b--    STATE : Type -> EFFECT-    STATE t = MkEff t State--    Handler State m where-         handle st Get     k = k st st-         handle st (Put n) k = k () n--    get : Eff x [STATE x]-    get = call Get--    put : x -> Eff () [STATE x]-    put val = call (Put val)--    putM : y -> Eff () [STATE x] [STATE y]-    putM val = call (Put val)---Console I/O-===========--Then listing below gives the definition of the ``STDIO``-effect, including handlers for ``IO`` and ``IOExcept``. We omit the-definition of the top level ``Eff`` functions, as this merely invoke-the effects ``PutStr``, ``GetStr``, ``PutCh`` and ``GetCh`` directly.--Note that in this case, the resource is the unit type in every case,-since the handlers merely apply the ``IO`` equivalents of the effects-directly.--.. _eff-stdiodef:-.. code-block:: idris--    data StdIO : Effect where-         PutStr : String -> sig StdIO ()-         GetStr : sig StdIO String-         PutCh : Char -> sig StdIO ()-         GetCh : sig StdIO Char--    Handler StdIO IO where-        handle () (PutStr s) k = do putStr s; k () ()-        handle () GetStr     k = do x <- getLine; k x ()-        handle () (PutCh c)  k = do putChar c; k () ()-        handle () GetCh      k = do x <- getChar; k x ()--    Handler StdIO (IOExcept a) where-        handle () (PutStr s) k = do ioe_lift $ putStr s; k () ()-        handle () GetStr     k = do x <- ioe_lift $ getLine; k x ()-        handle () (PutCh c)  k = do ioe_lift $ putChar c; k () ()-        handle () GetCh      k = do x <- ioe_lift $ getChar; k x ()--    STDIO : EFFECT-    STDIO = MkEff () StdIO--Exceptions-==========--The listing below gives the definition of the ``Exception``-effect, including two of its handlers for ``Maybe`` and ``List``. The-only operation provided is ``Raise``. The key point to note in the-definitions of these handlers is that the continuation ``k`` is not-used. Running ``Raise`` therefore means that computation stops with an-error.--.. code-block:: idris--    data Exception : Type -> Effect where-         Raise : a -> sig (Exception a) b--    Handler (Exception a) Maybe where-         handle _ (Raise e) k = Nothing--    Handler (Exception a) List where-         handle _ (Raise e) k = []--    EXCEPTION : Type -> EFFECT-    EXCEPTION t = MkEff () (Exception t)---Non-determinism-===============--The following listing gives the definition of the ``Select``-effect for writing non-deterministic programs, including a handler for-``List`` context which returns all possible successful values, and a-handler for ``Maybe`` context which returns the first successful-value.--.. code-block:: idris--    data Selection : Effect where-         Select : List a -> sig Selection a--    Handler Selection Maybe where-         handle _ (Select xs) k = tryAll xs where-             tryAll [] = Nothing-             tryAll (x :: xs) = case k x () of-                                     Nothing => tryAll xs-                                     Just v => Just v--    Handler Selection List where-         handle r (Select xs) k = concatMap (\x => k x r) xs--    SELECT : EFFECT-    SELECT = MkEff () Selection---Here, the continuation is called multiple times in each handler, for-each value in the list of possible values. In the ``List`` handler, we-accumulate all successful results, and in the ``Maybe`` handler we try-the first value in the list, and try later values only if that fails.--File Management-===============--Result-dependent effects are no different from non-dependent effects-in the way they are implemented. The listing below-illustrates this for the ``FILE_IO`` effect. The syntax for state-transitions ``{ x ==> {res} x’ }``, where the result state ``x’`` is-computed from the result of the operation ``res``, follows that for-the equivalent ``Eff`` programs.--.. code-block:: idris--    data FileIO : Effect where-         Open : (fname: String)-                -> (m : Mode)-                -> sig FileIO Bool () (\res => case res of-                                                    True => OpenFile m-                                                    False => ())-         Close : sig FileIO () (OpenFile m)--         ReadLine  :           sig FileIO String (OpenFile Read)-         WriteLine : String -> sig FileIO ()     (OpenFile Write)-         EOF       :           sig FileIO Bool   (OpenFile Read)--    Handler FileIO IO where-        handle () (Open fname m) k = do h <- openFile fname m-                                        if !(validFile h)-                                                 then k True (FH h)-                                                 else k False ()-        handle (FH h) Close      k = do closeFile h-                                        k () ()--        handle (FH h) ReadLine        k = do str <- fread h-                                             k str (FH h)-        handle (FH h) (WriteLine str) k = do fwrite h str-                                             k () (FH h)-        handle (FH h) EOF             k = do e <- feof h-                                             k e (FH h)--    FILE_IO : Type -> EFFECT-    FILE_IO t = MkEff t FileIO--Note that in the handler for ``Open``, the types passed to the-continuation ``k`` are different depending on whether the result is-``True`` (opening succeeded) or ``False`` (opening failed). This uses-``validFile``, defined in the ``Prelude``, to test whether a file-handler refers to an open file or not.
− docs/effects/index.rst 
@@ -1,40 +0,0 @@-.. _eff-tutorial-index:--####################-The Effects Tutorial-####################--A tutorial on the `Effects` package in `Idris`.--.. topic:: Effects and the ``Control.ST`` module--   There is a new module in the ``contrib`` package, ``Control.ST``, which-   provides the resource tracking facilities of `Effects` but with-   better support for creating and deleting resources, and implementing-   resources in terms of other resources.--   Unless you have a particular reason to use `Effects` you are strongly-   recommended to use ``Control.ST`` instead. There is a tutorial available-   on this site for ``Control.ST`` with several examples-   (:ref:`st-tutorial-index`).--.. note::--   The documentation for Idris has been published under the Creative-   Commons CC0 License. As such to the extent possible under law, *The-   Idris Community* has waived all copyright and related or neighbouring-   rights to Documentation for Idris.--   More information concerning the CC0 can be found online at: http://creativecommons.org/publicdomain/zero/1.0/--.. toctree::-   :maxdepth: 1--   introduction-   state-   simpleeff-   depeff-   impleff-   hangman-   conclusions-   summary
− docs/effects/introduction.rst 
@@ -1,109 +0,0 @@-************-Introduction-************--Pure functional languages with dependent types such as `Idris-<http://www.idris-lang.org/>`_ support reasoning about programs directly-in the type system, promising that we can *know* a program will run-correctly (i.e. according to the specification in its type) simply-because it compiles. Realistically, though, things are not so simple:-programs have to interact with the outside world, with user input,-input from a network, mutable state, and so on. In this tutorial I-will introduce the library, which is included with the distribution-and supports programming and reasoning with side-effecting programs,-supporting mutable state, interaction with the outside world,-exceptions, and verified resource management.--This tutorial assumes familiarity with pure programming in Idris,-as described in Sections 1–6 of the main tutorial [1]_. The examples-presented are tested with Idris and can be found in the-examples directory of the Idris repository.--Consider, for example, the following introductory function which-illustrates the kind of properties which can be expressed in the type-system:--.. code-block:: idris--   vadd : Vect n Int -> Vect n Int -> Vect n Int-   vadd []        []        = []-   vadd (x :: xs) (y :: ys) = x + y :: vadd xs ys--This function adds corresponding elements in a pair of vectors. The type-guarantees that the vectors will contain only elements of type ``Int``,-and that the input lengths and the output length all correspond. A-natural question to ask here, which is typically neglected by-introductory tutorials, is “How do I turn this into a program?” That is,-given some lists entered by a user, how do we get into a position to be-able to apply the ``vadd`` function? Before doing so, we will have to:--- Read user input, either from the keyboard, a file, or some other input device.--- Check that the user inputs are valid, i.e. contain only ``Int`` and are the same length, and report an error if not.--- Write output--The complete program will include side-effects for I/O and error-handling, before we can get to the pure core functionality. In this-tutorial, we will see how Idris supports side-effects.-Furthermore, we will see how we can use the dependent type system to-*reason* about stateful and side-effecting programs. We will return to-this specific example later.--Hello world-===========--To give an idea of how programs with effects look, here is the-ubiquitous “Hello world” program, written using the ``Effects``-library:--.. code-block:: idris--   module Main--   import Effects-   import Effect.StdIO--   hello : Eff () [STDIO]-   hello = putStrLn "Hello world!"--   main : IO ()-   main = run hello--As usual, the entry point is ``main``. All ``main`` has to do is invoke the-``hello`` function which supports the ``STDIO`` effect for console I/O, and-returns the unit value.  All programs using the ``Effects`` library must-``import Effects``.  The details of the ``Eff`` type will be presented in the-remainder of this tutorial.--To compile and run this program, Idris needs to be told to include-the ``Effects`` package, using the ``-p effects`` flag (this flag is-required for all examples in this tutorial):--.. code-block:: sh--   idris hello.idr -o hello -p effects-   ./hello Hello world!--Outline-=======--The tutorial is structured as follows: first, in Section-:ref:`sect-state`, we will discuss state management, describing why it-is important and introducing the ``effects`` library to show how it-can be used to manage state. This section also gives an overview of-the syntax of effectful programs. Section :ref:`sect-simpleff` then-introduces a number of other effects a program may have: I/O;-Exceptions; Random Numbers; and Non-determinism, giving examples for-each, and an extended example combining several effects in one-complete program. Section :ref:`sect-depeff` introduces *dependent*-effects, showing how states and resources can be managed in-types. Section :ref:`sect-impleff` shows how new effects can be-implemented.  Section :ref:`sect-hangman` gives an extended example-showing how to implement a “mystery word” guessing game, using effects-to describe the rules of the game and ensure they are implemented-accurately. References to further reading are given in Section-:ref:`sect-further`.--.. [1]-   You do not, however, need to know what a monad is!
− docs/effects/simpleeff.rst 
@@ -1,595 +0,0 @@-.. _sect-simpleff:--**************-Simple Effects-**************--So far we have seen how to write programs with locally mutable state-using the ``STATE`` effect. To recap, we have the definitions below-in a module ``Effect.State``--.. code-block:: idris--    module Effect.State--    STATE : Type -> EFFECT--    get    :             Eff x  [STATE x]-    put    : x ->        Eff () [STATE x]-    putM   : y ->        Eff () [STATE x] [STATE y]-    update : (x -> x) -> Eff () [STATE x]--    Handler State m where { ... }--The last line, ``Handler State m where { ... }``, means that the ``STATE``-effect is usable in any computation context ``m``. That is, a program-which uses this effect and returns something of type ``a`` can be-evaluated to something of type ``m a`` using ``run``, for any-``m``. The lower case ``State`` is a data type describing the-operations which make up the ``STATE`` effect itself—we will go into-more detail about this in Section :ref:`sect-impleff`.--In this section, we will introduce some other supported effects,-allowing console I/O, exceptions, random number generation and-non-deterministic programming. For each effect we introduce, we will-begin with a summary of the effect, its supported operations, and the-contexts in which it may be used, like that above for ``STATE``, and-go on to present some simple examples. At the end, we will see some-examples of programs which combine multiple effects.--All of the effects in the library, including those described in this-section, are summarised in Appendix :ref:`sect-appendix`.--Console I/O-===========--Console I/O is supported with the ``STDIO``-effect, which allows reading and writing characters and strings to and-from standard input and standard output. Notice that there is a-constraint here on the computation context ``m``, because it only-makes sense to support console I/O operations in a context where we-can perform (or at the very least simulate) console I/O:--.. code-block:: idris--    module Effect.StdIO--    STDIO : EFFECT--    putChar  : Char ->   Eff () [STDIO]-    putStr   : String -> Eff () [STDIO]-    putStrLn : String -> Eff () [STDIO]--    getStr   :           Eff String [STDIO]-    getChar  :           Eff Char [STDIO]--    Handler StdIO IO where { ... }-    Handler StdIO (IOExcept a) where { ... }--Examples-----------A program which reads the user’s name, then says hello, can be written-as follows:--.. code-block:: idris--    hello : Eff () [STDIO]-    hello = do putStr "Name? "-               x <- getStr-               putStrLn ("Hello " ++ trim x ++ "!")--We use ``trim`` here to remove the trailing newline from the-input. The resource associated with ``STDIO`` is simply the empty-tuple, which has a default value ``()``, so we can run this as-follows:--.. code-block:: idris--    main : IO ()-    main = run hello--In ``hello`` we could also use ``!``-notation instead of ``x <--getStr``, since we only use the string that is read once:--.. code-block:: idris--    hello : Eff () [STDIO]-    hello = do putStr "Name? "-               putStrLn ("Hello " ++ trim !getStr ++ "!")--More interestingly, we can combine multiple effects in one-program. For example, we can loop, counting the number of people we’ve-said hello to:--.. code-block:: idris--    hello : Eff () [STATE Int, STDIO]-    hello = do putStr "Name? "-               putStrLn ("Hello " ++ trim !getStr ++ "!")-               update (+1)-               putStrLn ("I've said hello to: " ++ show !get ++ " people")-               hello--The list of effects given in ``hello`` means that the function can-call ``get`` and ``put`` on an integer state, and any functions which-read and write from the console. To run this, ``main`` does not need-to be changed.--Aside: Resource Types------------------------To find out the resource type of an effect, if necessary (for example-if we want to initialise a resource explicitly with ``runInit`` rather-than using a default value with ``run``) we can run the-``resourceType`` function at the REPL:--.. code-block:: idris--    *ConsoleIO> resourceType STDIO-    () : Type-    *ConsoleIO> resourceType (STATE Int)-    Int : Type--Exceptions-==========--The ``EXCEPTION``-effect is declared in module ``Effect.Exception``. This allows programs-to exit immediately with an error, or errors to be handled more-generally:--.. _eff-exception:-.. code-block:: idris--    module Effect.Exception--    EXCEPTION : Type -> EFFECT--    raise : a -> Eff b [EXCEPTION a]--    Handler (Exception a) Maybe where { ... }-    Handler (Exception a) List where { ... }-    Handler (Exception a) (Either a) where { ... }-    Handler (Exception a) (IOExcept a) where { ... }-    Show a => Handler (Exception a) IO where { ... }--Example----------Suppose we have a ``String`` which is expected to represent an integer-in the range ``0`` to ``n``. We can write a function ``parseNumber``-which returns an ``Int`` if parsing the string returns a number in the-appropriate range, or throws an exception otherwise. Exceptions are-parameterised by an error type:--.. code-block:: idris--    data Error = NotANumber | OutOfRange--    parseNumber : Int -> String -> Eff Int [EXCEPTION Error]-    parseNumber num str-       = if all isDigit (unpack str)-            then let x = cast str in-                 if (x >=0 && x <= num)-                    then pure x-                    else raise OutOfRange-            else raise NotANumber--Programs which support the ``EXCEPTION`` effect can be run in any-context which has some way of throwing errors, for example, we can run-``parseNumber`` in the ``Either Error`` context. It returns a value of-the form ``Right x`` if successful:--.. code-block:: idris--    *Exception> the (Either Error Int) $ run (parseNumber 42 "20")-    Right 20 : Either Error Int--Or ``Left e`` on failure, carrying the appropriate exception:--.. code-block:: idris--    *Exception> the (Either Error Int) $ run (parseNumber 42 "50")-    Left OutOfRange : Either Error Int--    *Exception> the (Either Error Int) $ run (parseNumber 42 "twenty")-    Left NotANumber : Either Error Int--In fact, we can do a little bit better with ``parseNumber``, and have-it return a *proof* that the integer is in the required range along-with the integer itself. One way to do this is define a type of-bounded integers, ``Bounded``:--.. code-block:: idris--    Bounded : Int -> Type-    Bounded x = (n : Int ** So (n >= 0 && n <= x))--Recall that ``So`` is parameterised by a ``Bool``, and only ``So-True`` is inhabited. We can use ``choose`` to construct such a value-from the result of a dynamic check:--.. code-block:: idris--    data So : Bool -> Type where-      Oh : So True--    choose : (b : Bool) -> Either (So b) (So (not b))--We then write ``parseNumber`` using ``choose`` rather than an-``if/then/else`` construct, passing the proof it returns on success as-the boundedness proof:--.. code-block:: idris--    parseNumber : (x : Int) -> String -> Eff (Bounded x) [EXCEPTION Error]-    parseNumber x str-       = if all isDigit (unpack str)-            then let num = cast str in-                 case choose (num >=0 && num <= x) of-                      Left p => pure (num ** p)-                      Right p => raise OutOfRange-            else raise NotANumber--Random Numbers-==============--Random number generation is also implemented by the library, in module-``Effect.Random``:--.. code-block:: idris--    module Effect.Random--    RND : EFFECT--    srand  : Integer ->            Eff () [RND]-    rndInt : Integer -> Integer -> Eff Integer [RND]-    rndFin : (k : Nat) ->          Eff (Fin (S k)) [RND]--    Handler Random m where { ... }--Random number generation is considered side-effecting because its-implementation generally relies on some external source of randomness.-The default implementation here relies on an integer *seed*, which can-be set with ``srand``. A specific seed will lead to a predictable,-repeatable sequence of random numbers. There are two functions which-produce a random number:--- ``rndInt``, which returns a random integer between the given lower-   and upper bounds.--- ``rndFin``, which returns a random element of a finite set-   (essentially a number with an upper bound given in its type).--Example----------We can use the ``RND`` effect to implement a simple guessing game. The-``guess`` function, given a target number, will repeatedly ask the-user for a guess, and state whether the guess is too high, too low, or-correct:--.. code-block:: idris--    guess : Int -> Eff () [STDIO]--For reference, the code for ``guess`` is given below:--.. _eff-game:-.. code-block:: idris--    guess : Int -> Eff () [STDIO]-    guess target-        = do putStr "Guess: "-             case run {m=Maybe} (parseNumber 100 (trim !getStr)) of-                  Nothing => do putStrLn "Invalid input"-                                guess target-                  Just (v ** _) =>-                             case compare v target of-                                 LT => do putStrLn "Too low"-                                          guess target-                                 EQ => putStrLn "You win!"-                                 GT => do putStrLn "Too high"-                                          guess target--Note that we use ``parseNumber`` as defined previously to read user input, but-we don’t need to list the ``EXCEPTION`` effect because we use a nested ``run``-to invoke ``parseNumber``, independently of the calling effectful program.--To invoke this, we pick a random number within the range 0–100,-having set up the random number generator with a seed, then run-``guess``:--.. code-block:: idris--    game : Eff () [RND, STDIO]-    game = do srand 123456789-              guess (fromInteger !(rndInt 0 100))--    main : IO ()-    main = run game--If no seed is given, it is set to the ``default`` value. For a less-predictable game, some better source of randomness would be required,-for example taking an initial seed from the system time. To see how to-do this, see the ``SYSTEM`` effect described in :ref:`sect-appendix`.---Non-determinism-===============--The listing below gives the definition of the non-determinism-effect, which allows a program to choose a value non-deterministically-from a list of possibilities in such a way that the entire computation-succeeds:--.. code-block:: idris--    import Effects-    import Effect.Select--    SELECT : EFFECT--    select : List a -> Eff a [SELECT]--    Handler Selection Maybe where { ... }-    Handler Selection List where { ... }--Example----------The ``SELECT`` effect can be used to solve constraint problems, such-as finding Pythagorean triples. The idea is to use ``select`` to give-a set of candidate values, then throw an exception for any combination-of values which does not satisfy the constraint:--.. code-block:: idris--    triple : Int -> Eff (Int, Int, Int) [SELECT, EXCEPTION String]-    triple max = do z <- select [1..max]-                    y <- select [1..z]-                    x <- select [1..y]-                    if (x * x + y * y == z * z)-                       then pure (x, y, z)-                       else raise "No triple"--This program chooses a value for ``z`` between ``1`` and ``max``, then-values for ``y`` and ``x``. In operation, after a ``select``, the-program executes the rest of the ``do``-block for every possible-assignment, effectively searching depth-first. If the list is empty-(or an exception is thrown) execution fails.--There are handlers defined for ``Maybe`` and ``List`` contexts, i.e.-contexts which can capture failure. Depending on the context ``m``,-``triple`` will either return the first triple it finds (if in-``Maybe`` context) or all triples in the range (if in ``List``-context). We can try this as follows:--.. code-block:: idris--    main : IO ()-    main = do print $ the (Maybe _) $ run (triple 100)-              print $ the (List _) $ run (triple 100)--``vadd`` revisited-==================--We now return to the ``vadd`` program from the introduction. Recall the-definition:--.. code-block:: idris--    vadd : Vect n Int -> Vect n Int -> Vect n Int-    vadd []        []        = []-    vadd (x :: xs) (y :: ys) = x + y :: vadd xs ys--Using , we can set up a program so that it reads input from a user,-checks that the input is valid (i.e both vectors contain integers, and-are the same length) and if so, pass it on to ``vadd``. First, we-write a wrapper for ``vadd`` which checks the lengths and throw an-exception if they are not equal. We can do this for input vectors of-length ``n`` and ``m`` by matching on the implicit arguments ``n`` and-``m`` and using ``decEq`` to produce a proof of their equality, if-they are equal:--.. code-block:: idris--    vadd_check : Vect n Int -> Vect m Int ->-                 Eff (Vect m Int) [EXCEPTION String]-    vadd_check {n} {m} xs ys with (decEq n m)-      vadd_check {n} {m=n} xs ys | (Yes Refl) = pure (vadd xs ys)-      vadd_check {n} {m}   xs ys | (No contra) = raise "Length mismatch"--To read a vector from the console, we implement a function of the-following type:--.. code-block:: idris--    read_vec : Eff (p ** Vect p Int) [STDIO]--This returns a dependent pair of a length, and a vector of that-length, because we cannot know in advance how many integers the user-is going to input. We can use ``-1`` to indicate the end of input:--.. code-block:: idris--    read_vec : Eff (p ** Vect p Int) [STDIO]-    read_vec = do putStr "Number (-1 when done): "-                  case run (parseNumber (trim !getStr)) of-                       Nothing => do putStrLn "Input error"-                                     read_vec-                       Just v => if (v /= -1)-                                    then do (_ ** xs) <- read_vec-                                            pure (_ ** v :: xs)-                                    else pure (_ ** [])-      where-        parseNumber : String -> Eff Int [EXCEPTION String]-        parseNumber str-          = if all (\x => isDigit x || x == '-') (unpack str)-               then pure (cast str)-               else raise "Not a number"--This uses a variation on ``parseNumber`` which does not require a-number to be within range.--Finally, we write a program which reads two vectors and prints the-result of pairwise addition of them, throwing an exception if the-inputs are of differing lengths:--.. code-block:: idris--    do_vadd : Eff () [STDIO, EXCEPTION String]-    do_vadd = do putStrLn "Vector 1"-                 (_ ** xs) <- read_vec-                 putStrLn "Vector 2"-                 (_ ** ys) <- read_vec-                 putStrLn (show !(vadd_check xs ys))--By having explicit lengths in the type, we can be sure that ``vadd``-is only being used where the lengths of inputs are guaranteed to be-equal.  This does not stop us reading vectors from user input, but it-does require that the lengths are checked and any discrepancy is dealt-with gracefully.---Example: An Expression Calculator-=================================--To show how these effects can fit together, let us consider an-evaluator for a simple expression language, with addition and integer-values.--.. code-block:: idris--    data Expr = Val Integer-              | Add Expr Expr--An evaluator for this language always returns an ``Integer``, and-there are no situations in which it can fail!--.. code-block:: idris--    eval : Expr -> Integer-    eval (Val x) = x-    eval (Add l r) = eval l + eval r--If we add variables, however, things get more interesting. The-evaluator will need to be able to access the values stored in-variables, and variables may be undefined.--.. code-block:: idris--    data Expr = Val Integer-              | Var String-              | Add Expr Expr--To start, we will change the type of ``eval`` so that it is effectful,-and supports an exception effect for throwing errors, and a state-containing a mapping from variable names (as ``String``) to their-values:--.. code-block:: idris--    Env : Type-    Env = List (String, Integer)--    eval : Expr -> Eff Integer [EXCEPTION String, STATE Env]-    eval (Val x)   = pure x-    eval (Add l r) = pure $ !(eval l) + !(eval r)--Note that we are using ``!``-notation to avoid having to bind-subexpressions in a ``do`` block. Next, we add a case for evaluating-``Var``:--.. code-block:: idris--    eval (Var x) = case lookup x !get of-                        Nothing => raise $ "No such variable " ++ x-                        Just val => pure val--This retrieves the state (with ``get``, supported by the ``STATE Env``-effect) and raises an exception if the variable is not in the-environment (with ``raise``, supported by the ``EXCEPTION String``-effect).--To run the evaluator on a particular expression in a particular-environment of names and their values, we can write a function which-sets the state then invokes ``eval``:--.. code-block:: idris--    runEval : List (String, Integer) -> Expr -> Maybe Integer-    runEval args expr = run (eval' expr)-      where eval' : Expr -> Eff Integer [EXCEPTION String, STATE Env]-            eval' e = do put args-                         eval e--We have picked ``Maybe`` as a computation context here; it needs to be-a context which is available for every effect supported by-``eval``. In particular, because we have exceptions, it needs to be a-context which supports exceptions. Alternatively, ``Either String`` or-``IO`` would be fine, for example.--What if we want to extend the evaluator further, with random number-generation? To achieve this, we add a new constructor to ``Expr``,-which gives a random number up to a maximum value:--.. code-block:: idris--    data Expr = Val Integer-              | Var String-              | Add Expr Expr-              | Random Integer--Then, we need to deal with the new case, making sure that we extend-the list of events to include ``RND``. It doesn't matter where ``RND``-appears in the list, as long as it is present:--.. code-block:: idris--    eval : Expr -> Eff Integer [EXCEPTION String, RND, STATE Env]--    eval (Random upper) = rndInt 0 upper--For test purposes, we might also want to print the random number which-has been generated:--.. code-block:: idris--    eval (Random upper) = do val <- rndInt 0 upper-                             putStrLn (show val)-                             pure val--If we try this without extending the effects list, we would see an-error something like the following:--::--    Expr.idr:28:6:When elaborating right hand side of eval:-    Can't solve goal-       SubList [STDIO]-               [(EXCEPTION String), RND, (STATE (List (String, Integer)))]--In other words, the ``STDIO`` effect is not available. We can correct-this simply by updating the type of ``eval`` to include ``STDIO``.--.. code-block:: idris--    eval : Expr -> Eff Integer [STDIO, EXCEPTION String, RND, STATE Env]--.. note:: Using ``STDIO`` will restrict the number of contexts in-          which ``eval`` can be ``run`` to those which support-          ``STDIO``, such as ``IO``. Once effect lists get longer, it-          can be a good idea instead to encapsulate sets of effects in-          a type synonym. This is achieved as follows, simply by-          defining a function which computes a type, since types are-          first class in Idris:--          .. code-block:: idris--              EvalEff : Type -> Type-              EvalEff t = Eff t [STDIO, EXCEPTION String, RND, STATE Env]--              eval : Expr -> EvalEff Integer
− docs/effects/state.rst 
@@ -1,529 +0,0 @@-.. _sect-state:--*****-State-*****--Many programs, even pure programs, can benefit from locally mutable-state. For example, consider a program which tags binary tree nodes-with a counter, by an inorder traversal (i.e. counting depth first,-left to right). This would perform something like the following:--|image|--We can describe binary trees with the following data type ``BTree``-and ``testTree`` to represent the example input above:--.. code-block:: idris--    data BTree a = Leaf-                 | Node (BTree a) a (BTree a)--    testTree : BTree String-    testTree = Node (Node Leaf "Jim" Leaf)-                    "Fred"-                    (Node (Node Leaf "Alice" Leaf)-                          "Sheila"-                          (Node Leaf "Bob" Leaf))--Then our function to implement tagging, beginning to tag with a-specific value ``i``, has the following type:--.. code-block:: idris--    treeTag : (i : Int) -> BTree a -> BTree (Int, a)--First attempt-=============--Naïvely, we can implement ``treeTag`` by implementing a helper-function which propagates a counter, returning the result of the count-for each subtree:--.. code-block:: idris--    treeTagAux : (i : Int) -> BTree a -> (Int, BTree (Int, a))-    treeTagAux i Leaf = (i, Leaf)-    treeTagAux i (Node l x r)-           = let (i', l') = treeTagAux i l in-             let x' = (i', x) in-             let (i'', r') = treeTagAux (i' + 1) r in-                 (i'', Node l' x' r')--    treeTag : (i : Int) -> BTree a -> BTree (Int, a)-    treeTag i x = snd (treeTagAux i x)--This gives the expected result when run at the REPL prompt:--.. code-block:: idris--    *TreeTag> treeTag 1 testTree-    Node (Node Leaf (1, "Jim") Leaf)-         (2, "Fred")-         (Node (Node Leaf (3, "Alice") Leaf)-               (4, "Sheila")-               (Node Leaf (5, "Bob") Leaf)) : BTree (Int, String)--This works as required, but there are several problems when we try to-scale this to larger programs. It is error prone, because we need to-ensure that state is propagated correctly to the recursive calls (i.e.-passing the appropriate ``i`` or ``i’``). It is hard to read, because-the functional details are obscured by the state propagation. Perhaps-most importantly, there is a common programming pattern here which-should be abstracted but instead has been implemented by hand. There-is local mutable state (the counter) which we have had to make-explicit.--Introducing ``Effects``-=======================--Idris provides a library, ``Effects`` [3]_, which captures this-pattern and many others involving effectful computation [1]_. An-effectful program ``f`` has a type of the following form:--.. code-block:: idris--    f : (x1 : a1) -> (x2 : a2) -> ... -> Eff t effs--That is, the return type gives the effects that ``f`` supports-(``effs``, of type ``List EFFECT``) and the type the computation-returns ``t``. So, our ``treeTagAux`` helper could be written with the-following type:--.. code-block:: idris--    treeTagAux : BTree a -> Eff (BTree (Int, a)) [STATE Int]--That is, ``treeTagAux`` has access to an integer state, because the-list of available effects includes ``STATE Int``. ``STATE`` is-declared as follows in the module ``Effect.State`` (that is, we must-``import Effect.State`` to be able to use it):--.. code-block:: idris--    STATE : Type -> EFFECT--It is an effect parameterised by a type (by convention, we write-effects in all capitals). The ``treeTagAux`` function is an effectful-program which builds a new tree tagged with ``Ints``, and is-implemented as follows:--.. code-block:: idris--    treeTagAux Leaf = pure Leaf-    treeTagAux (Node l x r)-        = do l' <- treeTagAux l-             i <- get-             put (i + 1)-             r' <- treeTagAux r-             pure (Node l' (i, x) r')--There are several remarks to be made about this implementation.-Essentially, it hides the state, which can be accessed using ``get``-and updated using ``put``, but it introduces several new features.-Specifically, it uses ``do``-notation, binding variables with ``<-``,-and a ``pure`` function. There is much to be said about these-features, but for our purposes, it suffices to know the following:--- ``do`` blocks allow effectful operations to be sequenced.--- ``x <- e`` binds the result of an effectful operation ``e`` to a-   variable ``x``. For example, in the above code, ``treeTagAux l`` is-   an effectful operation returning ``BTree (Int, a)``, so ``l’`` has-   type ``BTree (Int, a)``.--- ``pure e`` turns a pure value ``e`` into the result of an effectful-   operation.--The ``get`` and ``put`` functions read and write a state ``t``,-assuming that the ``STATE t`` effect is available. They have the-following types, polymorphic in the state ``t`` they manage:--.. code-block:: idris--    get :      Eff t [STATE t]-    put : t -> Eff () [STATE t]--A program in ``Eff`` can call any other function in ``Eff`` provided-that the calling function supports at least the effects required by-the called function. In this case, it is valid for ``treeTagAux`` to-call both ``get`` and ``put`` because all three functions support the-``STATE Int`` effect.--Programs in ``Eff`` are run in some underlying *computation context*,-using the ``run`` or ``runPure`` function. Using ``runPure``, which-runs an effectful program in the identity context, we can write the-``treeTag`` function as follows, using ``put`` to initialise the-state:--.. code-block:: idris--    treeTag : (i : Int) -> BTree a -> BTree (Int, a)-    treeTag i x = runPure (do put i-                              treeTagAux x)--We could also run the program in an impure context such as ``IO``,-without changing the definition of ``treeTagAux``, by using ``run``-instead of ``runPure``:--.. code-block:: idris--    treeTagAux : BTree a -> Eff (BTree (Int, a)) [STATE Int]-    ...--    treeTag : (i : Int) -> BTree a -> IO (BTree (Int, a))-    treeTag i x = run (do put i-                          treeTagAux x)--Note that the definition of ``treeTagAux`` is exactly as before. For-reference, this complete program (including a ``main`` to run it) is-shown in Listing [introprog].--.. code-block:: idris--    module Main--    import Effects-    import Effect.State--    data BTree a = Leaf-                 | Node (BTree a) a (BTree a)--    Show a => Show (BTree a) where-        show Leaf = "[]"-        show (Node l x r) = "[" ++ show l ++ " "-                                ++ show x ++ " "-                                ++ show r ++ "]"--    testTree : BTree String-    testTree = Node (Node Leaf "Jim" Leaf)-                  "Fred"-                  (Node (Node Leaf "Alice" Leaf)-                        "Sheila"-                        (Node Leaf "Bob" Leaf))--    treeTagAux : BTree a -> Eff (BTree (Int, a)) [STATE Int]-    treeTagAux Leaf = pure Leaf-    treeTagAux (Node l x r) = do l' <- treeTagAux l-                                 i <- get-                                 put (i + 1)-                                 r' <- treeTagAux r-                                 pure (Node l' (i, x) r')--    treeTag : (i : Int) -> BTree a -> BTree (Int, a)-    treeTag i x = runPure (do put i; treeTagAux x)--    main : IO ()-    main = print (treeTag 1 testTree)--Effects and Resources-=====================--Each effect is associated with a *resource*, which is initialised-before an effectful program can be run. For example, in the case of-``STATE Int`` the corresponding resource is the integer state itself.-The types of ``runPure`` and ``run`` show this (slightly simplified-here for illustrative purposes):--.. code-block:: idris--    runPure : {env : Env id xs} -> Eff a xs -> a-    run : Applicative m => {env : Env m xs} -> Eff a xs -> m a--The ``env`` argument is implicit, and initialised automatically where-possible using default values given by implementations of the following -interface:--.. code-block:: idris--    interface Default a where-        default : a--Implementations of ``Default`` are defined for all primitive types, and many-library types such as ``List``, ``Vect``, ``Maybe``, pairs, etc.-However, where no default value exists for a resource type (for-example, you may want a ``STATE`` type for which there is no-``Default`` implementation) the resource environment can be given explicitly-using one of the following functions:--.. code-block:: idris--    runPureInit : Env id xs -> Eff a xs -> a-    runInit : Applicative m => Env m xs -> Eff a xs -> m a--To be well-typed, the environment must contain resources corresponding-exactly to the effects in ``xs``. For example, we could also have-implemented ``treeTag`` by initialising the state as follows:--.. code-block:: idris--    treeTag : (i : Int) -> BTree a -> BTree (Int, a)-    treeTag i x = runPureInit [i] (treeTagAux x)--Labelled Effects-================--What if we have more than one state, especially more than one state of-the same type? How would ``get`` and ``put`` know which state they-should be referring to? For example, how could we extend the tree-tagging example such that it additionally counts the number of leaves-in the tree? One possibility would be to change the state so that it-captured both of these values, e.g.:--.. code-block:: idris--    treeTagAux : BTree a -> Eff (BTree (Int, a)) [STATE (Int, Int)]--Doing this, however, ties the two states together throughout (as well-as not indicating which integer is which). It would be nice to be able-to call effectful programs which guaranteed only to access one of the-states, for example. In a larger application, this becomes-particularly important.--The library therefore allows effects in general to be *labelled* so-that they can be referred to explicitly by a particular name. This-allows multiple effects of the same type to be included. We can count-leaves and update the tag separately, by labelling them as follows:--.. code-block:: idris--    treeTagAux : BTree a ->  Eff (BTree (Int, a))-                                   ['Tag ::: STATE Int,-                                    'Leaves ::: STATE Int]--The ``:::`` operator allows an arbitrary label to be given to an-effect.  This label can be any type—it is simply used to identify an-effect uniquely. Here, we have used a symbol type. In general-``’name`` introduces a new symbol, the only purpose of which is to-disambiguate values [2]_.--When an effect is labelled, its operations are also labelled using the-``:-`` operator. In this way, we can say explicitly which state we-mean when using ``get`` and ``put``. The tree tagging program which-also counts leaves can be written as follows:--.. code-block:: idris--    treeTagAux Leaf = do-        'Leaves :- update (+1)-        pure Leaf-    treeTagAux (Node l x r) = do-        l' <- treeTagAux l-        i <- 'Tag :- get-        'Tag :- put (i + 1)-        r' <- treeTagAux r-        pure (Node l' (i, x) r')--The ``update`` function here is a combination of ``get`` and ``put``,-applying a function to the current state.--.. code-block:: idris--    update : (x -> x) -> Eff () [STATE x]--Finally, our top level ``treeTag`` function now returns a pair of the-number of leaves, and the new tree. Resources for labelled effects are-initialised using the ``:=`` operator (reminiscent of assignment in an-imperative language):--.. code-block:: idris--    treeTag : (i : Int) -> BTree a -> (Int, BTree (Int, a))-    treeTag i x = runPureInit ['Tag := i, 'Leaves := 0]-                        (do x' <- treeTagAux x-                            leaves <- 'Leaves :- get-                            pure (leaves, x'))--To summarise, we have:--- ``:::`` to convert an effect to a labelled effect.--- ``:-`` to convert an effectful operation to a labelled effectful operation.--- ``:=`` to initialise a resource for a labelled effect.--Or, more formally with their types (slightly simplified to account-only for the situation where available effects are not updated):--.. code-block:: idris--    (:::) : lbl -> EFFECT -> EFFECT-    (:-)  : (l : lbl) -> Eff a [x] -> Eff a [l ::: x]-    (:=)  : (l : lbl) -> res -> LRes l res--Here, ``LRes`` is simply the resource type associated with a labelled-effect. Note that labels are polymorphic in the label type ``lbl``.-Hence, a label can be anything—a string, an integer, a type, etc.--``!``-notation-==============--In many cases, using ``do``-notation can make programs unnecessarily-verbose, particularly in cases where the value bound is used once,-immediately. The following program returns the length of the-``String`` stored in the state, for example:--.. code-block:: idris--    stateLength : Eff Nat [STATE String]-    stateLength = do x <- get-                     pure (length x)--This seems unnecessarily verbose, and it would be nice to program in a-more direct style in these cases. provides ``!``-notation to help with-this. The above program can be written instead as:--.. code-block:: idris--    stateLength : Eff Nat [STATE String]-    stateLength = pure (length !get)--The notation ``!expr`` means that the expression ``expr`` should be-evaluated and then implicitly bound. Conceptually, we can think of-``!`` as being a prefix function with the following type:--.. code-block:: idris--    (!) : Eff a xs -> a--Note, however, that it is not really a function, merely syntax! In-practice, a subexpression ``!expr`` will lift ``expr`` as high as-possible within its current scope, bind it to a fresh name ``x``, and-replace ``!expr`` with ``x``. Expressions are lifted depth first, left-to right. In practice, ``!``-notation allows us to program in a more-direct style, while still giving a notational clue as to which-expressions are effectful.--For example, the expression:--.. code-block:: idris--    let y = 42 in f !(g !(print y) !x)--is lifted to:--.. code-block:: idris--    let y = 42 in do y' <- print y-                     x' <- x-                     g' <- g y' x'-                     f g'--The Type ``Eff``-================--Underneath, ``Eff`` is an overloaded function which translates to an-underlying type ``EffM``:--.. code-block:: idris--    EffM : (m : Type -> Type) -> (t : Type)-            -> (List EFFECT)-            -> (t -> List EFFECT) -> Type--This is more general than the types we have been writing so far. It is-parameterised over an underlying computation context ``m``, a-result type ``t`` as we have already seen, as well as a ``List EFFECT`` and a-function type ``t -> List EFFECT``.--These additional parameters are the list of *input* effects, and a-list of *output* effects, computed from the result of an effectful-operation.  That is: running an effectful program can change the set-of effects available! This is a particularly powerful idea, and we-will see its consequences in more detail later. Some examples of-operations which can change the set of available effects are:--- Updating a state containing a dependent type (for example adding an element to a vector).--- Opening a file for reading is an effect, but whether the file really-  *is* open afterwards depends on whether the file was successfully-  opened.--- Closing a file means that reading from the file should no longer be-  possible.--While powerful, this can make uses of the ``EffM`` type hard to read.-Therefore the library provides an overloaded function ``Eff``-There are the following three versions:--.. code-block:: idris--    SimpleEff.Eff : (t : Type) -> (input_effs : List EFFECT) -> Type-    TransEff.Eff  : (t : Type) -> (input_effs : List EFFECT) ->-                                  (output_effs : List EFFECT) -> Type-    DepEff.Eff    : (t : Type) -> (input_effs : List EFFECT) ->-                                  (output_effs_fn : t -> List EFFECT) -> Type--So far, we have used only the first version, ``SimpleEff.Eff``, which-is defined as follows:--.. code-block:: idris--    Eff : (x : Type) -> (es : List EFFECT) -> Type-    Eff x es = {m : Type -> Type} -> EffM m x es (\v => es)--i.e. the set of effects remains the same on output. This suffices for-the ``STATE`` example we have seen so far, and for many useful-side-effecting programs. We could also have written ``treeTagAux``-with the expanded type:--.. code-block:: idris--    treeTagAux : BTree a ->-                 EffM m (BTree (Int, a)) [STATE Int] (\x => [STATE Int])--Later, we will see programs which update effects:--.. code-block:: idris--    Eff a xs xs'--which is expanded to--.. code-block:: idris--    EffM m a xs (\_ => xs')--i.e. the set of effects is updated to ``xs’`` (think of a transition-in a state machine). There is, for example, a version of ``put`` which-updates the type of the state:--.. code-block:: idris--    putM : y -> Eff () [STATE x] [STATE y]--Also, we have:--.. code-block:: idris--    Eff t xs (\res => xs')--which is expanded to--.. code-block:: idris--    EffM m t xs (\res => xs')--i.e. the set of effects is updated according to the result of the-operation ``res``, of type ``t``.--Parameterising ``EffM`` over an underlying computation context allows us-to write effectful programs which are specific to one context, and in some-cases to write programs which *extend* the list of effects available using-the ``new`` function, though this is beyond the scope of this tutorial.--.. [1] The earlier paper [3]_ describes the essential implementation-   details, although the library presented there is an earlier version-   which is less powerful than that presented in this tutorial.--.. [2] In practice, ``’name`` simply introduces a new empty type--.. [3] Edwin Brady. 2013. Programming and reasoning with algebraic-       effects and dependent types. SIGPLAN Not. 48, 9 (September-       2013), 133-144. DOI=10.1145/2544174.2500581-       http://dl.acm.org/citation.cfm?doid=2544174.2500581----.. |image| image:: ../image/effects-tree.png-                   :width: 500px
− docs/effects/summary.rst 
@@ -1,152 +0,0 @@-.. _sect-appendix:--***************-Effects Summary-***************--This appendix gives interfaces for the core effects provided by the-library.--EXCEPTION-=========--.. code-block:: idris--    module Effect.Exception--    import Effects-    import System-    import Control.IOExcept--    EXCEPTION : Type -> EFFECT--    raise : a -> Eff b [EXCEPTION a]--    Handler (Exception a) Maybe where { ... }-    Handler (Exception a) List where { ... }-    Handler (Exception a) (Either a) where { ... }-    Handler (Exception a) (IOExcept a) where { ... }-    Show a => Handler (Exception a) IO where { ... }--FILE\_IO-========--.. code-block:: idris--    module Effect.File--    import Effects-    import Control.IOExcept--    FILE_IO : Type -> EFFECT--    data OpenFile : Mode -> Type--    open : (fname : String)-           -> (m : Mode)-           -> Eff Bool [FILE_IO ()] -                       (\res => [FILE_IO (case res of-                                               True => OpenFile m-                                               False => ())])-    close : Eff () [FILE_IO (OpenFile m)] [FILE_IO ()]--    readLine  : Eff String [FILE_IO (OpenFile Read)]-    writeLine : String -> Eff () [FILE_IO (OpenFile Write)]-    eof       : Eff Bool [FILE_IO (OpenFile Read)]--    Handler FileIO IO where { ... }--RND-===--.. code-block:: idris--    module Effect.Random--    import Effects-    import Data.Vect-    import Data.Fin--    RND : EFFECT--    srand  : Integer ->            Eff m () [RND]-    rndInt : Integer -> Integer -> Eff m Integer [RND]-    rndFin : (k : Nat) ->          Eff m (Fin (S k)) [RND]--    Handler Random m where { ... }--SELECT-======--.. code-block:: idris--    module Effect.Select--    import Effects--    SELECT : EFFECT--    select : List a -> Eff m a [SELECT]--    Handler Selection Maybe where { ... }-    Handler Selection List where { ... }--STATE-=====--.. code-block:: idris--    module Effect.State--    import Effects--    STATE : Type -> EFFECT--    get    :             Eff m x [STATE x]-    put    : x ->        Eff m () [STATE x]-    putM   : y ->        Eff m () [STATE x] [STATE y]-    update : (x -> x) -> Eff m () [STATE x]--    Handler State m where { ... }--STDIO-=====--.. code-block:: idris--    module Effect.StdIO--    import Effects-    import Control.IOExcept--    STDIO : EFFECT--    putChar  : Handler StdIO m => Char ->   Eff m () [STDIO]-    putStr   : Handler StdIO m => String -> Eff m () [STDIO]-    putStrLn : Handler StdIO m => String -> Eff m () [STDIO]--    getStr   : Handler StdIO m =>           Eff m String [STDIO]-    getChar  : Handler StdIO m =>           Eff m Char [STDIO]--    Handler StdIO IO where { ... }-    Handler StdIO (IOExcept a) where { ... }--SYSTEM-======--.. code-block:: idris--    module Effect.System--    import Effects-    import System-    import Control.IOExcept--    SYSTEM : EFFECT--    getArgs : Handler System e =>           Eff e (List String) [SYSTEM]-    time    : Handler System e =>           Eff e Int [SYSTEM]-    getEnv  : Handler System e => String -> Eff e (Maybe String) [SYSTEM]--    Handler System IO where { ... }-    Handler System (IOExcept a) where { ... }
− docs/faq/faq.rst 
@@ -1,329 +0,0 @@-**************************-Frequently Asked Questions-**************************--What are the differences between Agda and Idris?-================================================--Like Idris, Agda is a functional language with dependent types, supporting-dependent pattern matching. Both can be used for writing programs and proofs.-However, Idris has been designed from the start to emphasise general purpose-programming rather than theorem proving. As such, it supports interoperability-with systems libraries and C programs, and language constructs for-domain specific language implementation. It also includes higher level-programming constructs such as interfaces (similar to type classes) and do notation.--Idris supports multiple back ends (C and JavaScript by default, with the-ability to add more via plugins) and has a reference run time system, written-in C, with a garbage collector and built-in message passing concurrency.---Is Idris production ready?-==========================--Idris is primarily a research tool for exploring the possibilities of software-development with dependent types, meaning that the primary goal is not (yet) to-make a system which could be used in production. As such, there are a few rough-corners, and lots of missing libraries. Nobody is working on Idris full time,-and we don't have the resources at the moment to polish the system on our own.-Therefore, we don't recommend building your business around it!--Having said that, contributions which help towards making Idris suitable-for use in production would be very welcome - this includes (but is not-limited to) extra library support, polishing the run-time system (and ensuring-it is robust), providing and maintaining a JVM back end, etc.--Is there some documentation for the standard lib? List of functions?-=====================================================================--API documentation for the shipped packages is listed on `the-documentation page <http://www.idris-lang.org/documentation/>`_.--Unfortunately, the default prelude and shipped packages for `Idris`-are not necessarily complete with regards to documentation.  Other-ways to find functions include:--+ REPL commands:--  + Use `:apropos` to search for text in documentation and function names.-  + Use `:search` to search for functions of a given type.-  + Use `:browse` to list the contents of a given namespace.--+ Use the REPL's auto-complete functionality.-+ Grep through the source code in `libs/`--If you find that the shipped packages are lacking in documentation,-please feel free to write some. Or bug someone to do so.  `Idris` has-syntax for providing rich documentation, which is then viewable using-the `:doc` command and listed in generated HTML API documentation.---Why does Idris use eager evaluation rather than lazy?-=====================================================--Idris uses eager evaluation for more predictable performance, in particular-because one of the longer term goals is to be able to write efficient and-verified low level code such as device drivers and network infrastructure.-Furthermore, the Idris type system allows us to state precisely the type-of each value, and therefore the run-time form of each value. In a lazy-language, consider a value of type ``Int``:--.. code-block:: idris--    thing : Int--What is the representation of ``thing`` at run-time? Is it a bit pattern-representing an integer, or is it a pointer to some code which will compute-an integer? In Idris, we have decided that we would like to make this-distinction precise, in the type:--.. code-block:: idris--    thing_val : Int-    thing_comp : Lazy Int--Here, it is clear from the type that ``thing_val`` is guaranteed to be a-concrete ``Int``, whereas ``thing_comp`` is a computation which will produce an-``Int``.---How can I make lazy control structures?-=======================================--You can make control structures using the special Lazy type. For-example, ``if...then...else...`` in Idris expands to an application of-a function named ``ifThenElse``. The default implementation for-Booleans is defined as follows in the library:--.. code-block:: idris--    ifThenElse : Bool -> (t : Lazy a) -> (e : Lazy a) -> a-    ifThenElse True  t e = t-    ifThenElse False t e = e--The type ``Lazy a`` for ``t`` and ``e`` indicates that those arguments will-only be evaluated if they are used, that is, they are evaluated lazily.---Evaluation at the REPL doesn't behave as I expect. What's going on?-===================================================================--Being a fully dependently typed language, Idris has two phases where it-evaluates things, compile-time and run-time. At compile-time it will only-evaluate things which it knows to be total (i.e. terminating and covering all-possible inputs) in order to keep type checking decidable. The compile-time-evaluator is part of the Idris kernel, and is implemented in Haskell using a-HOAS (higher order abstract syntax) style representation of values. Since-everything is known to have a normal form here, the evaluation strategy doesn't-actually matter because either way it will get the same answer, and in practice-it will do whatever the Haskell run-time system chooses to do.--The REPL, for convenience, uses the compile-time notion of evaluation. As well-as being easier to implement (because we have the evaluator available) this can-be very useful to show how terms evaluate in the type checker. So you can see-the difference between:--.. code-block:: idris--    Idris> \n, m => (S n) + m-    \n => \m => S (plus n m) : Nat -> Nat -> Nat--    Idris> \n, m => n + (S m)-    \n => \m => plus n (S m) : Nat -> Nat -> Nat---Why can't I use a function with no arguments in a type?-=======================================================--If you use a name in a type which begins with a lower case letter, and which is-not applied to any arguments, then Idris will treat it as an implicitly-bound argument. For example:--.. code-block:: idris--    append : Vect n ty -> Vect m ty -> Vect (n + m) ty--Here, ``n``, ``m``, and ``ty`` are implicitly bound. This rule applies even-if there are functions defined elsewhere with any of these names. For example,-you may also have:--.. code-block:: idris--    ty : Type-    ty = String--Even in this case, ``ty`` is still considered implicitly bound in the definition-of ``append``, rather than making the type of ``append`` equivalent to...--.. code-block:: idris--    append : Vect n String -> Vect m String -> Vect (n + m) String--...which is probably not what was intended!  The reason for this rule is so-that it is clear just from looking at the type of ``append``, and no other-context, what the implicitly bound names are.--If you want to use an unapplied name in a type, you have two options. You-can either explicitly qualify it, for example, if ``ty`` is defined in the-namespace ``Main`` you can do the following:--.. code-block:: idris--    append : Vect n Main.ty -> Vect m Main.ty -> Vect (n + m) Main.ty--Alternatively, you can use a name which does not begin with a lower case-letter, which will never be implicitly bound:--.. code-block:: idris--    Ty : Type-    Ty = String--    append : Vect n Ty -> Vect m Ty -> Vect (n + m) Ty--As a convention, if a name is intended to be used as a type synonym, it is-best for it to begin with a capital letter to avoid this restriction.---I have an obviously terminating program, but Idris says it possibly isn't total. Why is that?-=============================================================================================--Idris can't decide in general whether a program is terminating due to-the undecidability of the `Halting Problem-<https://en.wikipedia.org/wiki/Halting_problem>`_. It is possible, however,-to identify some programs which are definitely terminating. Idris does this-using "size change termination" which looks for recursive paths from a-function back to itself. On such a path, there must be at least one-argument which converges to a base case.--- Mutually recursive functions are supported--- However, all functions on the path must be fully applied. In particular,-  higher order applications are not supported--- Idris identifies arguments which converge to a base case by looking for-  recursive calls to syntactically smaller arguments of inputs. e.g.-  ``k`` is syntactically smaller than ``S (S k)`` because ``k`` is a-  subterm of ``S (S k)``, but ``(k, k)`` is-  not syntactically smaller than ``(S k, S k)``.--If you have a function which you believe to be terminating, but Idris does-not, you can either restructure the program, or use the ``assert_total``-function.---When will Idris be self-hosting?-================================--It’s not a priority, though not a bad idea in the long run. It would-be a worthwhile effort in the short term to implement libraries in-Idris to support self-hosting, such as argument parsing and a-POSIX-compliant library for system interaction.--Does Idris have universe polymorphism? What is the type of ``Type``?-====================================================================--Rather than universe polymorphism, Idris has a cumulative hierarchy of-universes; ``Type : Type 1``, ``Type 1 : Type 2``, etc.-Cumulativity means that if ``x : Type n`` and ``n <= m``, then-``x : Type m``. Universe levels are always inferred by Idris, and-cannot be specified explicitly. The REPL command ``:type Type 1`` will-result in an error, as will attempting to specify the universe level-of any type.---Why does Idris use ``Double`` instead of ``Float64``?-=====================================================--Historically the C language and many other languages have used the-names ``Float`` and ``Double`` to represent floating point numbers of-size 32 and 64 respectively.  Newer languages such as Rust and Julia-have begun to follow the naming scheme described in `IEEE Standard for-Floating-Point Arithmetic (IEEE 754)-<https://en.wikipedia.org/wiki/IEEE_floating_point>`_. This describes-single and double precision numbers as ``Float32`` and ``Float64``;-the size is described in the type name.--Due to developer familiarity with the older naming convention, and-choice by the developers of Idris, Idris uses the C style convention.-That is, the name ``Double`` is used to describe double precision-numbers, and Idris does not support 32 bit floats at present.---What is -ffreestanding?-=======================--The freestanding flag is used to build Idris binaries which have their-libs and compiler in a relative path. This is useful for building binaries-where the install directory is unknown at build time. When passing this-flag, the IDRIS_LIB_DIR environment variable needs to be set to the path-where the Idris libs reside relative to the idris executable. The-IDRIS_TOOLCHAIN_DIR environment variable is optional, if that is set,-Idris will use that path to find the C compiler. For example:--::--   IDRIS_LIB_DIR="./libs" \-   IDRIS_TOOLCHAIN_DIR="./mingw/bin" \-   CABALFLAGS="-fffi -ffreestanding -frelease" \-   make---What does the name “Idris” mean?-================================--British people of a certain age may be familiar with this-`singing dragon <https://www.youtube.com/watch?v=G5ZMNyscPcg>`_. If-that doesn’t help, maybe you can invent a suitable acronym :-) .---Will there be support for Unicode characters for operators?-===========================================================--There are several reasons why we should not support Unicode operators:--- It's hard to type (this is important if you're using someone else's code, for-  example). Various editors have their own input methods, but you have to know-  what they are.--- Not every piece of software easily supports it. Rendering issues have been-  noted on some mobile email clients, terminal-based IRC clients, web browsers,-  etc. There are ways to resolve these rendering issues but they provide a-  barrier to entry to using Idris.--- Even if we leave it out of the standard library (which we will in any case!)-  as soon as people start using it in their library code, others have to deal-  with it.--- Too many characters look too similar. We had enough trouble with confusion-  between 0 and O without worrying about all the different kinds of colons and-  brackets.--- There seems to be a tendency to go over the top with use of Unicode. For-  example, using sharp and flat for delay and force (or is it the other way-  around?) in Agda seems gratuitous. We don't want to encourage this sort of-  thing, when words are often better.--With care, Unicode operators can make things look pretty but so can ``lhs2TeX``.-Perhaps in a few years time things will be different and software will cope-better and it will make sense to revisit this. For now, however, Idris will not-be offering arbitrary Unicode symbols in operators.--This seems like an instance of `Wadler's-Law <http://www.haskell.org/haskellwiki/Wadler%27s_Law>`__ in action.--This answer is based on Edwin Brady's response in the following-`pull request <https://github.com/idris-lang/Idris-dev/pull/694#issuecomment-29559291>`_.--Where can I find the community standards for the Idris community?-==================================================================--The Idris Community Standards are stated `here-<https://www.idris-lang.org/documentation/community-standards/>`_ .--Where can I find more answers?-==============================--There is an `Unofficial FAQ-<https://github.com/idris-lang/Idris-dev/wiki/Unofficial-FAQ>`_ on the wiki on-GitHub which answers more technical questions and may be updated more often.
− docs/guides/index.rst 
@@ -1,22 +0,0 @@-.. _guides-index:--################################-Tutorials on the Idris Language-################################--Tutorials submitted by community members.--.. note::-   The documentation for Idris has been published under the Creative-   Commons CC0 License. As such to the extent possible under law, *The-   Idris Community* has waived all copyright and related or neighboring-   rights to Documentation for Idris.--   More information concerning the CC0 can be found online at: http://creativecommons.org/publicdomain/zero/1.0/---.. toctree::-   :maxdepth: 1--   type-providers-ffi-   theorem-prover
− docs/guides/theorem-prover.rst 
@@ -1,217 +0,0 @@-*******************************-The Interactive Theorem Prover-*******************************--This short guide contributed by a community member illustrates how to prove associativity of addition on ``Nat`` using the interactive theorem prover.--First we define a module ``Foo.idr``--.. code-block:: idris--    module Foo--    plusAssoc : plus n (plus m o) = plus (plus n m) o-    plusAssoc = ?rhs--We wish to perform induction on ``n``. First we load the file into the Idris ``REPL`` as follows::--    $ idris Foo.idr--We will be given the following prompt, in future releases the version string will differ::--         ____    __     _-        /  _/___/ /____(_)____-        / // __  / ___/ / ___/     Version 0.9.18.1-      _/ // /_/ / /  / (__  )      http://www.idris-lang.org/-     /___/\__,_/_/  /_/____/       Type :? for help--    Idris is free software with ABSOLUTELY NO WARRANTY.-    For details type :warranty.-    Type checking ./Foo.idr-    Metavariables: Foo.rhs-    *Foo>---Explore the Context-====================--We start the interactive session by asking Idris to prove the-hole ``rhs`` using the command ``:p rhs``. Idris by default-will show us the initial context. This looks as follows::--    *Foo> :p rhs-    ----------                 Goal:                  -----------    { hole 0 }:-     (n : Nat) ->-     (m : Nat) ->-     (o : Nat) ->-     plus n (plus m o) = plus (plus n m) o--Application of Intros-=====================--We first apply the ``intros`` tactic::--    -Foo.rhs> intros-    ----------              Other goals:              -----------    { hole 2 }-    { hole 1 }-    { hole 0 }-    ----------              Assumptions:              -----------     n : Nat-     m : Nat-     o : Nat-    ----------                 Goal:                  -----------    { hole 3 }:-     plus n (plus m o) = plus (plus n m) o--Induction on ``n``-==================--Then apply ``induction`` on to ``n``::--    -Foo.rhs> induction n-    ----------              Other goals:              -----------    elim_S0-    { hole 2 }-    { hole 1 }-    { hole 0 }-    ----------              Assumptions:              -----------     n : Nat-     m : Nat-     o : Nat-    ----------                 Goal:                  -----------    elim_Z0:-     plus Z (plus m o) = plus (plus Z m) o---Compute-=======--::--    -Foo.rhs> compute-    ----------              Other goals:              -----------    elim_S0-    { hole 2 }-    { hole 1 }-    { hole 0 }-    ----------              Assumptions:              -----------     n : Nat-     m : Nat-     o : Nat-    ----------                 Goal:                  -----------    elim_Z0:-     plus m o = plus m o--Trivial-=======--::--    -Foo.rhs> trivial-    ----------              Other goals:              -----------    { hole 2 }-    { hole 1 }-    { hole 0 }-    ----------              Assumptions:              -----------     n : Nat-     m : Nat-     o : Nat-    ----------                 Goal:                  -----------    elim_S0:-     (n__0 : Nat) ->-     (plus n__0 (plus m o) = plus (plus n__0 m) o) ->-     plus (S n__0) (plus m o) = plus (plus (S n__0) m) o--Intros-======--::--    -Foo.rhs> intros-    ----------              Other goals:              -----------    { hole 4 }-    elim_S0-    { hole 2 }-    { hole 1 }-    { hole 0 }-    ----------              Assumptions:              -----------     n : Nat-     m : Nat-     o : Nat-     n__0 : Nat-     ihn__0 : plus n__0 (plus m o) = plus (plus n__0 m) o-    ----------                 Goal:                  -----------    { hole 5 }:-     plus (S n__0) (plus m o) = plus (plus (S n__0) m) o---Compute-=======--::--    -Foo.rhs> compute-    ----------              Other goals:              -----------    { hole 4 }-    elim_S0-    { hole 2 }-    { hole 1 }-    { hole 0 }-    ----------              Assumptions:              -----------     n : Nat-     m : Nat-     o : Nat-     n__0 : Nat-     ihn__0 : plus n__0 (plus m o) = plus (plus n__0 m) o-    ----------                 Goal:                  -----------    { hole 5 }:-     S (plus n__0 (plus m o)) = S (plus (plus n__0 m) o)---Rewrite-=======--::--    -Foo.rhs> rewrite ihn__0-    ----------              Other goals:              -----------    { hole 5 }-    { hole 4 }-    elim_S0-    { hole 2 }-    { hole 1 }-    { hole 0 }-    ----------              Assumptions:              -----------     n : Nat-     m : Nat-     o : Nat-     n__0 : Nat-     ihn__0 : plus n__0 (plus m o) = plus (plus n__0 m) o-    ----------                 Goal:                  -----------    { hole 6 }:-     S (plus n__0 (plus m o)) = S (plus n__0 (plus m o))--Trivial-=======--::--    -Foo.rhs> trivial-    rhs: No more goals.-    -Foo.rhs> qed-    Proof completed!-    Foo.rhs = proof-      intros-      induction n-      compute-      trivial-      intros-      compute-      rewrite ihn__0-      trivial--Two goals were created: one for ``Z`` and one for ``S``.-Here we have proven associativity, and assembled a tactic based proof script.-This proof script can be added to ``Foo.idr``.
− docs/guides/type-providers-ffi.rst 
@@ -1,247 +0,0 @@-***********************-Type Providers in Idris-***********************--`Type providers in Idris-<http://www.davidchristiansen.dk/pubs/dependent-type-providers.pdf>`__-are simple enough, but there are a few caveats to using them that it-would be worthwhile to go through the basic steps. We also go over-foreign functions, because these will often be used with type-providers.--The use case-============--First, let's talk about *why* we might want type providers. There are-a number of reasons to use them and there are other examples available-around the net, but in this tutorial we'll be using them to port C's-``struct stat`` to Idris.--Why do we need type providers? Well, Idris's FFI needs to know the-types of the things it passes to and from C, but the fields of a-``struct stat`` are implementation-dependent types that cannot be-relied upon. We don't just want to hard-code these types into our-program... so we'll use a type provider to find them at compile time!--A simple example-================--First, let's go over a basic usage of type providers, because foreign-functions can be confusing but it's important to remember that-providers themselves are simple.--A type provider is simply an IO action that returns a value of this-type:--.. code-block:: idris--    data Provider a = Provide a | Error String--Looks familiar? ``Provider`` is just ``Either a String``, given a-slightly more descriptive name.--Remember though, type providers we use in our program must be IO-actions. Let's write a simple one now:--.. code-block:: idris--    module Provider-    -- Asks nicely for the user to supply the size of C's size_t type on this-    -- machine-    getSizeT : IO (Provider Int)-    getSizeT = do-      putStrLn "I'm sorry, I don't know how big size_t is. Can you tell me, in bytes?"-      resp <- getLine-      case readInt resp of-         Just sizeTSize => pure (Provide sizeTSize)-         Nothing => pure (Error "I'm sorry, I don't understand.")-    -- the readInt function is left as an exercise--We assume that whoever's compiling the library knows the size of-``size_t``, so we'll just ask them! (Don't worry, we'll get it-ourselves later.) Then, if their response can be converted to an-integer, we present ``Provide sizeTSize`` as the result of our IO-action; or if it can't, we signal a failure. (This will then become a-compile-time error.)--Now we can use this IO action as a type provider:--.. code-block:: idris--    module Main-    -- to gain access to the IO action we're using as a provider-    import Provider--    -- TypeProviders is an extension, so we'll enable it-    %language TypeProviders--    -- And finally, use the provider!-    -- Note that the parentheses are mandatory.-    %provide (sizeTSize : Int) with getSizeT--    -- From now on it's just a normal program where `sizeTSize` is available-    -- as a top-level constant-    main : IO ()-    main = do-      putStr "Look! I figured out how big size_t is! It's "-      putStr (show sizeTSize)-      putStr " bytes!"--Yay! We... asked the user something at compile time? That's not very-good, actually. Our library is going to be difficult to compile! This-is hardly a step up from having them edit in the size of ``size_t``-themselves!--Don't worry, there's a better way.--Foreign Functions-=================--It's actually pretty easy to write a C function that figures out the-size of ``size_t``:--.. code:: c--    int sizeof_size_t() { return sizeof(size_t); }--(Why an int and not a ``size_t``? The FFI needs to know how to receive-the return value of this function and translate it into an Idris-value. If we knew how to do this for values of C type ``size_t``, we-wouldn't need to write this function at all! If we really wanted to be-safe from overflow, we could use an array of multiple integers, but-the SIZE of ``size_t`` is never going to be a 65535 byte integer.)--So now we can get the size of ``size_t`` as long as we're in C code.-We'd like to be able to use this from Idris. Can we do this? It turns-out we can.--``foreign``----------------With foreign, we can turn a C function into an IO action. It works-like this:--.. code-block:: idris--    getSizeT : IO Int-    getSizeT = foreign FFI_C "sizeof_size_t" (IO Int)--Pretty simple. ``foreign`` takes a specification of what function it-needs to call and that function's return type.--Running foreign functions----------------------------This is all well and good for writing code that will typecheck. To-actually run the code, we'll need to do just a bit more work. Exactly-what we need to do depends on whether we want to interpret or compile-our code.--In the interpreter---------------------If we want to call our foreign functions from interpreted code (such-as the REPL or a type provider), we need to dynamically link a library-containing the symbols we need. This is pretty easy to do with the-``%dynamic`` directive:--.. code-block:: idris--    %dynamic "./filename.so"--Note that the leading "./" is important: currently, the string you-provide is interpreted as by ``dlopen()``, which on Unix does not search-in the current directory by default. If you use the "./", the library-will be searched for in the directory from which you run idris (*not*-the location of the file you're running!). Of course, if you're using-functions from an installed library rather than something you wrote-yourself, the "./" is not necessary.--In an executable-------------------If we want to run our code from an executable, we can statically link-instead. We'll use the ``%include`` and ``%link`` directives:--.. code-block:: idris--    %include C "filename.h"-    %link C "filename.o"--Note the extra argument to the directive! We specify that we're-linking a C header and library. Also, unlike ``%dynamic``, these-directives search in the current directory by default. (That is, the-directory from which we run idris.)--Putting it all together-=======================--So, at the beginning of this article I said we'd use type providers to-port ``struct stat`` to Idris. The relevant part is just translating-all the mysterious typedef'd C types into Idris types, and that's what-we'll do here.--First, let's write a C file containing functions that we'll bind to.--.. code-block:: c--    /* stattypes.c */-    #include <sys/stat.h>--    int sizeof_dev_t() { return sizeof(dev_t); }-    int sizeof_ino_t() { return sizeof(ino_t); }-    /* lots more functions like this */--Next, an Idris file to define our providers:--.. code-block:: idris--    -- Providers.idr-    module Providers--    %dynamic "./stattypes.so"-    %access export--    sizeOfDevT : IO Int-    sizeOfDevT = foreign FFI_C "sizeof_dev_t" (IO Int)-    {- lots of similar functions -}--    -- Indicates how many bits are used to represent various system-    -- stat types.-    public export-    data BitWidth = B8 | B16 | B32 | B64--    Show BitWidth where-      show B8 = "8 bits"-      show B16 = "16 bits"-      show B32 = "32 bits"-      show B64 = "64 bits"--    -- Now we have an integer, but we want a Provider BitWidth.-    -- Since our sizeOf* functions are ordinary IO actions, we-    -- can just map over them.-    bytesToType : Int -> Provider BitWidth-    bytesToType 1 = Provide B8  -- "8 bit value"-    bytesToType 2 = Provide B16-    bytesToType 4 = Provide B32-    bytesToType 8 = Provide B64-    bytesToType _ = Error "Unrecognised integral type."--    getDevT : IO (Provider BitWidth)-    getDevT = map bytesToType sizeOfDevT-    {- lots of similar functions -}--Finally, we'll write one more idris file where we use the type-providers:--.. code-block:: idris--    -- Main.idr-    module Main-    import Providers-    %language TypeProviders-    %provide (DevTBitWidth : BitWidth) with getDevT--    -- We can now use DevTBitWidth in our program!-    main : IO ()-    main = putStrLn $ "size of dev_t: " ++ show DevTBitWidth
− docs/image/effects-tree.png

binary file changed (37773 → absent bytes)

− docs/image/login.png

binary file changed (10155 → absent bytes)

− docs/image/netstate.png

binary file changed (17544 → absent bytes)

− docs/image/plusReducesProof.png

binary file changed (14349 → absent bytes)

− docs/image/plusReducesProof.svg 
@@ -1,339 +0,0 @@-<?xml version="1.0" encoding="UTF-8" standalone="no"?>-<!-- Created with Inkscape (http://www.inkscape.org/) -->--<svg-   xmlns:dc="http://purl.org/dc/elements/1.1/"-   xmlns:cc="http://creativecommons.org/ns#"-   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"-   xmlns:svg="http://www.w3.org/2000/svg"-   xmlns="http://www.w3.org/2000/svg"-   xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"-   xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"-   width="210mm"-   height="297mm"-   viewBox="0 0 744.09448819 1052.3622047"-   id="svg2"-   version="1.1"-   inkscape:version="0.91 r13725"-   sodipodi:docname="plusReducesProof.svg">-  <defs-     id="defs4">-    <marker-       inkscape:stockid="Arrow1Mend"-       orient="auto"-       refY="0.0"-       refX="0.0"-       id="marker6540"-       style="overflow:visible;"-       inkscape:isstock="true">-      <path-         id="path6542"-         d="M 0.0,0.0 L 5.0,-5.0 L -12.5,0.0 L 5.0,5.0 L 0.0,0.0 z "-         style="fill-rule:evenodd;stroke:#0000ff;stroke-width:1pt;stroke-opacity:1;fill:#0000ff;fill-opacity:1"-         transform="scale(0.4) rotate(180) translate(10,0)" />-    </marker>-    <marker-       inkscape:stockid="Arrow1Mend"-       orient="auto"-       refY="0.0"-       refX="0.0"-       id="marker5748"-       style="overflow:visible;"-       inkscape:isstock="true">-      <path-         id="path5750"-         d="M 0.0,0.0 L 5.0,-5.0 L -12.5,0.0 L 5.0,5.0 L 0.0,0.0 z "-         style="fill-rule:evenodd;stroke:#0000ff;stroke-width:1pt;stroke-opacity:1;fill:#0000ff;fill-opacity:1"-         transform="scale(0.4) rotate(180) translate(10,0)" />-    </marker>-    <marker-       inkscape:isstock="true"-       style="overflow:visible;"-       id="marker5154"-       refX="0.0"-       refY="0.0"-       orient="auto"-       inkscape:stockid="Arrow1Mend"-       inkscape:collect="always">-      <path-         transform="scale(0.4) rotate(180) translate(10,0)"-         style="fill-rule:evenodd;stroke:#0000ff;stroke-width:1pt;stroke-opacity:1;fill:#0000ff;fill-opacity:1"-         d="M 0.0,0.0 L 5.0,-5.0 L -12.5,0.0 L 5.0,5.0 L 0.0,0.0 z "-         id="path5156" />-    </marker>-    <marker-       inkscape:stockid="Arrow1Mend"-       orient="auto"-       refY="0.0"-       refX="0.0"-       id="Arrow1Mend"-       style="overflow:visible;"-       inkscape:isstock="true"-       inkscape:collect="always">-      <path-         id="path4189"-         d="M 0.0,0.0 L 5.0,-5.0 L -12.5,0.0 L 5.0,5.0 L 0.0,0.0 z "-         style="fill-rule:evenodd;stroke:#0000ff;stroke-width:1pt;stroke-opacity:1;fill:#0000ff;fill-opacity:1"-         transform="scale(0.4) rotate(180) translate(10,0)" />-    </marker>-  </defs>-  <sodipodi:namedview-     id="base"-     pagecolor="#ffffff"-     bordercolor="#666666"-     borderopacity="1.0"-     inkscape:pageopacity="0.0"-     inkscape:pageshadow="2"-     inkscape:zoom="1"-     inkscape:cx="397.18872"-     inkscape:cy="520"-     inkscape:document-units="px"-     inkscape:current-layer="layer1"-     showgrid="false"-     inkscape:window-width="1110"-     inkscape:window-height="1011"-     inkscape:window-x="-4"-     inkscape:window-y="0"-     inkscape:window-maximized="0" />-  <metadata-     id="metadata7">-    <rdf:RDF>-      <cc:Work-         rdf:about="">-        <dc:format>image/svg+xml</dc:format>-        <dc:type-           rdf:resource="http://purl.org/dc/dcmitype/StillImage" />-        <dc:title></dc:title>-      </cc:Work>-    </rdf:RDF>-  </metadata>-  <g-     inkscape:label="Layer 1"-     inkscape:groupmode="layer"-     id="layer1">-    <text-       xml:space="preserve"-       style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:20px;line-height:125%;font-family:sans-serif;-inkscape-font-specification:'sans-serif Bold';letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"-       x="266"-       y="225.36221"-       id="text4136"-       sodipodi:linespacing="125%"><tspan-         sodipodi:role="line"-         id="tspan4138"-         x="266"-         y="225.36221">assumptions</tspan><tspan-         sodipodi:role="line"-         x="266"-         y="250.36221"-         id="tspan4140">(context)</tspan></text>-    <text-       sodipodi:linespacing="125%"-       id="text4142"-       y="238.36221"-       x="526"-       style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:20px;line-height:125%;font-family:sans-serif;-inkscape-font-specification:'sans-serif Bold';letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;"-       xml:space="preserve"><tspan-         id="tspan4146"-         y="238.36221"-         x="526"-         sodipodi:role="line">goal</tspan></text>-    <text-       xml:space="preserve"-       style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:12.5px;line-height:125%;font-family:sans-serif;-inkscape-font-specification:'sans-serif Bold';letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"-       x="420"-       y="289.36221"-       id="text4150"-       sodipodi:linespacing="125%"><tspan-         sodipodi:role="line"-         x="420"-         y="289.36221"-         id="tspan4152">(k : Nat) -&gt; (k = plus k 0) -&gt; S k = S (plus k 0)</tspan></text>-    <path-       style="fill:none;fill-rule:evenodd;stroke:#ff0000;stroke-width:2;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;stroke-miterlimit:4;stroke-dasharray:none"-       d="m 241,262.3622 428,-1"-       id="path4154"-       inkscape:connector-curvature="0" />-    <path-       inkscape:connector-curvature="0"-       id="path4160"-       d="m 241,308.3622 428,-1"-       style="fill:none;fill-rule:evenodd;stroke:#ff0000;stroke-width:2;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />-    <text-       sodipodi:linespacing="125%"-       id="text4162"-       y="312.36221"-       x="175"-       style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:12.5px;line-height:125%;font-family:sans-serif;-inkscape-font-specification:'sans-serif Bold';letter-spacing:0px;word-spacing:0px;fill:#0000ff;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;"-       xml:space="preserve"><tspan-         id="tspan4164"-         y="312.36221"-         x="175"-         sodipodi:role="line">intro `{{k}}</tspan></text>-    <text-       sodipodi:linespacing="125%"-       id="text4166"-       y="333.36221"-       x="482"-       style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:12.5px;line-height:125%;font-family:sans-serif;-inkscape-font-specification:'sans-serif Bold';letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"-       xml:space="preserve"><tspan-         id="tspan4168"-         y="333.36221"-         x="482"-         sodipodi:role="line">(k = plus k 0) -&gt; S k = S (plus k 0)</tspan></text>-    <text-       xml:space="preserve"-       style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:12.5px;line-height:125%;font-family:sans-serif;-inkscape-font-specification:'sans-serif Bold';letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"-       x="324"-       y="334.36221"-       id="text4170"-       sodipodi:linespacing="125%"><tspan-         sodipodi:role="line"-         x="324"-         y="334.36221"-         id="tspan4172">k : Nat</tspan></text>-    <path-       style="fill:none;fill-rule:evenodd;stroke:#0000ff;stroke-width:2;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;marker-end:url(#Arrow1Mend)"-       d="m 441,294.3622 -73,30"-       id="path4174"-       inkscape:connector-curvature="0"-       sodipodi:nodetypes="cc" />-    <path-       style="fill:none;fill-rule:evenodd;stroke:#ff0000;stroke-width:2;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"-       d="m 241,352.3622 428,-1"-       id="path5134"-       inkscape:connector-curvature="0" />-    <text-       xml:space="preserve"-       style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:12.5px;line-height:125%;font-family:sans-serif;-inkscape-font-specification:'sans-serif Bold';letter-spacing:0px;word-spacing:0px;fill:#0000ff;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"-       x="171"-       y="355.36221"-       id="text5136"-       sodipodi:linespacing="125%"><tspan-         sodipodi:role="line"-         x="171"-         y="355.36221"-         id="tspan5138">intro `{{ih}}</tspan></text>-    <text-       xml:space="preserve"-       style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:12.5px;line-height:125%;font-family:sans-serif;-inkscape-font-specification:'sans-serif Bold';letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"-       x="570"-       y="372.36221"-       id="text5140"-       sodipodi:linespacing="125%"><tspan-         sodipodi:role="line"-         x="570"-         y="372.36221"-         id="tspan5142">S k = S (plus k 0)</tspan></text>-    <text-       sodipodi:linespacing="125%"-       id="text5144"-       y="378.36221"-       x="324"-       style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:12.5px;line-height:125%;font-family:sans-serif;-inkscape-font-specification:'sans-serif Bold';letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"-       xml:space="preserve"><tspan-         id="tspan5146"-         y="378.36221"-         x="324"-         sodipodi:role="line">k : Nat</tspan></text>-    <text-       sodipodi:linespacing="125%"-       id="text5150"-       y="393.36221"-       x="323"-       style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:12.5px;line-height:125%;font-family:sans-serif;-inkscape-font-specification:'sans-serif Bold';letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"-       xml:space="preserve"><tspan-         id="tspan5152"-         y="393.36221"-         x="323"-         sodipodi:role="line">ih : k = plus k 0</tspan></text>-    <path-       inkscape:connector-curvature="0"-       id="path5728"-       d="m 242,404.3622 428,-1"-       style="fill:none;fill-rule:evenodd;stroke:#ff0000;stroke-width:2;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />-    <text-       sodipodi:linespacing="125%"-       id="text5730"-       y="408.36221"-       x="109"-       style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:12.5px;line-height:125%;font-family:sans-serif;-inkscape-font-specification:'sans-serif Bold';letter-spacing:0px;word-spacing:0px;fill:#0000ff;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"-       xml:space="preserve"><tspan-         id="tspan5732"-         y="408.36221"-         x="109"-         sodipodi:role="line">rewriteWith (Var `{{ih}})</tspan></text>-    <text-       sodipodi:linespacing="125%"-       id="text5734"-       y="424.36221"-       x="587"-       style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:12.5px;line-height:125%;font-family:sans-serif;-inkscape-font-specification:'sans-serif Bold';letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"-       xml:space="preserve"><tspan-         id="tspan5736"-         y="424.36221"-         x="587"-         sodipodi:role="line">S k = S k </tspan></text>-    <text-       xml:space="preserve"-       style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:12.5px;line-height:125%;font-family:sans-serif;-inkscape-font-specification:'sans-serif Bold';letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"-       x="325"-       y="430.36221"-       id="text5738"-       sodipodi:linespacing="125%"><tspan-         sodipodi:role="line"-         x="325"-         y="430.36221"-         id="tspan5740">k : Nat</tspan></text>-    <path-       style="fill:none;fill-rule:evenodd;stroke:#0000ff;stroke-width:2;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;marker-end:url(#marker5748)"-       d="m 610,379.3622 1,29"-       id="path5742"-       inkscape:connector-curvature="0"-       sodipodi:nodetypes="cc" />-    <text-       xml:space="preserve"-       style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:12.5px;line-height:125%;font-family:sans-serif;-inkscape-font-specification:'sans-serif Bold';letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"-       x="324"-       y="445.36221"-       id="text5744"-       sodipodi:linespacing="125%"><tspan-         sodipodi:role="line"-         x="324"-         y="445.36221"-         id="tspan5746">ih : k = plus k 0</tspan></text>-    <path-       inkscape:connector-curvature="0"-       id="path7294"-       d="m 418,460.3622 -2,-199"-       style="fill:none;fill-rule:evenodd;stroke:#ff0000;stroke-width:2;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"-       sodipodi:nodetypes="cc" />-    <path-       sodipodi:nodetypes="cc"-       inkscape:connector-curvature="0"-       id="path5148"-       d="m 519,339.3622 -107,44"-       style="fill:none;fill-rule:evenodd;stroke:#0000ff;stroke-width:2;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;marker-end:url(#marker5154)" />-    <path-       style="fill:none;fill-rule:evenodd;stroke:#0000ff;stroke-width:2;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:12, 2;stroke-dashoffset:0;stroke-opacity:1"-       d="m 609,391.3622 -197,49"-       id="path6538"-       inkscape:connector-curvature="0"-       sodipodi:nodetypes="cc" />-    <path-       style="fill:none;fill-rule:evenodd;stroke:#ff0000;stroke-width:2;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"-       d="m 242,458.3622 428,-1"-       id="path7308"-       inkscape:connector-curvature="0" />-    <text-       xml:space="preserve"-       style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:12.5px;line-height:125%;font-family:sans-serif;-inkscape-font-specification:'sans-serif Bold';letter-spacing:0px;word-spacing:0px;fill:#0000ff;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"-       x="177"-       y="462.36221"-       id="text7310"-       sodipodi:linespacing="125%"><tspan-         sodipodi:role="line"-         x="177"-         y="462.36221"-         id="tspan7312">reflexivity</tspan></text>-  </g>-</svg>
− docs/index.rst 
@@ -1,28 +0,0 @@-.. Idris Manual documentation master file, created by-   sphinx-quickstart on Sat Feb 28 20:41:47 2015.-   You can adapt this file completely to your liking, but it should at least-   contain the root `toctree` directive.--Documentation for the Idris Language-====================================--.. note::--   The documentation for Idris has been published under the Creative-   Commons CC0 License. As such to the extent possible under law, *The-   Idris Community* has waived all copyright and related or neighboring-   rights to Documentation for Idris.--   More information concerning the CC0 can be found online at: http://creativecommons.org/publicdomain/zero/1.0/---.. toctree::-   :maxdepth: 1--   tutorial/index-   faq/faq-   st/index-   effects/index-   proofs/index-   reference/index-   guides/index
− docs/listing/idris-prompt-helloworld.txt 
@@ -1,15 +0,0 @@-$ idris hello.idr-     ____    __     _-    /  _/___/ /____(_)____-    / // __  / ___/ / ___/     Version 1.3.2-  _/ // /_/ / /  / (__  )      http://www.idris-lang.org/- /___/\__,_/_/  /_/____/       Type :? for help--Type checking ./hello.idr-*hello> :t main-Main.main : IO ()-*hello> :c hello-*hello> :q-Bye bye-$ ./hello-Hello world
− docs/listing/idris-prompt-interp.txt 
@@ -1,12 +0,0 @@-$ idris interp.idr-     ____    __     _-    /  _/___/ /____(_)____-    / // __  / ___/ / ___/     Version 1.3.2-  _/ // /_/ / /  / (__  )      http://www.idris-lang.org/- /___/\__,_/_/  /_/____/       Type :? for help--Type checking ./interp.idr-*interp> :exec-Enter a number: 6-720-*interp>
− docs/listing/idris-prompt-start.txt 
@@ -1,8 +0,0 @@-$ idris-    ____    __     _-   /  _/___/ /____(_)____-   / // __  / ___/ / ___/     Version 1.3.2- _/ // /_/ / /  / (__  )      http://www.idris-lang.org/-/___/\__,_/_/  /_/____/       Type :? for help--Idris>
− docs/make.bat 
@@ -1,263 +0,0 @@-@ECHO OFF--REM Command file for Sphinx documentation--if "%SPHINXBUILD%" == "" (-	set SPHINXBUILD=sphinx-build-)-set BUILDDIR=_build-set ALLSPHINXOPTS=-d %BUILDDIR%/doctrees %SPHINXOPTS% .-set I18NSPHINXOPTS=%SPHINXOPTS% .-if NOT "%PAPER%" == "" (-	set ALLSPHINXOPTS=-D latex_paper_size=%PAPER% %ALLSPHINXOPTS%-	set I18NSPHINXOPTS=-D latex_paper_size=%PAPER% %I18NSPHINXOPTS%-)--if "%1" == "" goto help--if "%1" == "help" (-	:help-	echo.Please use `make ^<target^>` where ^<target^> is one of-	echo.  html       to make standalone HTML files-	echo.  dirhtml    to make HTML files named index.html in directories-	echo.  singlehtml to make a single large HTML file-	echo.  pickle     to make pickle files-	echo.  json       to make JSON files-	echo.  htmlhelp   to make HTML files and a HTML help project-	echo.  qthelp     to make HTML files and a qthelp project-	echo.  devhelp    to make HTML files and a Devhelp project-	echo.  epub       to make an epub-	echo.  latex      to make LaTeX files, you can set PAPER=a4 or PAPER=letter-	echo.  text       to make text files-	echo.  man        to make manual pages-	echo.  texinfo    to make Texinfo files-	echo.  gettext    to make PO message catalogs-	echo.  changes    to make an overview over all changed/added/deprecated items-	echo.  xml        to make Docutils-native XML files-	echo.  pseudoxml  to make pseudoxml-XML files for display purposes-	echo.  linkcheck  to check all external links for integrity-	echo.  doctest    to run all doctests embedded in the documentation if enabled-	echo.  coverage   to run coverage check of the documentation if enabled-	goto end-)--if "%1" == "clean" (-	for /d %%i in (%BUILDDIR%\*) do rmdir /q /s %%i-	del /q /s %BUILDDIR%\*-	goto end-)---REM Check if sphinx-build is available and fallback to Python version if any-%SPHINXBUILD% 2> nul-if errorlevel 9009 goto sphinx_python-goto sphinx_ok--:sphinx_python--set SPHINXBUILD=python -m sphinx.__init__-%SPHINXBUILD% 2> nul-if errorlevel 9009 (-	echo.-	echo.The 'sphinx-build' command was not found. Make sure you have Sphinx-	echo.installed, then set the SPHINXBUILD environment variable to point-	echo.to the full path of the 'sphinx-build' executable. Alternatively you-	echo.may add the Sphinx directory to PATH.-	echo.-	echo.If you don't have Sphinx installed, grab it from-	echo.http://sphinx-doc.org/-	exit /b 1-)--:sphinx_ok---if "%1" == "html" (-	%SPHINXBUILD% -b html %ALLSPHINXOPTS% %BUILDDIR%/html-	if errorlevel 1 exit /b 1-	echo.-	echo.Build finished. The HTML pages are in %BUILDDIR%/html.-	goto end-)--if "%1" == "dirhtml" (-	%SPHINXBUILD% -b dirhtml %ALLSPHINXOPTS% %BUILDDIR%/dirhtml-	if errorlevel 1 exit /b 1-	echo.-	echo.Build finished. The HTML pages are in %BUILDDIR%/dirhtml.-	goto end-)--if "%1" == "singlehtml" (-	%SPHINXBUILD% -b singlehtml %ALLSPHINXOPTS% %BUILDDIR%/singlehtml-	if errorlevel 1 exit /b 1-	echo.-	echo.Build finished. The HTML pages are in %BUILDDIR%/singlehtml.-	goto end-)--if "%1" == "pickle" (-	%SPHINXBUILD% -b pickle %ALLSPHINXOPTS% %BUILDDIR%/pickle-	if errorlevel 1 exit /b 1-	echo.-	echo.Build finished; now you can process the pickle files.-	goto end-)--if "%1" == "json" (-	%SPHINXBUILD% -b json %ALLSPHINXOPTS% %BUILDDIR%/json-	if errorlevel 1 exit /b 1-	echo.-	echo.Build finished; now you can process the JSON files.-	goto end-)--if "%1" == "htmlhelp" (-	%SPHINXBUILD% -b htmlhelp %ALLSPHINXOPTS% %BUILDDIR%/htmlhelp-	if errorlevel 1 exit /b 1-	echo.-	echo.Build finished; now you can run HTML Help Workshop with the ^-.hhp project file in %BUILDDIR%/htmlhelp.-	goto end-)--if "%1" == "qthelp" (-	%SPHINXBUILD% -b qthelp %ALLSPHINXOPTS% %BUILDDIR%/qthelp-	if errorlevel 1 exit /b 1-	echo.-	echo.Build finished; now you can run "qcollectiongenerator" with the ^-.qhcp project file in %BUILDDIR%/qthelp, like this:-	echo.^> qcollectiongenerator %BUILDDIR%\qthelp\IdrisManual.qhcp-	echo.To view the help file:-	echo.^> assistant -collectionFile %BUILDDIR%\qthelp\IdrisManual.ghc-	goto end-)--if "%1" == "devhelp" (-	%SPHINXBUILD% -b devhelp %ALLSPHINXOPTS% %BUILDDIR%/devhelp-	if errorlevel 1 exit /b 1-	echo.-	echo.Build finished.-	goto end-)--if "%1" == "epub" (-	%SPHINXBUILD% -b epub %ALLSPHINXOPTS% %BUILDDIR%/epub-	if errorlevel 1 exit /b 1-	echo.-	echo.Build finished. The epub file is in %BUILDDIR%/epub.-	goto end-)--if "%1" == "latex" (-	%SPHINXBUILD% -b latex %ALLSPHINXOPTS% %BUILDDIR%/latex-	if errorlevel 1 exit /b 1-	echo.-	echo.Build finished; the LaTeX files are in %BUILDDIR%/latex.-	goto end-)--if "%1" == "latexpdf" (-	%SPHINXBUILD% -b latex %ALLSPHINXOPTS% %BUILDDIR%/latex-	cd %BUILDDIR%/latex-	make all-pdf-	cd %~dp0-	echo.-	echo.Build finished; the PDF files are in %BUILDDIR%/latex.-	goto end-)--if "%1" == "latexpdfja" (-	%SPHINXBUILD% -b latex %ALLSPHINXOPTS% %BUILDDIR%/latex-	cd %BUILDDIR%/latex-	make all-pdf-ja-	cd %~dp0-	echo.-	echo.Build finished; the PDF files are in %BUILDDIR%/latex.-	goto end-)--if "%1" == "text" (-	%SPHINXBUILD% -b text %ALLSPHINXOPTS% %BUILDDIR%/text-	if errorlevel 1 exit /b 1-	echo.-	echo.Build finished. The text files are in %BUILDDIR%/text.-	goto end-)--if "%1" == "man" (-	%SPHINXBUILD% -b man %ALLSPHINXOPTS% %BUILDDIR%/man-	if errorlevel 1 exit /b 1-	echo.-	echo.Build finished. The manual pages are in %BUILDDIR%/man.-	goto end-)--if "%1" == "texinfo" (-	%SPHINXBUILD% -b texinfo %ALLSPHINXOPTS% %BUILDDIR%/texinfo-	if errorlevel 1 exit /b 1-	echo.-	echo.Build finished. The Texinfo files are in %BUILDDIR%/texinfo.-	goto end-)--if "%1" == "gettext" (-	%SPHINXBUILD% -b gettext %I18NSPHINXOPTS% %BUILDDIR%/locale-	if errorlevel 1 exit /b 1-	echo.-	echo.Build finished. The message catalogs are in %BUILDDIR%/locale.-	goto end-)--if "%1" == "changes" (-	%SPHINXBUILD% -b changes %ALLSPHINXOPTS% %BUILDDIR%/changes-	if errorlevel 1 exit /b 1-	echo.-	echo.The overview file is in %BUILDDIR%/changes.-	goto end-)--if "%1" == "linkcheck" (-	%SPHINXBUILD% -b linkcheck %ALLSPHINXOPTS% %BUILDDIR%/linkcheck-	if errorlevel 1 exit /b 1-	echo.-	echo.Link check complete; look for any errors in the above output ^-or in %BUILDDIR%/linkcheck/output.txt.-	goto end-)--if "%1" == "doctest" (-	%SPHINXBUILD% -b doctest %ALLSPHINXOPTS% %BUILDDIR%/doctest-	if errorlevel 1 exit /b 1-	echo.-	echo.Testing of doctests in the sources finished, look at the ^-results in %BUILDDIR%/doctest/output.txt.-	goto end-)--if "%1" == "coverage" (-	%SPHINXBUILD% -b coverage %ALLSPHINXOPTS% %BUILDDIR%/coverage-	if errorlevel 1 exit /b 1-	echo.-	echo.Testing of coverage in the sources finished, look at the ^-results in %BUILDDIR%/coverage/python.txt.-	goto end-)--if "%1" == "xml" (-	%SPHINXBUILD% -b xml %ALLSPHINXOPTS% %BUILDDIR%/xml-	if errorlevel 1 exit /b 1-	echo.-	echo.Build finished. The XML files are in %BUILDDIR%/xml.-	goto end-)--if "%1" == "pseudoxml" (-	%SPHINXBUILD% -b pseudoxml %ALLSPHINXOPTS% %BUILDDIR%/pseudoxml-	if errorlevel 1 exit /b 1-	echo.-	echo.Build finished. The pseudo-XML files are in %BUILDDIR%/pseudoxml.-	goto end-)--:end
− docs/proofs/definitional.rst 
@@ -1,231 +0,0 @@-In order to understand how to write proofs in Idris I think its worth clarifying some fundamentals, such as,---  Propositions and judgments--  Boolean and constructive logic--  Curry-Howard correspondence--  Definitional and propositional equalities--  Axiomatic and constructive approaches--Propositions and Judgments-==========================--Propositions are the subject of our proofs, before the proof then we can't formally say if they are true or not. If the proof is successful then the result is a 'judgment'.-For instance, if the ``proposition`` is,--+-------+-| 1+1=2 |-+-------+--When we prove it, the ``judgment`` is,--+------------+-| 1+1=2 true |-+------------+--Or if the ``proposition`` is,--+-------+-| 1+1=3 |-+-------+--Obviously  we can't prove it is true, but it is still a valid proposition and perhaps we can prove it is false so the ``judgment`` is, --+-------------+-| 1+1=3 false |-+-------------+--This may seem a bit pedantic but it is important to be careful,  in mathematics not every proposition is true or false for instance, a proposition may be unproven or even unprovable.--So the logic here is different from the logic that comes from boolean algebra. In that case what is not true is false and what is not false is true. The logic we are using here does not have this 'law of excluded middle' so we have to be careful not to use it.--A false proposition is taken to be a contradiction and if we have a contradiction then we can prove anything, so we need to avoid this. Some languages, used in proof assistants, prevent contradictions but such languages cannot be Turing complete, so Idris does not prevent contradictions.--The logic we are using  is called constructive (or sometimes intuitional) because we are constructing a 'database' of judgments.--There are also many other types of logic, another important type of logic for Idris programmers is '``linear logic``' but that's not discussed on this page.--Curry-Howard correspondence-===========================--So how to we relate these proofs to Idris programs? It turns out that there is a correspondence between constructive logic and type theory. They are the same structure and we can switch backward and forward between the two notations because they are the same thing.--The way that this works is that a  proposition is a type so this,--.. code-block:: idris--   Idris> 1+1=2-   2 = 2 : Type--is a proposition and it is also a type. This is built into Idris so when an '=' equals sign appears in a function type an equality type is generated. The following will also produce an equality type:---.. code-block:: idris--   Idris> 1+1=3-   2 = 3 : Type--Both of these are valid propositions so both are valid equality types. But how do we represent true judgment, that is, how do we denote 1+1=2 is true but not 1+1=3.-A type that is true is inhabited, that is, it can be constructed. An equality type has only one constructor 'Refl' so a proof of 1+1=2 is--.. code-block:: idris--   onePlusOne : 1+1=2-   onePlusOne = Refl--So how can Refl, which is a constructor without any parameters, construct an equality type? If we type it on its own then it can't:--.. code-block:: idris--  Idris> Refl-  (input):Can't infer argument A to Refl, Can't infer argument x to Refl--So it must pattern match on its return type:--.. code-block:: idris--    Idris> the (1=1) Refl-    Refl : 1 = 1--So now that we can represent propositions as types other aspects of propositional logic can also be translated to types as follows:--+----------+-------------------+--------------------------+-|          | propositions      | example of possible type |-+----------+-------------------+--------------------------+-| A        | x=y               |                          |-+----------+-------------------+--------------------------+-| B        | y=z               |                          |-+----------+-------------------+--------------------------+-| and      | A /\ B            | Pair(x=y,y=z)            |-+----------+-------------------+--------------------------+-| or       | A \/ B            | Either(x=y,y=z)          |-+----------+-------------------+--------------------------+-| implies  | A -> B            | (x=y) -> (y=x)           |-+----------+-------------------+--------------------------+-| for all  | y=z               |                          |-+----------+-------------------+--------------------------+-| exists   | y=z               |                          |-+----------+-------------------+--------------------------+---And (conjunction)--------------------We can have a type which corresponds to conjunction:--.. code-block:: idris--   AndIntro : a -> b -> A a b--There is a built in type called 'Pair'.--Or (disjunction)-------------------We can have a type which corresponds to disjunction:--.. code-block:: idris--   data Or : Type -> Type -> Type where-   OrIntroLeft : a -> A a b-   OrIntroRight : b -> A a b--There is a built in type called 'Either'.--Definitional and Propositional Equalities-=========================================--We have seen that  we can 'prove' a type by finding a way to construct a term. In the case of equality types there is only one constructor which is 'Refl'.-We have also seen that each side of the equation does not have to be identical like '2=2'. It is enough that both sides are ``definitionaly equal`` like this:--.. code-block:: idris--   onePlusOne : 1+1=2-   onePlusOne = Refl--So both sides of this equation nomalise to 2 and so Refl will type match and the proposition is proved.--We don't have to stick to terms, can also use symbolic parameters so the following  will compile:--.. code-block:: idris--   varIdentity : m = m-   varIdentity = Refl--If a proposition/equality type is not definitionaly equal but is still true then it is ``propositionaly equal``. In this case we may still be able to prove it but some steps in the proof may require us to add something into the terms or at least to take some sideways steps to get to a proof.--Especially when working with equalities containing variable terms (inside functions) it can be hard to know which equality types are definitially equal, in this example plusReducesL is '``definitially equal``' but plusReducesR is not (although it is '``propositionaly equal``'). The only difference between them is the order of the operands.--.. code-block:: idris--   plusReducesL : (n:Nat) -> plus Z n = n-   plusReducesL n = Refl--   plusReducesR : (n:Nat) -> plus n Z = n-   plusReducesR n = Refl--plusReducesR gives the following error:---.. code-block:: idris--   - + Errors (1)-   `-- proof.idr line 6 col 17:-     When checking right hand side of plusReducesR with expected type-             plus n 0 = n--     Type mismatch between-             n = n (Type of Refl)-     and-             plus n 0 = n (Expected type)--     Specifically:-             Type mismatch between-                     n-             and-                     plus n 0--So why is 'Refl' able to prove some equality types but not others?--The first answer is that 'plus' is defined in such a way that it splits on its first argument so it is simple to prove when 0 is the first argument but not the second. So what is the general way to know if Refl will work?--If an equality type can be proved/constructed by using Refl alone it is known as a ``definitional equality``. In order to be definitinally equal both sides of the equation must normalise to unique values. That is, each step in the proof must reduce the term so each step is effectively forced.--So when we type 1+1 in Idris it is immediately converted to 2 because definitional equality is built in.--.. code-block:: idris--    Idris> 1+1-    2 : Integer--In the following pages we discuss how to resolve propositionaly equalies.--Axiomatic and Constructive Approaches-=====================================--How should we define types so that  we can do proofs on them? In the natural numbers with plus example we could have started by treating it as a group based on the plus operator. So we have axioms:---  for all x,y : ``x+y=y+x``--  for all x: ``x + 0 = x = 0 + x``--  for all x,y,z: ``(x + y) + z = x + (x + z)``--Then we can implement '+' so that it respects these axioms (presumably implemented in hardware).--These are axioms, that is a propositions/types that are asserted to be true without proof. In Idris we can use the 'postulate' keyword ---.. code-block:: idris--   commutePlus ``postulate``: x -> y -> plus x y = plus y x--Alternatively we could define the natural numbers based on Zero and Successor. The axioms above then become derived rules and we also gain the ability to do inductive proofs.--As we know, Idris uses both of these approaches with automatic coercion between them which gives the best of both worlds.--So what can we learn from this to implement out own types:---  Should we try to implement both approaches?--  Should we define our types by constructing up from primitive types?--Proof theory affects these design decisions.--
− docs/proofs/index.rst 
@@ -1,28 +0,0 @@-.. _proofs-index:--###############-Theorem Proving-###############--A tutorial on theorem proving in Idris. --.. note::--   The documentation for Idris has been published under the Creative-   Commons CC0 License. As such to the extent possible under law, *The-   Idris Community* has waived all copyright and related or neighboring-   rights to Documentation for Idris.--   More information concerning the CC0 can be found online at: http://creativecommons.org/publicdomain/zero/1.0/--.. toctree::-   :maxdepth: 1--   definitional-   pluscomm-   inductive-   patterns-   propositional-   interactive-   interactiveOld-
− docs/proofs/inductive.rst 
@@ -1,101 +0,0 @@-.. _sect-inductive:--****************-Inductive Proofs-****************--Before embarking on proving ``plus_commutes`` in Idris itself, let us-consider the overall structure of a proof of some property of natural-numbers. Recall that they are defined recursively, as follows:--.. code-block:: idris--    data Nat : Type where-         Z : Nat-         S : Nat -> Nat--A *total* function over natural numbers must both terminate, and cover-all possible inputs. Idris checks functions for totality by checking that-all inputs are covered, and that all recursive calls are on-*structurally smaller* values (so recursion will always reach a base-case). Recalling ``plus``:--.. code-block:: idris--    plus : Nat -> Nat -> Nat-    plus Z     m = m-    plus (S k) m = S (plus k m)--This is total because it covers all possible inputs (the first argument-can only be ``Z`` or ``S k`` for some ``k``, and the second argument-``m`` covers all possible ``Nat``) and in the recursive call, ``k``-is structurally smaller than ``S k`` so the first argument will always-reach the base case ``Z`` in any sequence of recursive calls.--In some sense, this resembles a mathematical proof by induction (and-this is no coincidence!). For some property ``P`` of a natural number-``x``, we can show that ``P`` holds for all ``x`` if:---  ``P`` holds for zero (the base case).---  Assuming that ``P`` holds for ``k``, we can show ``P`` also holds for-   ``S k`` (the inductive step).--In ``plus``, the property we are trying to show is somewhat trivial (for-all natural numbers ``x``, there is a ``Nat`` which need not have any-relation to ``x``). However, it still takes the form of a base case and-an inductive step. In the base case, we show that there is a ``Nat``-arising from ``plus n m`` when ``n = Z``, and in the inductive step we-show that there is a ``Nat`` arising when ``n = S k`` and we know we can-get a ``Nat`` inductively from ``plus k m``. We could even write a-function capturing all such inductive definitions:--.. code-block:: idris--    nat_induction : (P : Nat -> Type) ->             -- Property to show-                    (P Z) ->                         -- Base case-                    ((k : Nat) -> P k -> P (S k)) -> -- Inductive step-                    (x : Nat) ->                     -- Show for all x-                    P x-    nat_induction P p_Z p_S Z = p_Z-    nat_induction P p_Z p_S (S k) = p_S k (nat_induction P p_Z p_S k)--Using ``nat_induction``, we can implement an equivalent inductive-version of ``plus``:--.. code-block:: idris--    plus_ind : Nat -> Nat -> Nat-    plus_ind n m-       = nat_induction (\x => Nat)-                       m                      -- Base case, plus_ind Z m-                       (\k, k_rec => S k_rec) -- Inductive step plus_ind (S k) m-                                              -- where k_rec = plus_ind k m-                       n--To prove that ``plus n m = plus m n`` for all natural numbers ``n`` and-``m``, we can also use induction. Either we can fix ``m`` and perform-induction on ``n``, or vice versa. We can sketch an outline of a proof;-performing induction on ``n``, we have:---  Property ``P`` is ``\x => plus x m = plus m x``.---  Show that ``P`` holds in the base case and inductive step:--   -  | Base case: ``P Z``, i.e.-      | ``plus Z m = plus m Z``, which reduces to-      | ``m = plus m Z`` due to the definition of ``plus``.--   -  | Inductive step: Inductively, we know that ``P k`` holds for a specific, fixed ``k``, i.e.-      | ``plus k m = plus m k`` (the induction hypothesis). Given this, show ``P (S k)``, i.e.-      | ``plus (S k) m = plus m (S k)``, which reduces to-      | ``S (plus k m) = plus m (S k)``. From the induction hypothesis, we can rewrite this to-      | ``S (plus m k) = plus m (S k)``.--To complete the proof we therefore need to show that ``m = plus m Z``-for all natural numbers ``m``, and that ``S (plus m k) = plus m (S k)``-for all natural numbers ``m`` and ``k``. Each of these can also be-proved by induction, this time on ``m``.--We are now ready to embark on a proof of commutativity of ``plus``-formally in Idris.
− docs/proofs/interactive.rst 
@@ -1,296 +0,0 @@-***************************-Interactive Theorem Proving-***************************--Idris supports interactive theorem proving via elaborator reflection.--:ref:`elaborator-reflection` is also used to convert high-level Idris code into-the core language and for customising the language. Here we show how to use it-to interactively construct proofs.--The primary purpose of the elaboration mechanism is to elaborate Idris and so it-is not optimised to work as a proof assistant, however it can interactively-construct proofs as described on this page.--Elab and Pruviloj Libraries-===========================--Elaborator reflection is defined in prelude/Language/Reflection/Elab.idr-and pruviloj is defined in Idris-dev/libs/pruviloj/--``Elab`` defines the basics such as: solve, attack, intro, compute,-rewriteWith and others.-``pruviloj`` defines some more advanced derived commands such as:-reflexivity and others.--To use ``pruviloj`` call Idris with the "-p pruviloj" option and add:--.. code-block:: idris--    import Pruviloj-    import Pruviloj.Induction--to the top of your file.--It is useful to get the docs at the REPL by using the ``:doc`` command, and-search the docstrings using ``:apropos``. So to introduce the functions from-Elab and Pruviloj, that we will need for the following example, here are-their docstrings:--.. code-block:: idris--    *plusReducesZ> :doc solve-    Language.Reflection.Elab.Tactics.solve : Elab ()-        Substitute a guess into a hole.--.. code-block:: idris--    *plusReducesZ> :doc attack-    Language.Reflection.Elab.Tactics.attack : Elab ()-        Convert a hole to make it suitable for bindings - that is, transform-        it such that it has the form ?h : t . h as opposed to ?h : t . f h.--        The binding tactics require that a hole be directly under its binding,-        or else the scopes of the generated terms won't make sense. This-        tactic creates a new hole of the proper form, and points the old hole-        at it.--.. code-block:: idris--    *plusReducesZ> :doc intro-    Language.Reflection.Elab.Tactics.intro : (n : TTName) -> Elab ()-        Introduce a lambda binding around the current hole and focus on the-        body. Requires that the hole be in binding form (use attack).-        Arguments:-            n : TTName  -- the name to use for the argument--.. code-block:: idris--    *plusReducesZ> :doc compute-    Language.Reflection.Elab.Tactics.compute : Elab ()-        Normalise the goal.--.. code-block:: idris--    *plusReducesZ> :doc rewriteWith-    Language.Reflection.Elab.Tactics.rewriteWith : Raw -> Elab ()-        Attempt to rewrite the goal using an equality.--        The tactic searches the goal for applicable subterms, and constructs a-        context for replace using them. In some cases, this is not possible,-        and replace must be called manually with an appropriate context.--        Because this tactic internally introduces a let binding, it requires-        that the hole be immediately under its binder (use attack if it might-        not be).--Here is the command from pruviloj that we will need for the example on-this page:--.. code-block:: idris--    *plusReducesZ> :doc reflexivity-    Pruviloj.Core.reflexivity : Elab ()-        A special-purpose tactic that attempts to solve a goal using Refl.-        This is useful for ensuring that goals in fact are trivial when-        developing or testing other tactics; otherwise, consider using search.--Interactive Example: plusReduces-================================--One way to write proofs interactively is to write the general *structure* of-the proof, and use the interactive mode to complete the details.-Consider the following definition, proved in :ref:`sect-theorems`:--.. code-block:: idris--    plusReduces : (n:Nat) -> plus Z n = n--We’ll be constructing the proof by *induction*, so we write the cases for ``Z``-and ``S``, with a recursive call in the ``S`` case giving the inductive-hypothesis, and insert *holes* for the rest of the definition:--.. code-block:: idris--    import Pruviloj-    import Pruviloj.Induction--    plusReducesZ' : (n:Nat) -> n = plus n Z-    plusReducesZ' Z     = ?plusredZ_Z-    plusReducesZ' (S k) = let ih = plusReducesZ' k in-                          ?plusredZ_S--On running , two global names are created, ``plusredZ_Z`` and-``plusredZ_S``, with no definition.--.. code-block:: idris--    *theorems> : idris plusReducesZ.idr -p pruviloj--    .  /  _/___/ /____(_)____-       / // __  / ___/ / ___/     Version 1.2.0-     _/ // /_/ / /  / (__  )      http://www.idris-lang.org/-    /___/\__,_/_/  /_/____/       Type :? for help--    Idris is free software with ABSOLUTELY NO WARRANTY.-    For details type :warranty.-    Holes: Main.plusredZ_S, Main.plusredZ_Z--This tells us that we have two holes Main.plusredZ_S and Main.plusredZ_Z. We can solve-these separately, ``plusredZ_Z`` is the simplest so we will do that first.--The ``:elab plusredZ_Z`` command enters interactive elaboration mode, which can be used to-complete the missing definition for plusredZ_Z.--.. code-block:: idris--    *plusReducesZ> :elab plusredZ_Z--    ----------                 Goal:                  -----------    {hole_0} : 0 = 0--This has been normalised to ``0 = 0`` so now we have to prove that ``0`` equals ``0``, which-is easy to prove by reflexivity from the pruviloj library:--.. code-block:: idris--    -Main.plusredZ_Z> reflexivity-    plusredZ_Z: No more goals.--This tells us that the proof is complete. We can now leave the interactive mode which-we entered with the ``:elab`` command. We do this with the ``:qed`` command:--.. code-block:: idris--    -Main.plusredZ_Z> :qed-    Proof completed!-    Main.plusredZ_Z = %runElab (do reflexivity)-    Holes: Main.plusredZ_S--This gives us a trace of the proof which is ``plusredZ_Z = %runElab (do reflexivity)``. We-can cut & paste this into the hole in the original file. This also tells us that we-have another hole ``Main.plusredZ_S`` remaining.--This remaining proof is bit more complicated, the following diagram gives an overview:--|image|--We approach this remaining proof in the same way by using the ``:elab`` command:--.. code-block:: idris--    *plusReducesZ> :elab plusredZ_S---    ----------                 Goal:                  -----------    {hole_0} : (k : Nat) -> (k = plus k 0) -> S k = S (plus k 0)--In this case, the goal is a function type, using ``k`` (the argument-accessible by pattern matching) and ``ih`` — the local variable-containing the result of the recursive call. We can introduce these as-assumptions using the ``intro`` tactic twice. The parameter is entered as-a constant of type ``TTName`` which is entered as a backtick with double-braces `{{ih}}. This gives:--.. code-block:: idris--    -Main.plusredZ_S> intro `{{k}}--    ----------              Assumptions:              -----------     k : Nat-    ----------                 Goal:                  -----------    {hole_0} : (k = plus k 0) -> S k = S (plus k 0)-    -Main.plusredZ_S> intro `{{ih}}--    ----------              Assumptions:              -----------     k : Nat-     ih : k = plus k 0-    ----------                 Goal:                  -----------    {hole_0} : S k = S (plus k 0)--We know, from the type of ``ih``, that ``k = plus k 0``, so we would-like to use this knowledge to replace ``plus k 0`` in the goal with-``k``. We can achieve this with the ``rewriteWith`` tactic:--.. code-block:: idris--    -Main.plusredZ_S> rewriteWith (Var `{{ih}})--    ----------              Assumptions:              -----------     k : Nat-     ih : k = plus k 0-    ----------                 Goal:                  -----------    {hole_0} : S k = S k--The ``rewriteWith`` tactic takes an equality proof as an argument, and tries-to rewrite the goal using that proof. The ih value is entered as a constant-of type ``TTName`` which is entered as a backtick with double braces `{{ih}} but-``rewriteWith`` requires an expression of type ``Raw``, rather than just a name,-so the Var constructor is used to make a variable. Here, it results in an equality-which is trivially provable using reflexivity:--.. code-block:: idris--    -Main.plusredZ_S> reflexivity-    plusredZ_S: No more goals.-    -Main.plusredZ_S> :qed-    Proof completed!-    Main.plusredZ_S = %runElab (do intro `{{k}}-                                   intro `{{ih}}-                                   rewriteWith (Var `{{ih}})-                                   reflexivity)--We can't just cut & paste this into the hole in the original file like this:--.. code-block:: idris--  import Pruviloj-  import Pruviloj.Induction--  %language ElabReflection--  plusReducesZ' : (n:Nat) -> n = plus n Z-  plusReducesZ' Z     = %runElab (do reflexivity)-  plusReducesZ' (S k) = let ih = plusReducesZ' k in-                      (%runElab (do intro `{{k}}-                               intro `{{ih}}-                               rewriteWith (Var `{{ih}})-                               reflexivity)-                      )--because this gives the following error:--.. code-block:: idris--  Idris> :load elabInteractiveEx2.idr-  elabInteractiveEx2.idr:10:32:-     |-  10 |                                intro `{{ih}}-     |                                ^-  unexpected "in"-  expecting dependent type signature--However if we put the proof into a separate function like this:--.. code-block:: idris--  import Pruviloj-  import Pruviloj.Induction--  %language ElabReflection--  plusredZ_S : (k : Nat) -> (ih:(k = plus k Z)) -> (S k = S (plus k Z))-  plusredZ_S = %runElab (do intro `{{k}}-                            intro `{{ih}}-                            rewriteWith (Var `{{ih}})-                            reflexivity)--  plusReducesZ' : (n:Nat) -> n = plus n Z-  plusReducesZ' Z     = %runElab (do reflexivity)-  plusReducesZ' (S k) = let ih = plusReducesZ' k in plusredZ_S k ih--This then loads.--.. [#f1] https://github.com/idris-lang/Idris-dev/issues/4556--.. |image| image:: ../image/plusReducesProof.png
− docs/proofs/interactiveOld.rst 
@@ -1,169 +0,0 @@-**************************************************************-DEPRECATED: Interactive Theorem Proving Using Old Tactics Code-**************************************************************--.. warning::-   The interactive theorem-proving interface documented here has been-   deprecated in favor of :ref:`elaborator-reflection`.--Idris also supports interactive theorem proving via tactics. This-is generally not recommended to be used directly, but rather used as a-mechanism for building proof automation which is beyond the scope of this-tutorial. In this section, we briefly discus tactics.--One way to write proofs interactively is to write the general *structure* of-the proof, and use the interactive mode to complete the details.-Consider the following definition, proved in :ref:`sect-theorems`:--.. code-block:: idris--    plusReduces : (n:Nat) -> plus Z n = n--We’ll be constructing the proof by *induction*, so we write the cases for ``Z``-and ``S``, with a recursive call in the ``S`` case giving the inductive-hypothesis, and insert *holes* for the rest of the definition:--.. code-block:: idris--    plusReducesZ' : (n:Nat) -> n = plus n Z-    plusReducesZ' Z     = ?plusredZ_Z-    plusReducesZ' (S k) = let ih = plusReducesZ' k in-                          ?plusredZ_S--On running , two global names are created, ``plusredZ_Z`` and-``plusredZ_S``, with no definition. We can use the ``:m`` command at the-prompt to find out which holes are still to be solved (or, more-precisely, which functions exist but have no definitions), then the-``:t`` command to see their types:--.. code-block:: idris--    *theorems> :m-    Global holes:-            [plusredZ_S,plusredZ_Z]--.. code-block:: idris--    *theorems> :t plusredZ_Z-    plusredZ_Z : Z = plus Z Z--    *theorems> :t plusredZ_S-    plusredZ_S : (k : Nat) -> (k = plus k Z) -> S k = plus (S k) Z--The ``:p`` command enters interactive proof mode, which can be used to-complete the missing definitions.--.. code-block:: idris--    *theorems> :p plusredZ_Z--    ---------------------------------- (plusredZ_Z) ---------    {hole0} : Z = plus Z Z--This gives us a list of premises (above the line; there are none here)-and the current goal (below the line; named ``{hole0}`` here). At the-prompt we can enter tactics to direct the construction of the proof. In-this case, we can normalise the goal with the ``compute`` tactic:--.. code-block:: idris--    -plusredZ_Z> compute--    ---------------------------------- (plusredZ_Z) ---------    {hole0} : Z = Z--Now we have to prove that ``Z`` equals ``Z``, which is easy to prove by-``Refl``. To apply a function, such as ``Refl``, we use ``refine`` which-introduces subgoals for each of the function’s explicit arguments-(``Refl`` has none):--.. code-block:: idris--    -plusredZ_Z> refine Refl-    plusredZ_Z: no more goals--Here, we could also have used the ``trivial`` tactic, which tries to-refine by ``Refl``, and if that fails, tries to refine by each name in-the local context. When a proof is complete, we use the ``qed`` tactic-to add the proof to the global context, and remove the hole from the-unsolved holes list. This also outputs a trace of the proof:--.. code-block:: idris--    -plusredZ_Z> qed-    plusredZ_Z = proof-        compute-        refine Refl--.. code-block:: idris--    *theorems> :m-    Global holes:-            [plusredZ_S]--The ``:addproof`` command, at the interactive prompt, will add the proof-to the source file (effectively in an appendix). Let us now prove the-other required lemma, ``plusredZ_S``:--.. code-block:: idris--    *theorems> :p plusredZ_S--    ---------------------------------- (plusredZ_S) ---------    {hole0} : (k : Nat) -> (k = plus k Z) -> S k = plus (S k) Z--In this case, the goal is a function type, using ``k`` (the argument-accessible by pattern matching) and ``ih`` — the local variable-containing the result of the recursive call. We can introduce these as-premises using the ``intro`` tactic twice (or ``intros``, which-introduces all arguments as premises). This gives:--.. code-block:: idris--      k : Nat-      ih : k = plus k Z-    ---------------------------------- (plusredZ_S) ---------    {hole2} : S k = plus (S k) Z--Since plus is defined by recursion on its first argument, the term-``plus (S k) Z`` in the goal can be simplified, so we use ``compute``.--.. code-block:: idris--      k : Nat-      ih : k = plus k Z-    ---------------------------------- (plusredZ_S) ---------    {hole2} : S k = S (plus k Z)--We know, from the type of ``ih``, that ``k = plus k Z``, so we would-like to use this knowledge to replace ``plus k Z`` in the goal with-``k``. We can achieve this with the ``rewrite`` tactic:--.. code-block:: idris--    -plusredZ_S> rewrite ih--      k : Nat-      ih : k = plus k Z-    ---------------------------------- (plusredZ_S) ---------    {hole3} : S k = S k--    -plusredZ_S>--The ``rewrite`` tactic takes an equality proof as an argument, and tries-to rewrite the goal using that proof. Here, it results in an equality-which is trivially provable:--.. code-block:: idris--    -plusredZ_S> trivial-    plusredZ_S: no more goals-    -plusredZ_S> qed-    plusredZ_S = proof {-        intros;-        rewrite ih;-        trivial;-    }--Again, we can add this proof to the end of our source file using the-``:addproof`` command at the interactive prompt.
− docs/proofs/patterns.rst 
@@ -1,351 +0,0 @@-***********************-Pattern Matching Proofs-***********************--In this section, we will provide a proof of ``plus_commutes`` directly,-by writing a pattern matching definition. We will use interactive-editing features extensively, since it is significantly easier to-produce a proof when the machine can give the types of intermediate-values and construct components of the proof itself. The commands we-will use are summarised below. Where we refer to commands-directly, we will use the Vim version, but these commands have a direct-mapping to Emacs commands.--+---------------------+-----------------+---------------+--------------------------------------------------------------------------------------------+-|Command              | Vim binding     | Emacs binding | Explanation                                                                                |-+---------------------+-----------------+---------------+--------------------------------------------------------------------------------------------+-| Check type          | ``\t``          | ``C-c C-t``   | Show type of identifier or hole under the cursor.                                          |-+---------------------+-----------------+---------------+--------------------------------------------------------------------------------------------+-| Proof search        | ``\o``          | ``C-c C-a``   | Attempt to solve hole under the cursor by applying simple proof search.                    |-+---------------------+-----------------+---------------+--------------------------------------------------------------------------------------------+-| Make new definition | ``\d``          | ``C-c C-s``   | Add a template definition for the type defined under the cursor.                           |-+---------------------+-----------------+---------------+--------------------------------------------------------------------------------------------+-| Make lemma          | ``\l``          | ``C-c C-e``   | Add a top level function with a type which solves the hole under the cursor.               |-+---------------------+-----------------+---------------+--------------------------------------------------------------------------------------------+-| Split cases         | ``\c``          | ``C-c C-c``   | Create new constructor patterns for each possible case of the variable under the cursor.   |-+---------------------+-----------------+---------------+--------------------------------------------------------------------------------------------+---Creating a Definition-=====================--To begin, create a file ``pluscomm.idr`` containing the following type-declaration:--.. code-block:: idris--    plus_commutes : (n : Nat) -> (m : Nat) -> n + m = m + n--To create a template definition for the proof, press ``\d`` (or the-equivalent in your editor of choice) on the line with the type-declaration. You should see:--.. code-block:: idris--    plus_commutes : (n : Nat) -> (m : Nat) -> n + m = m + n-    plus_commutes n m = ?plus_commutes_rhs--To prove this by induction on ``n``, as we sketched in Section-:ref:`sect-inductive`, we begin with a case split on ``n`` (press-``\c`` with the cursor over the ``n`` in the definition.) You-should see:--.. code-block:: idris--    plus_commutes : (n : Nat) -> (m : Nat) -> n + m = m + n-    plus_commutes Z m = ?plus_commutes_rhs_1-    plus_commutes (S k) m = ?plus_commutes_rhs_2--If we inspect the types of the newly created holes,-``plus_commutes_rhs_1`` and ``plus_commutes_rhs_2``, we see that the-type of each reflects that ``n`` has been refined to ``Z`` and ``S k``-in each respective case. Pressing ``\t`` over-``plus_commutes_rhs_1`` shows:--.. code-block:: idris--      m : Nat-    ---------------------------------------    plus_commutes_rhs_1 : m = plus m 0--Note that ``Z`` renders as ``0`` because the pretty printer renders-natural numbers as integer literals for readability. Similarly, for-``plus_commutes_rhs_2``:--.. code-block:: idris--      k : Nat-      m : Nat-    ---------------------------------------    plus_commutes_rhs_2 : S (plus k m) = plus m (S k)--It is a good idea to give these slightly more meaningful names:--.. code-block:: idris--    plus_commutes : (n : Nat) -> (m : Nat) -> n + m = m + n-    plus_commutes Z m = ?plus_commutes_Z-    plus_commutes (S k) m = ?plus_commutes_S--Base Case-=========--We can create a separate lemma for the base case interactively, by-pressing ``\l`` with the cursor over ``plus_commutes_Z``. This-yields:--.. code-block:: idris--    plus_commutes_Z : m = plus m 0--    plus_commutes : (n : Nat) -> (m : Nat) -> n + m = m + n-    plus_commutes Z m = plus_commutes_Z-    plus_commutes (S k) m = ?plus_commutes_S--That is, the hole has been filled with a call to a top level-function ``plus_commutes_Z``. The argument ``m`` has been made implicit-because it can be inferred from context when it is applied.--Unfortunately, we cannot prove this lemma directly, since ``plus`` is-defined by matching on its *first* argument, and here ``plus m 0`` has a-specific value for its *second argument* (in fact, the left hand side of-the equality has been reduced from ``plus 0 m``.) Again, we can prove-this by induction, this time on ``m``.--First, create a template definition with ``\d``:--.. code-block:: idris--    plus_commutes_Z : m = plus m 0-    plus_commutes_Z = ?plus_commutes_Z_rhs--Since we are going to write this by induction on ``m``, which is-implicit, we will need to bring ``m`` into scope manually:--.. code-block:: idris--    plus_commutes_Z : m = plus m 0-    plus_commutes_Z {m} = ?plus_commutes_Z_rhs--Now, case split on ``m`` with ``\c``:--.. code-block:: idris--    plus_commutes_Z : m = plus m 0-    plus_commutes_Z {m = Z} = ?plus_commutes_Z_rhs_1-    plus_commutes_Z {m = (S k)} = ?plus_commutes_Z_rhs_2--Checking the type of ``plus_commutes_Z_rhs_1`` shows the following,-which is easily proved by reflection:--.. code-block:: idris--    ---------------------------------------    plus_commutes_Z_rhs_1 : 0 = 0--For such trivial proofs, we can let write the proof automatically by-pressing ``\o`` with the cursor over ``plus_commutes_Z_rhs_1``.-This yields:--.. code-block:: idris--    plus_commutes_Z : m = plus m 0-    plus_commutes_Z {m = Z} = Refl-    plus_commutes_Z {m = (S k)} = ?plus_commutes_Z_rhs_2--For ``plus_commutes_Z_rhs_2``, we are not so lucky:--.. code-block:: idris--      k : Nat-    ---------------------------------------    plus_commutes_Z_rhs_2 : S k = S (plus k 0)--Inductively, we should know that ``k = plus k 0``, and we can get access-to this inductive hypothesis by making a recursive call on k, as-follows:--.. code-block:: idris--    plus_commutes_Z : m = plus m 0-    plus_commutes_Z {m = Z} = Refl-    plus_commutes_Z {m = (S k)} = let rec = plus_commutes_Z {m=k} in-                                      ?plus_commutes_Z_rhs_2--For ``plus_commutes_Z_rhs_2``, we now see:--.. code-block:: idris--      k : Nat-      rec : k = plus k (fromInteger 0)-    ---------------------------------------    plus_commutes_Z_rhs_2 : S k = S (plus k 0)--Again, the ``fromInteger 0`` is merely due to ``Nat`` having an implementation-of the ``Num`` interface. So we know that ``k = plus k 0``, but how do-we use this to update the goal to ``S k = S k``?--To achieve this, Idris provides a ``replace`` function as part of the-prelude:--.. code-block:: idris--    *pluscomm> :t replace-    replace : (x = y) -> P x -> P y--Given a proof that ``x = y``, and a property ``P`` which holds for-``x``, we can get a proof of the same property for ``y``, because we-know ``x`` and ``y`` must be the same. In practice, this function can be-a little tricky to use because in general the implicit argument ``P``-can be hard to infer by unification, so Idris provides a high level-syntax which calculates the property and applies ``replace``:--.. code-block:: idris--    rewrite prf in expr--If we have ``prf : x = y``, and the required type for ``expr`` is some-property of ``x``, the ``rewrite ... in`` syntax will search for ``x``-in the required type of ``expr`` and replace it with ``y``. Concretely,-in our example, we can say:--.. code-block:: idris--    plus_commutes_Z {m = (S k)} = let rec = plus_commutes_Z {m=k} in-                                      rewrite rec in ?plus_commutes_Z_rhs_2--Checking the type of ``plus_commutes_Z_rhs_2`` now gives:--.. code-block:: idris--      k : Nat-      rec : k = plus k (fromInteger 0)-      _rewrite_rule : plus k 0 = k-    ---------------------------------------    plus_commutes_Z_rhs_2 : S (plus k 0) = S (plus k 0)--Using the rewrite rule ``rec`` (which we can see in the context here as-``_rewrite_rule``\  [1]_, the goal type has been updated with ``k``-replaced by ``plus k 0``.--Alternatively, we could have applied the rewrite in the other direction-using the ``sym`` function:--.. code-block:: idris--    *pluscomm> :t sym-    sym : (l = r) -> r = l--.. code-block:: idris--    plus_commutes_Z {m = (S k)} = let rec = plus_commutes_Z {m=k} in-                                      rewrite sym rec in ?plus_commutes_Z_rhs_2--In this case, inspecting the type of the hole gives:--.. code-block:: idris--      k : Nat-      rec : k = plus k (fromInteger 0)-      _rewrite_rule : k = plus k 0-    ---------------------------------------    plus_commutes_Z_rhs_2 : S k = S k--Either way, we can use proof search (``\o``) to complete the-proof, giving:--.. code-block:: idris--    plus_commutes_Z : m = plus m 0-    plus_commutes_Z {m = Z} = Refl-    plus_commutes_Z {m = (S k)} = let rec = plus_commutes_Z {m=k} in-                                      rewrite rec in Refl--The base case is now complete.--Inductive Step-==============--Our main theorem, ``plus_commutes`` should currently be in the following-state:--.. code-block:: idris--    plus_commutes : (n : Nat) -> (m : Nat) -> n + m = m + n-    plus_commutes Z m = plus_commutes_Z-    plus_commutes (S k) m = ?plus_commutes_S--Looking again at the type of ``plus_commutes_S``, we have:--.. code-block:: idris--      k : Nat-      m : Nat-    ---------------------------------------    plus_commutes_S : S (plus k m) = plus m (S k)--Conveniently, by induction we can immediately tell that-``plus k m = plus m k``, so let us rewrite directly by making a-recursive call to ``plus_commutes``. We add this directly, by hand, as-follows:--.. code-block:: idris--    plus_commutes : (n : Nat) -> (m : Nat) -> n + m = m + n-    plus_commutes Z m = plus_commutes_Z-    plus_commutes (S k) m = rewrite plus_commutes k m in ?plus_commutes_S--Checking the type of ``plus_commutes_S`` now gives:--.. code-block:: idris--      k : Nat-      m : Nat-      _rewrite_rule : plus m k = plus k m-    ---------------------------------------    plus_commutes_S : S (plus m k) = plus m (S k)--The good news is that ``m`` and ``k`` now appear in the correct order.-However, we still have to show that the successor symbol ``S`` can be-moved to the front in the right hand side of this equality. This-remaining lemma takes a similar form to the ``plus_commutes_Z``; we-begin by making a new top level lemma with ``\l``. This gives:--.. code-block:: idris--    plus_commutes_S : (k : Nat) -> (m : Nat) -> S (plus m k) = plus m (S k)--Unlike the previous case, ``k`` and ``m`` are not made implicit because-we cannot in general infer arguments to a function from its result.-Again, we make a template definition with ``\d``:--.. code-block:: idris--    plus_commutes_S : (k : Nat) -> (m : Nat) -> S (plus m k) = plus m (S k)-    plus_commutes_S k m = ?plus_commutes_S_rhs--Again, this is defined by induction over ``m``, since ``plus`` is-defined by matching on its first argument. The complete definition is:--.. code-block:: idris--    total-    plus_commutes_S : (k : Nat) -> (m : Nat) -> S (plus m k) = plus m (S k)-    plus_commutes_S k Z = Refl-    plus_commutes_S k (S j) = rewrite plus_commutes_S k j in Refl--All holes have now been solved.--The ``total`` annotation means that we require the final function to-pass the totality checker; i.e. it will terminate on all possible-well-typed inputs. This is important for proofs, since it provides a-guarantee that the proof is valid in *all* cases, not just those for-which it happens to be well-defined.--Now that ``plus_commutes`` has a ``total`` annotation, we have completed the-proof of commutativity of addition on natural numbers.--.. [1]-   Note that the left and right hand sides of the equality have been-   swapped, because ``replace`` takes a proof of ``x=y`` and the-   property for ``x``, not ``y``.
− docs/proofs/pluscomm.rst 
@@ -1,189 +0,0 @@-********************************************-Running example: Addition of Natural Numbers-********************************************--Throughout this tutorial, we will be working with the following-function, defined in the Idris prelude, which defines addition on-natural numbers:--.. code-block:: idris--    plus : Nat -> Nat -> Nat-    plus Z     m = m-    plus (S k) m = S (plus k m)--It is defined by the above equations, meaning that we have for free the-properties that adding ``m`` to zero always results in ``m``, and that-adding ``m`` to any non-zero number ``S k`` always results in-``S (plus k m)``. We can see this by evaluation at the Idris REPL (i.e.-the prompt, the read-eval-print loop):--.. code-block:: idris--    Idris> \m => plus Z m-    \m => m : Nat -> Nat--    Idris> \k,m => plus (S k) m-    \k => \m => S (plus k m) : Nat -> Nat -> Nat--Note that unlike many other language REPLs, the Idris REPL performs-evaluation on *open* terms, meaning that it can reduce terms which-appear inside lambda bindings, like those above. Therefore, we can-introduce unknowns ``k`` and ``m`` as lambda bindings and see how-``plus`` reduces.--The ``plus`` function has a number of other useful properties, for-example:---  It is *commutative*, that is for all ``Nat`` inputs ``n`` and ``m``,-   we know that ``plus n m = plus m n``.---  It is *associative*, that is for all ``Nat`` inputs ``n``, ``m`` and-   ``p``, we know that ``plus n (plus m p) = plus (plus m n) p``.--We can use these properties in an Idris program, but in order to do so-we must *prove* them.--Equality Proofs-===============--Idris has a built-in propositional equality type, conceptually defined-as follows:--.. code-block:: idris--    data (=) : a -> b -> Type where-       Refl : x = x--Note that this must be built-in, rather than defined in the library,-because ``=`` is a reserved operator — you cannot define this directly-in your own code.--It is *propositional* equality, where the type states that any two-values in different types ``a`` and ``b`` may be proposed to be equal.-There is only one way to *prove* equality, however, which is by-reflexivity (``Refl``).--We have a *type* for propositional equality here, and correspondingly a-*program* inhabiting an instance of this type can be seen as a proof of-the corresponding proposition [1]_. So, trivially, we can prove that-``4`` equals ``4``:--.. code-block:: idris--    four_eq : 4 = 4-    four_eq = Refl--However, trying to prove that ``4 = 5`` results in failure:--.. code-block:: idris--    four_eq_five : 4 = 5-    four_eq_five = Refl--The type ``4 = 5`` is a perfectly valid type, but is uninhabited, so-when trying to type check this definition, Idris gives the following-error:--::--    When elaborating right hand side of four_eq_five:-    Type mismatch between-            x = x (Type of Refl)-    and-            4 = 5 (Expected type)--Type checking equality proofs--------------------------------An important step in type checking Idris programs is *unification*,-which attempts to resolve implicit arguments such as the implicit-argument ``x`` in ``Refl``. As far as our understanding of type checking-proofs is concerned, it suffices to know that unifying two terms-involves reducing both to normal form then trying to find an assignment-to implicit arguments which will make those normal forms equal.--When type checking ``Refl``, Idris requires that the type is of the form-``x = x``, as we see from the type of ``Refl``. In the case of-``four_eq_five``, Idris will try to unify the expected type ``4 = 5``-with the type of ``Refl``, ``x = x``, notice that a solution requires-that ``x`` be both ``4`` and ``5``, and therefore fail.--Since type checking involves reduction to normal form, we can write the-following equalities directly:--.. code-block:: idris--    twoplustwo_eq_four : 2 + 2 = 4-    twoplustwo_eq_four = Refl--    plus_reduces_Z : (m : Nat) -> plus Z m = m-    plus_reduces_Z m = Refl--    plus_reduces_Sk : (k, m : Nat) -> plus (S k) m = S (plus k m)-    plus_reduces_Sk k m = Refl--Heterogeneous Equality-======================--Equality in Idris is *heterogeneous*, meaning that we can even propose-equalities between values in different types:--.. code-block:: idris--    idris_not_php : 2 = "2"--Obviously, in Idris the type ``2 = "2"`` is uninhabited, and one might-wonder why it is useful to be able to propose equalities between values-in different types. However, with dependent types, such equalities can-arise naturally. For example, if two vectors are equal, their lengths-must be equal:--.. code-block:: idris--    vect_eq_length : (xs : Vect n a) -> (ys : Vect m a) ->-                     (xs = ys) -> n = m--In the above declaration, ``xs`` and ``ys`` have different types because-their lengths are different, but we would still like to draw a-conclusion about the lengths if they happen to be equal. We can define-``vect_eq_length`` as follows:--.. code-block:: idris--    vect_eq_length xs xs Refl = Refl--By matching on ``Refl`` for the third argument, we know that the only-valid value for ``ys`` is ``xs``, because they must be equal, and-therefore their types must be equal, so the lengths must be equal.--Alternatively, we can put an underscore for the second ``xs``, since-there is only one value which will type check:--.. code-block:: idris--    vect_eq_length xs _ Refl = Refl--Properties of ``plus``-======================--Using the ``(=)`` type, we can now state the properties of ``plus``-given above as Idris type declarations:--.. code-block:: idris--    plus_commutes : (n, m : Nat) -> plus n m = plus m n-    plus_assoc : (n, m, p : Nat) -> plus n (plus m p) = plus (plus n m) p--Both of these properties (and many others) are proved for natural number-addition in the Idris standard library, using ``(+)`` from the ``Num``-interface rather than using ``plus`` directly. They have the names-``plusCommutative`` and ``plusAssociative`` respectively.--In the remainder of this tutorial, we will explore several different-ways of proving ``plus_commutes`` (or, to put it another way, writing-the function.) We will also discuss how to use such equality proofs, and-see where the need for them arises in practice.--.. [1]-   This is known as the Curry-Howard correspondence.
− docs/proofs/propositional.rst 
@@ -1,128 +0,0 @@-This page attempts to explain some of the techniques used in Idris to prove propositional equalities.--Proving Propositional Equality-==============================--We have seen that definitional equalities can be proved using Refl since they always normalise to unique values that can be compared directly.--However with propositional equalities we are using symbolic variables they do not always normalse.--So to take the previous example:--plusReducesR : (n:Nat) -> plus n Z = n--In this case 'plus n Z' does not normalise to n. Even though both sides are equal we cannot pattern match Refl.--If the pattern match cannot match for all 'n' then the way around this is to separately match all possible values of 'n'. In the case of natural numbers we do this by induction.--So here:--.. code-block:: idris--   plusReducesR : n = plus n 0-   plusReducesR {n = Z} = Refl-   plusReducesR {n = (S k)} = let rec = plus_commutes_Z {n=k} in-                                  rewrite rec in Refl--we don't call Refl to match on 'n = plus n 0' forall 'n' we call it for every number separately. So, in the second line, the pattern matcher knows to substitute Z for n in the type being matched. This uses 'rewrite' which is explained below.--Replace-=======--This implements the 'indiscernability of identicals' principle, if two terms are equal then they have the same properties. In other words, if x=y, then we can substitute y for x in any expression. In our proofs we can express this as:--   if x=y-   then P x = P y--where P is a pure function representing the property. In the examples below P is an expression in some variable with a type like this: P: n -> Type--So if n is a natural number variable then P could be something like 2*n + 3.--To use this in our proofs there is the following function in the prelude:--.. code-block:: idris--   ||| Perform substitution in a term according to some equality.-   replace : {a:_} -> {x:_} -> {y:_} -> {P : a -> Type} -> x = y -> P x -> P y-   replace Refl prf = prf--Removing the implicits, if we supply an equality (x=y) and a proof of a property of x (P x) then we get a proof of a property of y (P y)--.. code-block:: idris--   > :t replace-   replace : (x = y) -> P x -> P y--So, in the following example, if we supply p1 x which is a proof that x=2 and the equality x=y then we get a proof that y=2.--.. code-block:: idris--   p1: Nat -> Type-   p1 n = (n=2)--   testReplace: (x=y) -> (p1 x) -> (p1 y)-   testReplace a b = replace a b--Rewrite-=======--Similar to 'replace' above but Idris provides a nicer syntax which makes 'rewrite' easier to use in examples like plusReducesR above.--.. code-block:: idris--   rewrite__impl : (P : a -> Type) -> x = y -> P y -> P x-   rewrite__impl p Refl prf = prf--The difference from 'replace' above is nicer syntax and the property p1 is explicitly supplied and it goes in the opposite direction (input and output reversed).--Example: again we supply p1 which is a proof that x=2 and the equality x=y then we get a proof that y=2.--.. code-block:: idris--   p1: Nat -> Type-   p1 x = (x=2)--   testRewrite2: (x=y) -> (p1 y) -> (p1 x)-   testRewrite2 a b = rewrite a in b--We can think of rewrite doing this:-- * Start with a equation x=y and a property P: x -> Type- * Searches y in P- * Replaces all occurrences of y with x in P.--That is, we are doing a substitution.--Symmetry and Transitivity-=========================--In addition to 'reflexivity' equality also obeys 'symmetry' and 'transitivity' and these are also included in the prelude:--.. code-block:: idris--   ||| Symmetry of propositional equality-   sym : {left:a} -> {right:b} -> left = right -> right = left-   sym Refl = Refl--   ||| Transitivity of propositional equality-   trans : {a:x} -> {b:y} -> {c:z} -> a = b -> b = c -> a = c-   trans Refl Refl = Refl--Heterogeneous Equality-======================--Also included in the prelude: --.. code-block:: idris--   ||| Explicit heterogeneous ("John Major") equality. Use this when Idris-   ||| incorrectly chooses homogeneous equality for `(=)`.-   ||| @ a the type of the left side-   ||| @ b the type of the right side-   ||| @ x the left side-   ||| @ y the right side-   (~=~) : (x : a) -> (y : b) -> Type-   (~=~) x y = (x = y)---
− docs/reference/codegen.rst 
@@ -1,138 +0,0 @@-************************-Code Generation Targets-************************--``Idris`` has been designed such that the compiler can generate code for-different backends upon request. By default ``Idris`` generates a ``C``-backend when generating an executable. Included within the standard Idris installation are backends for Javascript and Node.js.--However, there are third-party code generators out there.  Below we-describe some of these backends and how you can use them when-compiling your ``Idris`` code. If you want to write your own codegen for your language there is a `stub project on GitHub <https://github.com/idris-lang/idris-emptycg>`__ that can help point you in the right direction.--Official Backends-==================--C Language-------------Javascript-------------To generate code that is tailored for running in the browser-issue the following command:--::--    $ idris --codegen javascript hello.idr -o hello.js---Idris can produce very big chunks of JavaScript code (hello world-weighs in at 1500 lines). However, the generated code can be minified-using the `closure-compiler-<https://developers.google.com/closure/compiler/>`__ from Google.--::--   java -jar compiler.jar --compilation_level ADVANCED_OPTIMIZATIONS --js hello.js---Node.js----------Generating code for NodeJS is slightly different. Idris outputs a-JavaScript file that can be directly executed via node.--::--    $ idris --codegen node hello.idr -o hello-    $ ./hello-    Hello world----Third Party-============--.. note::--   These are third-party code generations and may have bit-rotted or-   do not work with current versions of Idris. Please speak to the-   project's maintainors if there are any problems.---CIL (.NET, Mono, Unity)--------------------------::--    idris --codegen cil Main.idr -o HelloWorld.exe \-      && mono HelloWorld.exe--The resulting assemblies can also be used with .NET or Unity.--Requires `idris-cil <https://github.com/bamboo/idris-cil>`__.--Erlang---------`Available online <https://github.com/lenary/idris-erlang>`__--Java-------`Available online <https://github.com/idris-hackers/idris-java>`__---::--   idris hello.idr --codegen java -o hello.jar---Note: The resulting .jar is automatically prefixed by a header including-an .sh script to allow executing it directly.--JVM------`Available online <https://github.com/mmhelloworld/idris-jvm>`__--LLVM--------`Available online <https://github.com/idris-hackers/idris-llvm>`__--Malfunction---------------`Available online <https://github.com/stedolan/idris-malfunction>`__--Ocaml--------`Available online <https://github.com/ziman/idris-ocaml>`__--PHP------`Available online <https://github.com/edwinb/idris-php>`__--Python---------`Available online <https://github.com/ziman/idris-py>`__--Ruby-------`Available online <https://github.com/mrb/idris-ruby>`__--WS------`Available online <https://github.com/edwinb/WS-idr>`__--WebAssembly--------------`Available online <https://github.com/SPY/idris-codegen-wasm>`__
− docs/reference/compilation.rst 
@@ -1,131 +0,0 @@-************************************-Compilation, Logging, and Reporting-************************************--This section provides information about the Idris compilation process, and-provides details over how you can follow the process through logging.--Compilation Process-===================--Idris follows the following compilation process:--#. Parsing-#. Type Checking--   #. Elaboration-   #. Coverage-   #. Unification-   #. Totality Checking-   #. Erasure--#. Code Generation--   #. Defunctionalisation-   #. Inlining-   #. Resolving variables-   #. Code Generation---Type Checking Only-==================--With Idris you can ask it to terminate the compilation process after type checking has completed. This is achieved through use of either:--+ The command line options--  + ``--check`` for files-  + ``--checkpkg`` for packages--+ The REPL command: ``:check``--Use of this option will still result in the generation of the Idris binary ``.ibc`` files, and is suitable if you do not wish to generate code from one of the supported backends.--Reporting Compilation Process-=============================--During compilation the reporting of Idris' progress can be controlled-by setting a verbosity level.--+ ``-V``, or alternatively ``--verbose`` and ``--V0``, will report which file Idris is currently type checking.-+ ``--V1`` will additionally report: Parsing, IBC Generation, and Code-  Generation.-+ ``--V2`` will additionally report: Totality Checking, Universe-  Checking, and the individual steps prior to code generation.---By default Idris' progress reporting is set to quiet-``-q``, or ``--quiet``.--Logging Internal Operation-===========================--For those that develop on the Idris compiler, the internal operation-of Idris is captured using a category based logger. Currently, the-logging infrastructure has support for the following categories:--+ Parser (``parser``)-+ Elaborator (``elab``)-+ Code generation (``codegen``)-+ Erasure (``erasure``)-+ Coverage Checking (``coverage``)-+ IBC generation (``ibc``)---These categories are specified using the command-line option:-``--logging-categories CATS``, where ``CATS`` is a quoted colon-separated string of the categories you want to see. By default if this-option is not specified all categories are allowed.  Sub-categories-have yet to be defined but will be in the future, especially for the-elaborator.--Further, the verbosity of logging can be controlled by specifying a-logging level between: 1 to 10 using the command-line option: ``--log-<level>``.--+ Level 0: Show no logging output. Default level-+ Level 1: High level details of the compilation process.-+ Level 2: Provides details of the coverage checking, and further details the elaboration process specifically: Interface, Clauses, Data, Term, and Types,-+ Level 3: Provides details of compilation of the IRTS, erasure, parsing, case splitting, and further details elaboration of: Implementations, Providers, and Values.-+ Level 4: Provides further details on: Erasure, Coverage Checking, Case splitting, and elaboration of clauses.-+ Level 5: Provides details on the prover, and further details elaboration (adding declarations) and compilation of the IRTS.-+ Level 6: Further details elaboration and coverage checking.-+ Level 7:-+ Level 8:-+ Level 9:-+ Level 10: Further details elaboration.--Environment Variables-=====================--Several paths set by default within the Idris compiler can be-overridden through environment variables.  The provided variables are:--* `IDRIS_CC` Change the `C` compiler used by the `C` backend.-* `IDRIS_CFLAGS` Change the `C` flags passed to the `C` compiler.-* `TARGET`   Change the target directory i.e. `data dir` where Idris installs files when installing using Cabal/Stack.-* `IDRIS_LIBRARY_PATH` Change the location of where installed packages are found/installed.-* `IDRIS_DOC_PATH`  Change the location of where generated idrisdoc for packages are installed.--.. note::--   In versions of Idris prior to 0.12.3 the environment variables-   `IDRIS_LIBRARY_PATH` and `TARGET` were both used to affect the-   installation of single packages and direct where Idris installed-   its data. The meaning of these variables has changed, and command-   line options are preferred when changing where individual packages-   are installed.--The CLI option `--ibcsubdir` can be used to direct where generated IBC-files are placed.  However, this means Idris will install files in a-non-standard location separate from the rest of the installed-packages. The CLI option `--idrispath <dir>` allows you to add a-directory to the library search path; this option can be used multiple-times and can be shortened to `-i <dir>`. Similary, the `--sourcepath-<dir>` option can be used to add directories to the source search-path. There is no shortened version for this option as `-s` is a-reserved flag.--Further, Idris also supports options to augment the paths used, and-pass options to the code generator backend.  The option `--cg-opt-<ARG>` can be used to pass options to the code generator. The format-of `<ARG>` is dependent on the selected backend.
− docs/reference/documenting.rst 
@@ -1,142 +0,0 @@-.. _sect-documenting:--**********************-Documenting Idris Code-**********************--Idris documentation comes in two major forms: comments, which exist-for a reader’s edification and are ignored by the compiler, and inline-API documentation, which the compiler parses and stores for future-reference. To consult the documentation for a declaration ``f``, write-``:doc f`` at the REPL or use the appropriate command in your editor-(``C-c C-d`` in Emacs, ``<LocalLeader>h`` in Vim).--Comments-========--Use comments to explain why code is written the way that it-is. Idris’s comment syntax is the same as that of Haskell: lines-beginning with ``--`` are comments, and regions bracketed by ``{-``-and ``-}`` are comments even if they extend across multiple-lines. These can be used to comment out lines of code or provide-simple documentation for the readers of Idris code.--Inline Documentation-====================--Idris also supports a comprehensive and rich inline syntax for Idris-code to be generated. This syntax also allows for named parameters and-variables within type signatures to be individually annotated using a-syntax similar to Javadoc parameter annotations.--Documentation always comes before the declaration being documented.-Inline documentation applies to either top-level declarations or to-constructors. Documentation for specific arguments to constructors, type-constructors, or functions can be associated with these arguments using-their names.--The inline documentation for a declaration is an unbroken string of-lines, each of which begins with ``|||`` (three pipe symbols). The-first paragraph of the documentation is taken to be an overview, and-in some contexts, only this overview will be shown. After the-documentation for the declaration as a whole, it is possible to-associate documentation with specific named parameters, which can-either be explicitly name or the results of converting free variables-to implicit parameters.  Annotations are the same as with Javadoc-annotations, that is for the named parameter ``(n : T)``, the-corresponding annotation is ``||| @ n Some description`` that is-placed before the declaration.--Documentation is written in Markdown, though not all contexts will-display all possible formatting (for example, images are not displayed-when viewing documentation in the REPL, and only some terminals render-italics correctly). A comprehensive set of examples is given below.--.. code-block:: idris---    ||| Modules can also be documented.-    module Docs--    ||| Add some numbers.-    |||-    ||| Addition is really great. This paragraph is not part of the overview.-    ||| Still the same paragraph. -    |||-    ||| You can even provide examples which are inlined in the documentation:-    ||| ```idris example-    ||| add 4 5-    ||| ```-    ||| -    ||| Lists are also nifty:-    ||| * Really nifty!-    ||| * Yep!-    ||| * The name `add` is a **bold** choice-    ||| @ n is the recursive param-    ||| @ m is not-    add : (n, m : Nat) -> Nat-    add Z     m = m-    add (S n) m = S (add n m)---    ||| Append some vectors-    ||| @ a the contents of the vectors-    ||| @ xs the first vector (recursive param)-    ||| @ ys the second vector (not analysed)-    appendV : (xs : Vect n a) -> (ys : Vect m a) -> Vect (add n m) a-    appendV []      ys = ys-    appendV (x::xs) ys = x :: appendV xs ys--    ||| Here's a simple datatype-    data Ty =-      ||| Unit-      UNIT |-      ||| Functions-      ARR Ty Ty--    ||| Points to a place in a typing context-    data Elem : Vect n Ty -> Ty -> Type where-      Here : {ts : Vect n Ty} -> Elem (t::ts) t-      There : {ts : Vect n Ty} -> Elem ts t -> Elem (t'::ts) t--    ||| A more interesting datatype-    ||| @ n the number of free variables-    ||| @ ctxt a typing context for the free variables-    ||| @ ty the type of the term-    data Term : (ctxt : Vect n Ty) -> (ty : Ty) -> Type where--      ||| The constructor of the unit type-      ||| More comment-      ||| @ ctxt the typing context-      UnitCon : {ctxt : Vect n Ty} -> Term ctxt UNIT--      ||| Function application-      ||| @ f the function to apply-      ||| @ x the argument-      App : {ctxt : Vect n Ty} -> (f : Term ctxt (ARR t1 t2)) -> (x : Term ctxt t1) -> Term ctxt t2--      ||| Lambda-      ||| @ body the function body-      Lam : {ctxt : Vect n Ty} -> (body : Term (t1::ctxt) t2) -> Term ctxt (ARR t1 t2)--      ||| Variables-      ||| @ i de Bruijn index-      Var : {ctxt : Vect n Ty} -> (i : Elem ctxt t) -> Term ctxt t--    ||| A computation that may someday finish-    codata Partial : Type -> Type where--      ||| A finished computation-      ||| @ value the result-      Now : (value : a) -> Partial a--      ||| A not-yet-finished computation-      ||| @ rest the remaining work-      Later : (rest : Partial a) -> Partial a--    ||| We can document records, including their fields and constructors-    record Yummy where-      ||| Make a yummy-      constructor MkYummy-      ||| What to eat-      food : String
− docs/reference/elaborator-reflection.rst 
@@ -1,203 +0,0 @@-.. _elaborator-reflection:--*********************-Elaborator Reflection-*********************--The Idris elaborator is responsible for converting high-level Idris code into the core language.-It is implemented as a kind of embedded tactic language in Haskell, where tactic scripts are written in an *elaboration monad* that provides error handling and a proof state.-For details, see `Edwin Brady's 2013 paper in the Journal of Functional-Programming <https://eb.host.cs.st-andrews.ac.uk/drafts/impldtp.pdf>`_.--Elaborator reflection makes the elaboration type as well as a selection of its tactics available to Idris code.-This means that metaprograms written in Idris can have complete control over the elaboration process, generating arbitrary code, and they have access to all of the facilities available in the elaborator, such as higher-order unification, type checking, and emitting auxiliary definitions.--The Elaborator State-====================--The elaborator state contains information about the ongoing elaboration process.-In particular, it contains a *goal type*, which is to be filled by an under-construction *proof term*.-The proof term can contain *holes*, each of which has a scope in which it is valid and a type.-Some holes may additionally contain *guesses*, which can be substituted in the scope of the hole.-The holes are tracked in a *hole queue*, and one of them is *focused*.-In addition to the goal type, proof term, and holes, the elaborator state contains a collection of unsolved unification problems that can affect elaboration.--The elaborator state is not directly available to Idris programs.-Instead, it is modified through the use of *tactics*, which are operations that affect the elaborator state.-A tactic that returns a value of type ``a``, potentially modifying the elaborator state, has type ``Elab a``.-The default tactics are all in the namespace ``Language.Reflection.Elab.Tactics``.---Running Elaborator Scripts-==========================--On their own, tactics have no effect.-The meta-operation ``%runElab script`` runs ``script`` in the current elaboration context.-Before you can use ``%runElab``, you will have to enable the language extension by adding-``%language ElabReflection`` in your file (or by passing ``-X ElabReflection`` to the-``idris`` executable from your command line).-For example, the following script constructs the identity function at type ``Nat``:--.. code-block:: idris--    idNat : Nat -> Nat-    idNat = %runElab (do intro `{{x}}-                         fill (Var `{{x}})-                         solve)---On the right-hand side, the Idris elaborator has the goal ``Nat -> Nat``.-When it encounters the ``%runElab`` directive, it fulfills this goal by running the provided script.-The first tactic, ``intro``, constructs a lambda that binds the name ``x``.-The name argument is optional because a default name can be taken from the function type.-Now, the proof term is of the form ``\x : Nat => {hole}``.-The second tactic, ``fill``, fills this hole with a guess, giving the term ``\x : Nat => {hole≈x}``.-Finally, the ``solve`` tactic instantiates the guess, giving the result ``\x : Nat => x``.--Because elaborator scripts are ordinary Idris expressions, it is also possible to use them in multiple contexts.-Note that there is nothing ``Nat``-specific about the above script.-We can generate identity functions at any concrete type using the same script:--.. code-block:: idris--    mkId : Elab ()-    mkId = do intro `{{x}}-              fill (Var `{{x}})-              solve--    idNat : Nat -> Nat-    idNat = %runElab mkId--    idUnit : () -> ()-    idUnit = %runElab mkId--    idString : String -> String-    idString = %runElab mkId---Interactively Building Elab Scripts-===================================--You can build an ``Elab`` script interactively at the REPL.-Use the command ``:metavars``, or ``:m`` for short, to list the available holes.-Then, issue the ``:elab <hole>`` command at the REPL-to enter the elaboration shell.--At the shell, you can enter proof tactics to alter the proof state.-You can view the system-provided tactics prior to entering the shell-by issuing the REPL command ``:browse Language.Reflection.Elab.Tactics``.-When you have discharged all goals, you can complete the proof-using the ``:qed`` command and receive in return an elaboration script-that fills the hole.--The interactive elaboration shell accepts a limited number of commands,-including a subset of the commands understood by the normal Idris REPL-as well as some elaboration-specific commands. It also supports the -``do``-syntax, meaning you can write ``res <- command`` to bind the result of -``command`` to variable ``res``.--General-purpose commands:--- ``:eval <EXPR>``, or ``:e <EXPR>`` for short, evaluates the provided expression-  and prints the result.--- ``:type <EXPR>``, or ``:t <EXPR>`` for short, prints the provided expression-  together with its type.--- ``:search <TYPE>`` searches for definitions having the provided type.--- ``:doc <NAME>`` searches for definitions with the provided name and prints their-  documentation.---Commands for viewing the proof state:--- ``:state`` displays the current state of the term being constructed. It lists both-  other goals and the current goal.--- ``:term`` displays the current proof term as well as its yet-to-be-filled holes.---Commands for manipulating the proof state:--- ``:undo`` undoes the effects of the last tactic.--- ``:abandon`` gives up on proving the current lemma and quits the elaboration shell.--- ``:qed`` finishes the script and exits the elaboration shell. The shell will only accept-  this command once it reports, "No more goals." On exit, it will print out the finished-  elaboration script for you to copy into your program.---Failure-=======--Some tactics may *fail*.-For example, ``intro`` will fail if the focused hole does not have a function type, ``solve`` will fail if the current hole does not contain a guess, and ``fill`` will fail if the term to be filled in has the wrong type.-Scripts can also fail explicitly using the ``fail`` tactic.--To account for failure, there is an ``Alternative`` implementation for ``Elab``.-The ``<|>`` operator first tries the script to its left.-If that script fails, any changes that it made to the state are undone and the right argument is executed.-If the first argument succeeds, then the second argument is not executed.--Querying the Elaboration State-==============================--``Elab`` includes operations to query the elaboration state, allowing scripts to use information about their environment to steer the elaboration process.-The ordinary Idris bind syntax can be used to propagate this information.-For example, a tactic that solves the current goal when it is the unit type might look like this:--.. code-block:: idris--    triv : Elab ()-    triv = do compute-              g <- getGoal-              case (snd g) of-                `(() : Type) => do fill `(() : ())-                                   solve-                otherGoal => fail [ TermPart otherGoal-                                  , TextPart "is not trivial"-                                  ]---The tactic ``compute`` normalises the type of its goal with respect to the current context.-While not strictly necessary, this allows ``triv`` to be used in contexts where the triviality of the goal is not immediately apparent.-Then, ``getGoal`` is used, and its result is bound to ``g``.-Because it returns a pair consisting of the current goal's name and type, we case-split on its second projection.-If the goal type turns out to have been the unit type, we fill using the unit constructor and solve the goal.-Otherwise, we fail with an error message informing the user that the current goal is not trivial.--Additionally, the elaboration state can be dumped into an error message with the ``debug`` tactic.-A variant, ``debugMessage``, allows arbitrary messages to be included with the state, allowing for a kind of "``printf`` debugging" of elaboration scripts.-The message format used by ``debugMessage`` is the same for errors produced by the error reflection mechanism, allowing the re-use of the Idris pretty-printer when rendering messages.--Changing the Global Context-===========================--``Elab`` scripts can modify the global context during execution.-Just as the Idris elaborator produces auxiliary definitions to implement features such as ``where``-blocks and ``case`` expressions, user elaboration scripts may need to define functions.-Furthermore, this allows ``Elab`` reflection to be used to implement features such as interface deriving.-The operations ``declareType``, ``defineFunction``, and ``addImplementation`` allow ``Elab`` scripts to modify the global context.--Using Idris's Features-======================--The Idris compiler has a number of ways to automate the construction of terms.-On its own, the ``Elab`` state and its interactions with the unifier allow implicits to be solved using unification.-Additional operations use further features of Idris.-In particular, ``resolveTC`` solves the current goal using interface resolution, ``search`` invokes the proof search mechanism, and ``sourceLocation`` finds the context in the original file at which the elaboration script is invoked.---Recursive Elaboration-=====================--The elaboration mechanism can be invoked recursively using the ``runElab`` tactic.-This tactic takes a goal type and an elaboration script as arguments and runs the script in a fresh lexical environment to create an inhabitant of the provided goal type.-This is primarily useful for code generation, particularly for generating pattern-matching clauses, where variable scope needs to be one that isn't the present local context.--Learn More-==========-While this documentation is still incomplete, elaboration reflection works in Idris today.-As you wait for the completion of the documentation, the list of built-in tactics can be obtained using the ``:browse`` command in an Idris REPL or the corresponding feature in one of the graphical IDE clients to explore the ``Language.Reflection.Elab.Tactics`` namespace.-All of the built-in tactics contain documentation strings.
− docs/reference/erasure.rst 
@@ -1,502 +0,0 @@-*************************-Erasure By Usage Analysis-*************************--This work stems from this `feature proposal-<https://github.com/idris-lang/Idris-dev/wiki/Egg-%232%3A-Erasure-annotations>`__-(obsoleted by this page). Beware that the information in the proposal-is out of date — and sometimes even in direct contradiction with the-eventual implementation.--Motivation-==========--Traditional dependently typed languages (Agda, Coq) are good at-erasing *proofs* (either via irrelevance or an extra universe).--.. code-block:: idris--    half : (n : Nat) -> Even n -> Nat-    half Z EZ = Z-    half (S (S n)) (ES pf) = S (half n pf)--For example, in the above snippet, the second argument is a proof,-which is used only to convince the compiler that the function is-total. This proof is never inspected at runtime and thus can be-erased. In this case, the mere existence of the proof is sufficient-and we can use irrelevance-related methods to achieve erasure.--However, sometimes we want to erase *indices* and this is where the-traditional approaches stop being useful, mainly for reasons described-in the `original proposal-<https://github.com/idris-lang/Idris-dev/wiki/Egg-%232%3A-Erasure-annotations>`__.--.. code-block:: idris--    uninterleave : {n : Nat} -> Vect (n * 2) a -> (Vect n a, Vect n a)-    uninterleave [] = ([] , [])-    uninterleave (x :: y :: rest) with (unzipPairs rest)-      | (xs, ys) = (x :: xs, y :: ys)--Notice that in this case, the second argument is the important one and-we would like to get rid of the ``n`` instead, although the shape of-the program is generally the same as in the previous case.--There are methods described by Brady, McBride and McKinna in [BMM04]_-to remove the indices from data structures, exploiting the fact that-functions operating on them either already have a copy of the-appropriate index or the index can be quickly reconstructed if needed.-However, we often want to erase the indices altogether, from the whole-program, even in those cases where reconstruction is not possible.--The following two sections describe two cases where doing so improves-the runtime performance asymptotically.--Binary numbers------------------ O(n) instead of O(log n)--Consider the following ``Nat``-indexed type family representing binary-numbers:--.. code-block:: idris--    data Bin : Nat -> Type where-      N : Bin 0-      O : {n : Nat} -> Bin n -> Bin (0 + 2*n)-      I : {n : Nat} -> Bin n -> Bin (1 + 2*n)--These are supposed to be (at least asymptotically) fast and-memory-efficient because their size is logarithmic compared to the-numbers they represent.--Unfortunately this is not the case. The problem is that these binary-numbers still carry the *unary* indices with them, performing-arithmetic on the indices whenever arithmetic is done on the binary-numbers themselves. Hence the real representation of the number 15-looks like this:--::--    I -> I -> I -> I -> N-    S    S    S    Z-    S    S    Z-    S    S-    S    Z-    S-    S-    S-    Z--The used memory is actually *linear*, not logarithmic and therefore we-cannot get below O(n) with time complexities.--One could argue that Idris in fact compiles ``Nat`` via GMP but-that's a moot point for two reasons:--+ First, whenever we try to index our data structures with anything-  else than ``Nat``, the compiler is not going to come to the rescue.--+ Second, even with ``Nat``, the GMP integers are *still* there and-  they slow the runtime down.--This ought not to be the case since the ``Nat`` are never used at-runtime and they are only there for typechecking purposes. Hence we-should get rid of them and get runtime code similar to what an Idris-programmer would write.--U-views of lists--------------------  O(n^2) instead of O(n)--Consider the type of U-views of lists:--.. code-block:: idris--    data U : List a -> Type where-      nil : U []-      one : (z : a) -> U [z]-      two : {xs : List a} -> (x : a) -> (u : U xs) -> (y : a) -> U (x :: xs ++ [y])--For better intuition, the shape of the U-view of-``[x0,x1,x2,z,y2,y1,y0]`` looks like this:--::--      x0   y0    (two)-      x1   y1    (two)-      x2   y2    (two)-         z       (one)--When recursing over this structure, the values of ``xs`` range over-``[x0,x1,x2,z,y2,y1,y0]``, ``[x1,x2,z,y2,y1]``, ``[x2,z,y2]``,-``[z]``.  No matter whether these lists are stored or built on demand,-they take up a quadratic amount of memory (because they cannot share-nodes), and hence it takes a quadratic amount of time just to build-values of this index alone.--But the reasonable expectation is that operations with U-views take-linear time — so we need to erase the index ``xs`` if we want to-achieve this goal.--Changes to Idris-================--Usage analysis is run at every compilation and its outputs are used-for various purposes. This is actually invisible to the user but it's-a relatively big and important change, which enables the new features.--Everything that is found to be unused is erased. No annotations are-needed, just don't use the thing and it will vanish from the generated-code. However, if you wish, you can use the dot annotations to get a-warning if the thing is accidentally used.--"Being used" in this context means that the value of the "thing" may-influence run-time behaviour of the program. (More precisely, it is-not found to be irrelevant to the run-time behaviour by the usage-analysis algorithm.)--"Things" considered for removal by erasure include:--* function arguments--* data constructor fields (including record fields and dictionary-  fields of interface implementations)--For example, ``Either`` often compiles to the same runtime-representation as ``Bool``. Constructor field removal sometimes-combines with the newtype optimisation to have quite a strong effect.--There is a new compiler option ``--warnreach``, which will enable-warnings coming from erasure. Since we have full usage analysis, we-can compile even those programs that violate erasure annotations ---it's just that the binaries may run slower than expected. The warnings-will be enabled by default in future versions of Idris (and possibly-turned to errors). However, in this transitional period, we chose to-keep them on-demand to avoid confusion until better documentation is-written.--Case-tree elaboration tries to avoid using dotted "things" whenever-possible. (NB. This is not yet perfect and it's being worked on:-https://gist.github.com/ziman/10458331)--Postulates are no longer required to be collapsible. They are now-required to be *unused* instead.--Changes to the language-=======================--You can use dots to mark fields that are not intended to be used at-runtime.--.. code-block:: idris--    data Bin : Nat -> Type where-      N : Bin 0-      O : .{n : Nat} -> Bin n -> Bin (0 + 2*n)-      I : .{n : Nat} -> Bin n -> Bin (1 + 2*n)--If these fields are found to be used at runtime, the dots will trigger-a warning (with ``--warnreach``).--Note that free (unbound) implicits are dotted by default so, for-example, the constructor ``O`` can be defined as:--.. code-block:: idris--      O : Bin n -> Bin (0 + 2*n)--and this is actually the preferred form.--If you have a free implicit which is meant to be used at runtime, you-have to change it into an (undotted) ``{bound : implicit}``.--You can also put dots in types of functions to get more guarantees.--.. code-block:: idris--    half : (n : Nat) -> .(pf : Even n) -> Nat--and free implicits are automatically dotted here, too.--What it means-=============--Dot annotations serve two purposes:--* influence case-tree elaboration to avoid dotted variables--* trigger warnings when a dotted variable is used--However, there's no direct connection between being dotted and being-erased. The compiler erases everything it can, dotted or not. The dots-are there mainly to help the programmer (and the compiler) refrain-from using the values they want to erase.--How to use it-=============--Ideally, few or no extra annotations are needed -- in practice, it-turns out that having free implicits automatically dotted is enough to-get good erasure.--Therefore, just compile with ``--warnreach`` to see warnings if-erasure cannot remove parts of the program.--However, those programs that have been written without runtime-behaviour in mind, will need some help to get in the form that-compiles to a reasonable binary. Generally, it's sufficient to follow-erasure warnings (which may be sometimes unhelpful at the moment).--Benchmarks-==========---  source: https://github.com/ziman/idris-benchmarks--  results: http://ziman.functor.sk/erasure-bm/--It can be clearly seen that asymptotics are improved by erasure.--Shortcomings-============--You can't get warnings in libraries because usage analysis starts from-``Main.main``. This will be solved by the planned ``%default_usage``-pragma.--Usage warnings are quite bad and unhelpful at the moment. We should-include more information and at least translate argument numbers to-their names.--There is no decent documentation yet. This wiki page is the first one.--There is no generally accepted terminology. We switch between-"dotted", "unused", "erased", "irrelevant", "inaccessible", while each-has a slightly different meaning. We need more consistent and-understandable naming.--If the same type is used in both erased and non-erased context, it-will retain its fields to accommodate the least common denominator ---the non-erased context. This is particularly troublesome in the case-of the type of (dependent) pairs, where it actually means that no-erasure would be performed. We should probably locate disjoint uses of-data types and split them into "sub-types". There are three different-flavours of dependent types now: ``Sigma`` (nothing erased),-``Exists`` (first component erased), ``Subset`` (second component-erased).--Case-tree building does not avoid dotted values coming from-pattern-matched constructors (https://gist.github.com/ziman/10458331).-This is to be fixed soon. (Fixed.)--Higher-order function arguments and opaque functional variables are-considered to be using all their arguments. To work around this, you-can force erasure via the type system, using the ``Erased`` wrapper:-https://github.com/idris-lang/Idris-dev/blob/master/libs/base/Data/Erased.idr--Interface methods are considered to be using the union of all their-implementations. In other words, an argument of a method is unused-only if it is unused in every implementation of the method that occurs-in the program.--Planned features-================--- Fixes to the above shortcomings in general.--- Improvements to the case-tree elaborator so that it properly avoids-   dotted fields of data constructors. Done.--- Compiler pragma ``%default_usage used/unused`` and per-function-   overrides ``used`` and ``unused``, which allow the programmer to-   mark the return value of a function as used, even if the function-   is not used in ``main`` (which is the case when writing library-   code). These annotations will help library writers discover usage-   violations in their code before it is actually published and used-   in compiled programs.--Troubleshooting-===============--My program is slower-----------------------The patch introducing erasure by usage analysis also disabled some-optimisations that were in place before; these are subsumed by the new-erasure. However, in some erasure-unaware programs, where erasure by-usage analysis does not exercise its full potential (but the old-optimisations would have worked), certain slowdown may be observed (up-to ~10% according to preliminary benchmarking), due to retention and-computation of information that should not be necessary at runtime.--A simple check whether this is the case is to compile with-``--warnreach``. If you see warnings, there is some unnecessary code-getting compiled into the binary.--The solution is to change the code so that there are no warnings.--Usage warnings are unhelpful-------------------------------This is a known issue and we are working on it. For now, see the section-`How to read and resolve erasure-warnings <#how-to-read-and-resolve-erasure-warnings>`__.--There should be no warnings in this function-----------------------------------------------A possible cause is non-totality of the function (more precisely,-non-coverage). If a function is non-covering, the program needs to-inspect all arguments in order to detect coverage failures at runtime.-Since the function inspects all its arguments, nothing can be erased-and this may transitively cause usage violations. The solution is to-make the function total or accept the fact that it will use its-arguments and remove some dots from the appropriate constructor fields-and function arguments. (Please note that this is not a shortcoming of-erasure and there is nothing we can do about it.)--Another possible cause is the currently imperfect case-tree-elaboration, which does not avoid dotted constructor fields (see-https://gist.github.com/ziman/10458331). You can either rephrase the-function or wait until this is fixed, hopefully soon. Fixed.--The compiler refuses to recognise this thing as erased---------------------------------------------------------You can force anything to be erased by wrapping it in the ``Erased``-monad. While this program triggers usage warnings,--.. code-block:: idris--    f : (g : Nat -> Nat) -> .(x : Nat) -> Nat-    f g x = g x  -- WARNING: g uses x--the following program does not:--.. code-block:: idris--    f : (g : Erased Nat -> Nat) -> .(x : Nat) -> Nat-    f g x = g (Erase x)  -- OK--How to read and resolve erasure warnings-========================================--Example 1------------Consider the following program:--.. code-block:: idris--    vlen : Vect n a -> Nat-    vlen {n = n} xs = n--    sumLengths : List (Vect n a) -> Nat-    sumLengths       []  = 0-    sumLengths (v :: vs) = vlen v + sumLengths vs--    main : IO ()-    main = print . sumLengths $ [[0,1],[2,3]]--When you compile it using ``--warnreach``, there is one warning:--.. code-block:: idris--    Main.sumLengths: inaccessible arguments reachable:-      n (no more information available)--The warning does not contain much detail at this point so we can try-compiling with ``--dumpcases cases.txt`` and look up the compiled-definition in ``cases.txt``:--.. code-block:: idris--    Main.sumLengths {e0} {e1} {e2} =-      case {e2} of-      | Prelude.List.::({e6}) => LPlus (ATInt ITBig)({e0}, Main.sumLengths({e0}, ____, {e6}))-      | Prelude.List.Nil() => 0--The reason for the warning is that ``sumLengths`` calls ``vlen``, which-gets inlined. The second clause of ``sumLengths`` then accesses the-variable ``n``, compiled as ``{e0}``. Since ``n`` is a free implicit, it-is automatically considered dotted and this triggers the warning.--A solution would be either making the argument ``n`` a bound implicit-parameter to indicate that we wish to keep it at runtime,--.. code-block:: idris--    sumLengths : {n : Nat} -> List (Vect n a) -> Nat--or fixing ``vlen`` to not use the index:--.. code-block:: idris--    vlen : Vect n a -> Nat-    vlen [] = Z-    vlen (x :: xs) = S (vlen xs)--Which solution is appropriate depends on the usecase.--Example 2------------Consider the following program manipulating value-indexed binary-numbers.--.. code-block:: idris--    data Bin : Nat -> Type where-        N : Bin Z-        O : Bin n -> Bin (0 + n + n)-        I : Bin n -> Bin (1 + n + n)--    toN : (b : Bin n) -> Nat-    toN  N = Z-    toN (O {n} bs) = 0 + n + n-    toN (I {n} bs) = 1 + n + n--    main : IO ()-    main = print . toN $ I (I (O (O (I N))))--In the function ``toN``, we attempted to "cheat" and instead of-traversing the whole structure, we just projected the value index ``n``-out of constructors ``I`` and ``O``. However, this index is a free-implicit, therefore it is considered dotted.--Inspecting it then produces the following warnings when compiling with-``--warnreach``:--.. code-block:: idris--    Main.I: inaccessible arguments reachable:-      n from Main.toN arg# 1-    Main.O: inaccessible arguments reachable:-      n from Main.toN arg# 1--We can see that the argument ``n`` of both ``I`` and ``O`` is used in-the function ``toN``, argument 1.--At this stage of development, warnings only contain argument numbers,-not names; this will hopefully be fixed. When numbering arguments, we-go from 0, taking free implicits first, left-to-right; then the bound-arguments. The function ``toN`` has therefore in fact two arguments:-``n`` (argument 0) and ``b`` (argument 1). And indeed, as the warning-says, we project the dotted field from ``b``.--Again, one solution is to fix the function ``toN`` to calculate its-result honestly; the other one is to accept that we carry a ``Nat``-with every constructor of ``Bin`` and make it a bound implicit:--.. code-block:: idris--        O : {n : Nat} -> Bin n -> Bin (0 + n + n)-        I : {n : Nat} -> bin n -> Bin (1 + n + n)--References-==========--.. [BMM04] Edwin Brady, Conor McBride, James McKinna: `Inductive-           families need not store their indices-           <http://citeseerx.ist.psu.edu/viewdoc/summary;jsessionid=1F796FCF0F2C4C535FC70F62BE2FB821?doi=10.1.1.62.3849>`__
− docs/reference/ffi.rst 
@@ -1,531 +0,0 @@-******************************-New Foreign Function Interface-******************************--.. sectionauthor:: Edwin Brady--Ever since Idris has had multiple backends compiling to different-target languages on potentially different platforms, we have had the-problem that the foreign function interface (FFI) was written under-the assumption of compiling to C. As a result, it has been hard to-write generic code for multiple targets, or even to be sure that if-code compiles that it will run on the expected target.--As of 0.9.17, Idris will have a new foreign function interface (FFI)-which is aware of multiple targets. Users who are working with the-default code generator can happily continue writing programs as before-with no changes, but if you are writing bindings for an external-library, writing a back end, or working with a non-C back end, there-are some things you will need to be aware of, which this page-describes.--The ``IO'`` monad, and ``main``-===============================--The ``IO`` monad exists as before, but is now specific to the C-backend (or, more precisely, any backend whose foreign function calls-are compatible with C.) Additionally, there is now an ``IO'`` monad,-which is parameterised over a FFI descriptor:--.. code-block:: idris--    data IO' : (lang : FFI) -> Type -> Type--The Prelude defines two FFI descriptors which are imported-automatically, for C and JavaScript/Node, and defines ``IO`` to use-the C FFI and ``JS_IO`` to use the JavaScript FFI:--.. code-block:: idris--    FFI_C  : FFI-    FFI_JS : FFI--    IO : Type -> Type-    IO a = IO' FFI_C a--    JS_IO : Type -> Type-    JS_IO a = IO' FFI_JS a--As before, the entry point to an Idris program is ``main``, but the-type of ``main`` can now be any implementation of ``IO'``, e.g. the-following are both valid:--.. code-block:: idris--    main : IO ()-    main : JS_IO ()--The FFI descriptor includes details about which types can be-marshalled between the foreign language and Idris, and the "target" of-a foreign function call (typically just a String representation of the-function's name, but potentially something more complicated such as an-external library file or even a URL).--FFI descriptors-===============--An FFI descriptor is a record containing a predicate which holds when-a type can be marshalled, and the type of the target of a foreign-call:--.. code-block:: idris--    record FFI where-         constructor MkFFI-         ffi_types : Type -> Type-         ffi_fn : Type--For C, this is:--.. code-block:: idris--    ||| Supported C integer types-    public export-    data C_IntTypes : Type -> Type where-        C_IntChar   : C_IntTypes Char-        C_IntNative : C_IntTypes Int-        C_IntBits8  : C_IntTypes Bits8-        C_IntBits16 : C_IntTypes Bits16-        C_IntBits32 : C_IntTypes Bits32-        C_IntBits64 : C_IntTypes Bits64--    ||| Supported C function types-    public export-    data C_FnTypes : Type -> Type where-        C_Fn : C_Types s -> C_FnTypes t -> C_FnTypes (s -> t)-        C_FnIO : C_Types t -> C_FnTypes (IO' FFI_C t)-        C_FnBase : C_Types t -> C_FnTypes t--    ||| Supported C foreign types-    public export-    data C_Types : Type -> Type where-        C_Str   : C_Types String-        C_Float : C_Types Double-        C_Ptr   : C_Types Ptr-        C_MPtr  : C_Types ManagedPtr-        C_Unit  : C_Types ()-        C_Any   : C_Types (Raw a)-        C_FnT   : C_FnTypes t -> C_Types (CFnPtr t)-        C_IntT  : C_IntTypes i -> C_Types i--    ||| A descriptor for the C FFI. See the constructors of `C_Types`-    ||| and `C_IntTypes` for the concrete types that are available.-    %error_reverse-    public export-    FFI_C : FFI-        FFI_C = MkFFI C_Types String String--Linking foreign code-====================--This is the example of linking C code. --.. code-block:: idris-    %include C "mylib.h"-    %link C "mylib.o"--Example Makefile--.. code-block:: shell-    DEFAULT: mylib.o main.idr-    	idris main.idr -o executableFile--    clean:-    	rm -f executableFile mylib.o main.ibc--Foreign calls-=============--To call a foreign function, the ``foreign`` function is used. For-example:--.. code-block:: idris--    do_fopen : String -> String -> IO Ptr-    do_fopen f m-       = foreign FFI_C "fileOpen" (String -> String -> IO Ptr) f m--The ``foreign`` function takes an FFI description, a function name (the-type is given by the ``ffi_fn`` field of ``FFI_C`` here), and a function-type, which gives the expected types of the remaining arguments. Here,-we're calling an external function ``fileOpen`` which takes, in the C, a-``char*`` file name, a ``char*`` mode, and returns a file pointer. It is-the job of the C back end to convert Idris ``String`` to C ``char*``-and vice versa.--The argument types and return type given here must be present in the-``fn_types`` predicate of the ``FFI_C`` description for the foreign-call to be valid.--**Note** The arguments to ``foreign`` *must* be known at compile time,-because the foreign calls are generated statically. The ``%inline``-directive on a function can be used to give hints to help this, for-example a shorthand for calling external JavaScript functions:--.. code-block:: idris--    %inline-    jscall : (fname : String) -> (ty : Type) ->-              {auto fty : FTy FFI_JS [] ty} -> ty-    jscall fname ty = foreign FFI_JS fname ty--C callbacks-------------It is possible to pass an Idris function to a C function taking a function-pointer by using ``CFnPtr`` in the function type. The Idris function is passed-to ``MkCFnPtr`` in the arguments. The example below shows declaring the C standard-library function ``qsort`` which takes a pointer to a comparison function.--.. code-block:: idris--    myComparer : Ptr -> Ptr -> Int-    myComparer = ...--    qsort : Ptr -> Int -> Int -> IO ()-    qsort data elems elsize = foreign FFI_C "qsort"-                    (Ptr -> Int -> Int -> CFnPtr (Ptr -> Ptr -> Int) -> IO ())-                    data elems elsize (MkCFnPtr myComparer)--There are a few limitations to callbacks in the C FFI. The foreign function can't-take the function to make a callback of as an argument. This will give a-compilation error:--.. code-block:: idris--    -- This does not work-    example : (Int -> ()) -> IO ()-    example f = foreign FFI_C "callbacker" (CFnPtr (Int -> ()) -> IO ()) f--Note that the function that is used as a callback can't be a closure, that is-it can't be a partially applied function. This is because the mechanism used is-unable to pass the closed-over values through C. If we want to pass Idris values-to the callback we have to pass them through C explicitly. Non-primitive Idris-values can be passed to C via the ``Raw`` type.--The other big limitation is that it doesn't support IO functions. Use-``unsafePerformIO`` to wrap them (i.e. to make an IO function usable as a callback, change the return type-from IOr to r, and change the = do to = unsafePerformIO $ do).--There are two special function names:-``%wrapper`` returns the function pointer that wraps an Idris function. This-is useful if the function pointer isn't taken by a C function directly but-should be inserted into a data structure. A foreign declaration using-``%wrapper`` must return ``IO Ptr``.--.. code-block:: idris--    -- this returns the C function pointer to a qsort comparer-    example_wrapper : IO Ptr-    example_wrapper = foreign FFI_C "%wrapper" (CFnPtr (Ptr -> Ptr -> Int) -> IO Ptr)-                            (MkCFnPtr myComparer)--``%dynamic`` calls a C function pointer with some arguments. This is useful if-a C function returns or data structure contains a C function pointer, for example-structs of function pointers are common in object-oriented C such as in COM or the-Linux kernel. The function type contains an extra ``Ptr`` at the start for the-function pointer. ``%dynamic`` can be seen as a pseudo-function that calls the-function in the first argument, passing the remaining arguments to it.--.. code-block:: idris--    -- we have a pointer to a function with the signature int f(int), call it-    example_dynamic : Ptr -> Int -> IO Int-    example_dynamic fn x = foreign FFI_C "%dynamic" (Ptr -> Int -> IO Int) fn x--If the foreign name is prefixed by a ``&``, it is treated as a pointer to the-global variable with the following name. The type must be just ``IO Ptr``.--.. code-block:: idris--    -- access the global variable errno-    errno : IO Ptr-    errno = foreign FFI_C "&errno" (IO Ptr)--If the foreign name is prefixed by a ``#``, the name is pasted in literally. This is-useful to access constants that are preprocessor definitions (like ``INT_MAX``).--.. code-block:: idris--    %include C "limits.h"--    -- access the preprocessor definition INT_MAX-    intMax : IO Int-    intMax = foreign FFI_C "#INT_MAX" (IO Int)--    main : IO ()-    main = print !intMax--For more complicated interactions with C (such as reading and setting fields-of a C struct), there is a module CFFI available in the contrib package.--C heap---------Idris has two heaps where objects can be allocated:--+--------------------------------------+---------------------------------------+-| FP heap                              | C heap                                |-+======================================+=======================================+-| Cheney-collected                     | Mark-and-sweep-collected              |-+--------------------------------------+---------------------------------------+-| Garbage collections touches only     | Garbage collection has to traverse    |-| live objects.                        | all registered items.                 |-+--------------------------------------+---------------------------------------+-| Ideal for FP-style rapid allocation  | Ideal for C-style allocation of a few |-| of lots of small short-lived pieces  | big buffers.                          |-| of memory, such as data constructors.|                                       |-+--------------------------------------+---------------------------------------+-| Finalizers are impossible to support | Items have finalizers that are called |-| reasonably.                          | on deallocation.                      |-+--------------------------------------+---------------------------------------+-| Data is copied all the time (when    | Copying does not happen.              |-| collecting garbage, modifying data,  |                                       |-| registering managed pointers, etc.)  |                                       |-+--------------------------------------+---------------------------------------+-| Contains objects of various types.   | Contains C heap items: ``(void *)``   |-|                                      | pointers with finalizers. A finalizer |-|                                      | is a routine that deallocates the     |-|                                      | resources associated with the item.   |-+--------------------------------------+---------------------------------------+-| Fixed set of object types.           | The data pointer may point            |-|                                      | to anything, as long as the finalizer |-|                                      | cleans up correctly.                  |-+--------------------------------------+---------------------------------------+-| Not suitable for C resources and     | Suitable for C resources and arbitrary|-| arbitrary pointers.                  | pointers.                             |-+--------------------------------------+---------------------------------------+-| Values form a compact memory block.  | Items are kept in a linked list.      |-+--------------------------------------+---------------------------------------+-| Any Idris value, most notably        | Items represented by the              |-| ``ManagedPtr``.                      | Idris type ``CData``.                 |-+--------------------------------------+---------------------------------------+-| Data of ``ManagedPtr`` allocated     | Data allocated in C, pointer copied   |-| in C, buffer then copied into the FP | into the C heap.                      |-| heap.                                |                                       |-+--------------------------------------+---------------------------------------+-| Allocation and reallocation not      | Allocated and reallocate freely in C, |-| possible from C code (without having | registering the allocated items       |-| a reference to the VM). Everything   | in the FFI.                           |-| is copied instead.                   |                                       |-+--------------------------------------+---------------------------------------+--The FP heap is the primary heap. It may contain values of type ``CData``,-which are references to items in the C heap. A C heap item contains-a ``(void *)`` pointer and the corresponding finalizer. Once a C heap item-is no longer referenced from the FP heap, it is marked as unused and-the next GC sweep will call its finalizer and deallocate it.--There is no Idris interface for ``CData`` other than its type and FFI.--Usage from C code-~~~~~~~~~~~~~~~~~--* Although not enforced in code, ``CData`` is meant to be opaque-  and non-RTS code (such as libraries or C bindings) should-  access only its ``(void *)`` field called ``data``.--* Feel free to mutate both the pointer ``data`` (eg. after calling ``realloc``)-  and the memory it points to. However, keep in mind-  that this must not break Idris's referential transparency.--* **WARNING!** If you call ``cdata_allocate`` or ``cdata_manage``,-  the resulting ``CData`` object *must* be returned from your-  FFI function so that it is inserted in the C heap by the RTS.-  Otherwise the memory will be leaked.--.. code:: idris--    some_allocating_fun : Int -> IO CData-    some_allocating_fun i = foreign FFI_C "some_allocating_fun" (Int -> IO CData) i--    other_fun : CData -> Int -> IO Int-    other_fun cd i = foreign FFI_C "other_fun" (CData -> Int -> IO Int) cd i--.. code:: cpp--    #include "idris_rts.h"--    static void finalizer(void * data)-    {-        MyStruct * ptr = (MyStruct *) data;-        free_something(ptr->something);-        free(ptr);-    }--    CData some_allocating_fun(int arg)-    {-        size_t size = sizeof(...);-        void * data = (void *) malloc(size);-        // ...-        return cdata_manage(data, size, finalizer);-    }--    int other_fun(CData cd, int arg)-    {-        int result = foo(cd->data);-        return result;-    }--The ``Raw`` type constructor allows you to access or return a runtime-representation of the value. For instance, if you want to copy a string-generated from C code into an Idris value, you may want to return a-``Raw String``instead of a ``String`` and use ``MKSTR`` or ``MKSTRlen`` to-copy it over.--.. code-block:: idris--    getString : () -> IO (Raw String)-    getString () = foreign FFI_C "get_string" (IO (Raw String))--.. code-block:: cpp--    const VAL get_string ()-    {-        char * c_string = get_string_allocated_with_malloc()-        const VAL idris_string = MKSTR(c_string);-        free(c_string);-        return idris_string-    }--FFI implementation---------------------In order to write bindings to external libraries, the details of how-``foreign`` works are unnecessary --- you simply need to know that-``foreign`` takes an FFI descriptor, the function name, and its-type. It is instructive to look a little deeper, however:--The type of ``foreign`` is as follows:--.. code-block:: idris--    foreign : (ffi : FFI)-           -> (fname : ffi_fn f)-           -> (ty : Type)-           -> {auto fty : FTy ffi [] ty}-           -> ty--The important argument here is the implicit ``fty``, which contains a-proof (``FTy``) that the given type is valid according to the FFI-description ``ffi``:--.. code-block:: idris--    data FTy : FFI -> List Type -> Type -> Type where-         FRet : ffi_types f t -> FTy f xs (IO' f t)-         FFun : ffi_types f s -> FTy f (s :: xs) t -> FTy f xs (s -> t)--Notice that this uses the ``ffi_types`` field of the FFI descriptor---- these arguments to ``FRet`` and ``FFun`` give explicit proofs that-the type is valid in this FFI. For example, the above ``do_fopen``-builds the following implicit proof as the ``fty`` argument to-``foreign``:--.. code-block:: idris--    FFun C_Str (FFun C_Str (FRet C_Ptr))--Compiling foreign calls-=======================--(This section assumes some knowledge of the Idris internals.)--When writing a back end, we now need to know how to compile-``foreign``.  We'll skip the details here of how a ``foreign`` call-reaches the intermediate representation (the IR), though you can look-in ``IO.idr`` in the ``prelude`` package to see a bit more detail ----a ``foreign`` call is implemented by the primitive function-``mkForeignPrim``. The important part of the IR as defined in-``Lang.hs`` is the following constructor:--.. code-block:: idris--    data LExp = ...-              | LForeign FDesc -- Function descriptor-                         FDesc -- Return type descriptor-                         [(FDesc, LExp)]--So, a ``foreign`` call appears in the IR as the ``LForeign``-constructor, which takes a function descriptor (of a type given by the-``ffi_fn`` field in the FFI descriptor), a return type descriptor-(given by an application of ``FTy``), and a list of arguments with-type descriptors (also given by an application of ``FTy``).--An ``FDesc`` describes an application of a name to some arguments, and-is really just a simplified subset of an ``LExp``:--.. code-block:: idris--    data FDesc = FCon Name-               | FStr String-               | FUnknown-               | FApp Name [FDesc]--There are corresponding structures in the lower level IRs, such as the-defunctionalised, simplified and bytecode forms.--Our ``do_fopen`` example above arrives in the ``LExp`` form as:--.. code-block:: idris--    LForeign (FStr "fileOpen") (FCon (sUN "C_Ptr"))-             [(FCon (sUN "C_Str"), f), (FCon (sUN "C_Str"), m)]--(Assuming that ``f`` and ``m`` stand for the ``LExp`` representations-of the arguments.) This information should be enough for any back end-to marshal the arguments and return value appropriately.--.. note::--   When processing ``FDesc``, be aware that there may be implicit-   arguments, which have not been erased. For example, ``C_IntT`` has-   an implicit argument ``i``, so will appear in an ``FDesc`` as-   something of the form ``FApp (sUN "C_IntT") [i, t]`` where ``i`` is-   the implicit argument (which can be ignored) and ``t`` is the-   descriptor of the integer type. See ``CodegenC.hs``, specifically-   the function ``toFType``, to see how this works in practice.--JavaScript FFI descriptor-=========================--The JavaScript FFI descriptor is a little more complex, because the-JavaScript FFI supports marshalling functions. It is defined as-follows:--.. code-block:: idris--    mutual-      data JsFn t = MkJsFn t--      data JS_IntTypes  : Type -> Type where-           JS_IntChar   : JS_IntTypes Char-           JS_IntNative : JS_IntTypes Int--      data JS_FnTypes : Type -> Type where-           JS_Fn     : JS_Types s -> JS_FnTypes t -> JS_FnTypes (s -> t)-           JS_FnIO   : JS_Types t -> JS_FnTypes (IO' l t)-           JS_FnBase : JS_Types t -> JS_FnTypes t--      data JS_Types : Type -> Type where-           JS_Str   : JS_Types String-           JS_Float : JS_Types Double-           JS_Ptr   : JS_Types Ptr-           JS_Unit  : JS_Types ()-           JS_FnT   : JS_FnTypes a -> JS_Types (JsFn a)-           JS_IntT  : JS_IntTypes i -> JS_Types i--The reason for wrapping function types in a ``JsFn`` is to help the-proof search when building ``FTy``. We hope to improve proof search-eventually, but for the moment it works much more reliably if the-indices are disjoint! An example of using this appears in `IdrisScript-<https://github.com/idris-hackers/IdrisScript>`__ when setting-timeouts:--.. code-block:: idris--    setTimeout : (() -> JS_IO ()) -> (millis : Int) -> JS_IO Timeout-    setTimeout f millis = do-      timeout <- jscall "setTimeout(%0, %1)"-                        (JsFn (() -> JS_IO ()) -> Int -> JS_IO Ptr)-                        (MkJsFn f) millis-      pure $ MkTimeout timeout
− docs/reference/ide-protocol.rst 
@@ -1,213 +0,0 @@-********************-The IDE Protocol-********************--The Idris REPL has two modes of interaction: a human-readable syntax designed for direct use in a terminal, and a machine-readable syntax designed for using Idris as a backend for external tools.--Protocol Overview--------------------The communication protocol is of asynchronous request-reply style: a single request from the client is handled by Idris at a time.-Idris waits for a request on its standard input stream, and outputs the answer or answers to standard output.-The result of a request can be either success, failure, or intermediate output; and furthermore, before the result is delivered, there might be additional meta-messages.---A reply can consist of multiple messages: any number of messages to inform the user about the progress of the request or other informational output, and finally a result, either ``ok`` or ``error``.--The wire format is the length of the message in characters, encoded in 6 characters hexadecimal, followed by the message encoded as S-expression (sexp).-Additionally, each request includes a unique integer (counting upwards), which is repeated in all messages corresponding to that request.--An example interaction from loading the file ``/home/hannes/empty.idr`` looks as follows on the wire:::--  00002a((:load-file "/home/hannes/empty.idr") 1)-  000039(:write-string "Type checking /home/hannes/empty.idr" 1)-  000025(:set-prompt "/home/hannes/empty" 1)-  000032(:return (:ok "Loaded /home/hannes/empty.idr") 1)---The first message is the request from idris-mode to load the specific file, which length is hex 2a, decimal 42 (including the newline at the end).-The request identifier is set to 1.-The first message from Idris is to write the string ``Type checking /home/hannes/empty.idr``, another is to set the prompt to ``*/home/hannes/empty``.-The answer, starting with ``:return`` is ``ok``, and additional information is that the file was loaded.--There are three atoms in the wire language: numbers, strings, and symbols.-The only compound object is a list, which is surrounded by parenthesis.-The syntax is::--  A ::= NUM | '"' STR '"' | ':' ALPHA+-  S ::= A | '(' S* ')' | nil--where ``NUM`` is either 0 or a positive integer, ``ALPHA`` is an alphabetical character, and ``STR`` is the contents of a string, with ``"`` escaped by a backslash.-The atom ``nil`` is accepted instead of ``()`` for compatibility with some regexp pretty-printing routines.--The state of the Idris process is mainly the active file, which needs to be kept synchronised between the editor and Idris.-This is achieved by the already seen ``:load-file`` command.--The available commands include:--  ``(:load-file FILENAME [LINE])``-    Load the named file.  If a ``LINE`` number is provided, the file is only loaded up to that line.  Otherwise, the entire file is loaded.--  ``(:interpret STRING)``-    Interpret ``STRING`` at the Idris REPL, returning a highlighted result.--  ``(:type-of STRING)``-    Return the type of the name, written with Idris syntax in the ``STRING``.-    The reply may contain highlighting information.--  ``(:case-split LINE NAME)``-    Generate a case-split for the pattern variable ``NAME`` on program line ``LINE``.-    The pattern-match cases to be substituted are returned as a string with no highlighting.--  ``(:add-clause LINE NAME)``-    Generate an initial pattern-match clause for the function declared as ``NAME`` on program line ``LINE``.-    The initial clause is returned as a string with no highlighting.--  ``(:add-proof-clause LINE NAME)``-    Add a clause driven by the ``<==`` syntax.--  ``(:add-missing LINE NAME)``-    Add the missing cases discovered by totality checking the function declared as ``NAME`` on program line ``LINE``.-    The missing clauses are returned as a string with no highlighting.--  ``(:make-with LINE NAME)``-    Create a with-rule pattern match template for the clause of function ``NAME`` on line ``LINE``.-    The new code is returned with no highlighting.--  ``(:make-case LINE NAME)``-    Create a case pattern match template for the clause of function ``NAME`` on line ``LINE``.-    The new code is returned with no highlighting.--  ``(:make-lemma LINE NAME)``-    Create a top level function with a type which solves the hole named ``NAME`` on line ``LINE``.--  ``(:proof-search LINE NAME HINTS)``-    Attempt to fill out the holes on ``LINE`` named ``NAME`` by proof search.-    ``HINTS`` is a possibly-empty list of additional things to try while searching.--  ``(:docs-for NAME [MODE])``-    Look up the documentation for ``NAME``, and return it as a highlighted string. If ``MODE`` is ``:overview``, only the first paragraph of documentation is provided for ``NAME``.  If ``MODE`` is ``:full``, or omitted, the full documentation is returned for ``NAME``.- -  ``(:apropos STRING)``-    Search the documentation for mentions of ``STRING``, and return any found as a list of highlighted strings.- -  ``(:metavariables WIDTH)``-    List the currently-active holes, with their types pretty-printed with ``WIDTH`` columns.--  ``(:who-calls NAME)``-    Get a list of callers of ``NAME``.--  ``(:calls-who NAME)``-    Get a list of callees of ``NAME``.--  ``(:browse-namespace NAMESPACE)``-    Return the contents of ``NAMESPACE``, like ``:browse`` at the command-line REPL.--  ``(:normalise-term TM)``-    Return a highlighted string consisting of the results of normalising the serialised term ``TM`` (which would previously have been sent as the ``tt-term`` property of a string).--  ``(:show-term-implicits TM)``-    Return a highlighted string consisting of the results of making all arguments in serialised term ``TM`` (which would previously have been sent as the ``tt-term`` property of a string) explicit.--  ``(:hide-term-implicits TM)``-    Return a highlighted string consisting of the results of making all arguments in serialised term ``TM`` (which would previously have been sent as the ``tt-term`` property of a string) follow their usual implicitness setting.--  ``(:elaborate-term TM)``-    Return a highlighted string consisting of the core language term corresponding to serialised term ``TM`` (which would previously have been sent as the ``tt-term`` property of a string).--  ``(:print-definition NAME)``-    Return the definition of ``NAME`` as a highlighted string.--  ``(:repl-completions NAME)``-    Search names, types and documentations which contain ``NAME``. Return the result of tab-completing ``NAME`` as a REPL command.--  ``:version``-    Return the version information of the Idris compiler.----Possible replies include a normal final reply:::-- (:return (:ok SEXP [HIGHLIGHTING]))- (:return (:error String [HIGHLIGHTING]))--A normal intermediate reply:::-- (:output (:ok SEXP [HIGHLIGHTING]))- (:output (:error String [HIGHLIGHTING]))--Informational and/or abnormal replies:::--  (:write-string String)-  (:set-prompt String)-  (:warning (FilePath (LINE COL) (LINE COL) String [HIGHLIGHTING]))--Proof mode replies:::--  (:start-proof-mode)-  (:write-proof-state [String] [HIGHLIGHTING])-  (:end-proof-mode)-  (:write-goal String)--Output Highlighting----------------------Idris mode supports highlighting the output from Idris.-In reality, this highlighting is controlled by the Idris compiler.-Some of the return forms from Idris support an optional extra parameter: a list mapping spans of text to metadata about that text.-Clients can then use this list both to highlight the displayed output and to enable richer interaction by having more metadata present.-For example, the Emacs mode allows right-clicking identifiers to get a menu with access to documentation and type signatures.---A particular semantic span is a three element list.-The first element of the list is the index at which the span begins, the second element is the number of characters included in the span, and the third is the semantic data itself.-The semantic data is a list of lists.-The head of each list is a key that denotes what kind of metadata is in the list, and the tail is the metadata itself.--The following keys are available:-  ``name``-    gives a reference to the fully-qualified Idris name-  ``implicit``-    provides a Boolean value that is True if the region is the name of an implicit argument-  ``decor``-    describes the category of a token, which can be ``type``, ``function``, ``data``, ``keyword``, or ``bound``.--  ``source-loc``-    states that the region refers to a source code location. Its body is a collection of key-value pairs, with the following possibilities:--    ``filename``-      provides the filename--    ``start``-      provides the line and column that the source location starts at as a two-element tail--    ``end``-      provides the line and column that the source location ends at as a two-element tail--  ``text-formatting``-    provides an attribute of formatted text. This is for use with natural-language text, not code, and is presently emitted only from inline documentation. The potential values are ``bold``, ``italic``, and ``underline``.--  ``link-href``-    provides a URL that the corresponding text is a link to. --  ``quasiquotation``-    states that the region is quasiquoted.--  ``antiquotation``-    states that the region is antiquoted.--  ``tt-term``-    A serialised representation of the Idris core term corresponding to the region of text.--Source Code Highlighting---------------------------Idris supports instructing editors how to colour their code.-When elaborating source code or REPL input, Idris will locate regions of the source code corresponding to names, and emit information about these names using the same metadata as output highlighting.--These messages will arrive as replies to the command that caused elaboration to occur, such as ``:load-file`` or ``:interpret``.-They have the format:::--  (:output (:ok (:highlight-source POSNS)))--where ``POSNS`` is a list of positions to highlight. Each of these is a two-element list whose first element is a position (encoded as for the ``source-loc`` property above) and whose second element is highlighting metadata in the same format used for output.
− docs/reference/index.rst 
@@ -1,42 +0,0 @@-.. _reference-index:--###################-Language Reference-###################--This is the reference guide for the Idris Language.-It documents the language specification and internals.-This will tell you how Idris works, for using it you should read the Idris Tutorial.--.. note::-   The documentation for Idris has been published under the Creative-   Commons CC0 License. As such to the extent possible under law, *The-   Idris Community* has waived all copyright and related or neighboring-   rights to Documentation for Idris.--   More information concerning the CC0 can be found online at: http://creativecommons.org/publicdomain/zero/1.0/---.. toctree::-   :maxdepth: 1--   codegen-   documenting-   packages-   uniqueness-types-   ffi-   syntax-guide-   syntax-reference-   erasure-   ide-protocol-   semantic-highlighting-   tactics-   repl-   compilation-   internals-   language-features-   language-extensions-   elaborator-reflection-   type-directed-search-   partial-evaluation-   misc
− docs/reference/internals.rst 
@@ -1,176 +0,0 @@-*****************-Idris' Internals-*****************--Note: this is still a fairly raw set of notes taken by David-Christiansen at Edwin's presentation at the 2013 Idris Developers-Meeting. They're in the process of turning into a useful guide - feel-free to contribute.--This document assumes that you are already familiar with Idris. It is-intended for those who want to work on the internals.--People looking to develop new back ends may want to look at [[Idris back-end IRs\|Idris-back-end-IRs]]--Core/TT.hs-==========--Idris is compiled to a simple, explicit core language. This core-language is called TT because it looks a bit like a Π. It's a minimal-language, with a locally nameless representation. That is, local-variables are represented with de Bruijn indices and globally-defined-constants are represented with names.--The ``TT`` datatype uses a trick that is common in the Idris code: it is-polymorphic over the type of names stored in it, and it derives-``Functor``. This allows ``fmap`` to be used as a general-purpose-traversal.--There is a general construction for binders, used for λ, Π, and-let-bindings. These are distinguished using a ``BinderType``.--During compilation, some terms (especially types) will be erased. This-is represented using the ``Erased`` constructor of ``TT``. A handy trick-when generating TT terms is to insert ``Erased`` where a term is-uniquely determined, as the typechecker will fill it out.--The constructor ``Proj`` is a result of the optimizer. It is used to-extract a specific constructor argument, in a more economical way than-defining a new pattern-matching operation.--The datatype ``Raw`` represents terms that have not yet been-typechecked. The typechecker converts a ``Raw`` to a ``TT`` if it can.--Core/CaseTree.hs-================--Case trees are used to represent top-level pattern-matching definitions-in the TT language.--Just as with the ``TT`` datatype, the ``deriving Functor`` trick is used-with ``SC`` and ``CaseAlt`` to get GHC to generate a function for-mapping over contained terms.--Constructor cases (``ConCase`` in ``CaseAlt``) refer to numbered-constructors. Every constructor is numbered 0,1,2,…. At this stage in-the compiler, the tags are datatype-local. After defunctionalization,-however, they are made globally unique.--The ``n+1`` patterns (``SucCase``) and hacky-seeming things are to make-code fast -- please ask before "cleaning up" the representation.--Core/Evaluate.hs-================--This module contains the main evaluator for Idris. The evaluator is used-both at the REPL and during type checking, where normalised terms need-to be compared for equality.--A key datatype in the evaluator is a *context*. Contexts are mappings-from global names to their values, but they are organized to make-type-directed disambiguation quick. In particular, the main part of a-name that a user might type is used as the key, and its values are maps-from namespaces to actual values.--The datatype ``Def`` represents a definition in the global context. All-global names map to this structure.--``Type`` and ``Term`` are both synonyms for ``TT``.--Datatypes are represented by a ``TyDecl`` with the appropriate-``NameType``. A ``Function`` is a global constant term with an annotated-type, ``Operator`` represents primitives implemented in Haskell, and-``CaseOp`` represents ordinary pattern-matching definitions. ``CaseOp``-has four versions for different purposes, and all are saved because-that's easiest.--``CaseInfo``: the ``tc_dictionary`` is because it's a type class-dictionary which makes totality checking easier.--The ``normalise*`` functions give different behaviors - but-``normalise`` is the most common.--``normaliseC`` - "resolved" means with names converted to de Bruijn-indices as appropriate.--``normaliseAll`` - reduce everything, even if it's non-total--``normaliseTrace`` - special-purpose for debugging--``simplify`` - reduce the things that are small - the list argument is-the things to not reduce.--Core/Typecheck.hs-=================--Standard stuff. Hopefully no changes are necessary.--Core/Elaborate.hs-=================--Idris definitions are elaborated one by one and turned into the-corresponding TT. This is done with a tactic language as an EDSL in the-Elab monad (or Elab' when there's a custom state).--Lots of plumbing for errors.--All elaboration is relative to a global context.--The string in the pair returned by elaborate is log information.--See JFP paper, but the names don't necessarily map to each other. The-paper is the "idealized version" without logging, additional state, etc.--All the tactics take Raws, typechecking happens there.--claim (x : t) assumes a new x : t.--PLEASE TIDY THINGS UP!--proofSearch flag to try' is whether the failure came from a human (so-fail) or from a machine (so continue)--Idris-level syntax for providing alternatives explicitly: (\| x, y, z-\|) try x, y, z in order, and take the first that succeeds.--Core/ProofState.hs-==================--Core/Unify.hs-=============--Deals with unification. Unification can reply with: - this works - this-can never work - this will work if these other unification problems work-out (eg unifying f x with 1)--match\_unify: same thing as unification except it's just matching name-against name, term against term. x + y matches to 0 + y with x = 0. Used-for <== syntax as well as type class resolution.--Idris/AbsSyntaxTree.hs-======================--PTerm is the datatype of Idris syntax. P is for Program. Each PTerm-turns into a TT term by applying a series of tactics.--IState is the major interpreter state. The global context is the-tt\_ctxt field.--Ctxt maps possibly ambiguous names to their referents.--Idris/ElabDecls.hs-==================--This is where the actual elaboration from PTerm to TT happens.--Idris/ElabTerm.hs-=================--build is the function that creates a Raw. All the "junk" is to deal with-things like metavars and so forth. It has to remember what names are-still to be defined, and it doesn't yet know the type (filled in by-unificaiton later). Also case expressions have to turn into top-level-functions.--resolveTC is type class resolution.
− docs/reference/language-extensions.rst 
@@ -1,36 +0,0 @@-*******************-Language Extensions-*******************----Type Providers-===============--Idris type providers are a way to get the type system to reflect-observations about the world outside of Idris. Similarly to `F# type-providers <http://msdn.microsoft.com/en-us/library/vstudio/hh156509.aspx>`__,-they cause effectful computations to run during type checking, returning-information that the type checker can use when checking the rest of the-program. While F# type providers are based on code generation, Idris-type providers use only the ordinary execution semantics of Idris to-generate the information.--A type provider is simply a term of type ``IO (Provider t)``, where-``Provider`` is a data type with constructors for a successful result-and an error. The type ``t`` can be either ``Type`` (the type of types)-or a concrete type. Then, a type provider ``p`` is invoked using the-syntax ``%provide (x : t) with p``. When the type checker encounters-this line, the IO action ``p`` is executed. Then, the resulting term is-extracted from the IO monad. If it is ``Provide y`` for some ``y : t``,-then ``x`` is bound to ``y`` for the remainder of typechecking and in-the compiled code. If execution fails, a generic error is reported and-type checking terminates. If the resulting term is ``Error e`` for some-string ``e``, then type checking fails and the error ``e`` is reported-to the user.--Example Idris type providers can be seen at `this-repository <https://github.com/david-christiansen/idris-type-providers>`__.-More detailed descriptions are available in David Christiansen's `WGP-'13 paper <http://dx.doi.org/10.1145/2502488.2502495>`__ and `M.Sc.-thesis <http://itu.dk/people/drc/david-christiansen-thesis.pdf>`__.
− docs/reference/language-features.rst 
@@ -1,54 +0,0 @@-**********************-Core Language Features-**********************----  Full-spectrum dependent types--  Strict evaluation (plus ``Lazy : Type -> Type`` type constructor for-   explicit laziness)--  Lambda, Pi (forall), Let bindings--  Pattern matching definitions--  Export modifiers ``public``, ``abstract``, ``private``--  Function options ``partial``, ``total``--  ``where`` clauses--  "magic with"--  Implicit arguments (in top level types)--  "Bound" implicit arguments ``{n : Nat} -> {a : Type} -> Vect n a``--  "Unbound" implicit arguments --- ``Vect n a`` is equivalent to the-   above in a type, ``n`` and ``a`` are implicitly bound. This applies-   to names beginning with a lower case letter in an argument position.--  'Tactic' implicit arguments, which are solved by running a tactic-   script or giving a default argument, rather than by unification.--  Unit type ``()``, empty type ``Void``--  Tuples (desugaring to nested pairs)--  Dependent pair syntax ``(x : T ** P x)`` (there exists an ``x`` of-   type ``T`` such that ``P x``)--  Inline ``case`` expressions--  Heterogeneous equality--  ``do`` notation--  Idiom brackets--  Interfaces (like type classes), supporting default methods and dependencies between-   methods--  ``rewrite`` prf ``in`` expr--  Metavariables--  Inline proof/tactic scripts--  Implicit coercion--  ``codata``--  Also ``Inf : Type -> Type`` type constructor for mixed data/codata.-   In fact ``codata`` is implemented by putting recursive arguments under-   ``Inf``.--  ``syntax`` rules for defining pattern and term syntactic sugar--  these are used in the standard library to define-   ``if ... then ... else`` expressions and an Agda-style preorder-   reasoning syntax.--  `Uniqueness-   typing <https://github.com/idris-lang/Idris-dev/wiki/Uniqueness-Types>`__-   using the ``UniqueType`` universe.--  `Partial-   evaluation <https://github.com/idris-lang/Idris-dev/wiki/Static-Arguments-and-Partial-Evaluation>`__-   by ``%static`` argument annotations.--  Error message reflection--  Eliminators--  Label types ``'name``--  ``%logging n``--  ``%unifyLog``
− docs/reference/misc.rst 
@@ -1,228 +0,0 @@-**************-Miscellaneous-**************--Things we have yet to classify, or are two small to justify their own page.---The Unifier Log-===============--If you're having a hard time debugging why the unifier won't accept-something (often while debugging the compiler itself), try applying the-special operator ``%unifyLog`` to the expression in question. This will-cause the type checker to spit out all sorts of informative messages.---Namespaces and type-directed disambiguation-===========================================--Names can be defined in separate namespaces, and disambiguated by type.-An expression ``with NAME EXPR`` will privilege the namespace ``NAME``-in the expression ``EXPR``. For example:--::--    Idris> with List [[1,2],[3,4],[5,6]]-    [[1, 2], [3, 4], [5, 6]] : List (List Integer)--    Idris> with Vect [[1,2],[3,4],[5,6]]-    [[1, 2], [3, 4], [5, 6]] : Vect 3 (Vect 2 Integer)--    Idris> [[1,2],[3,4],[5,6]]-    Can't disambiguate name: Prelude.List.::, Prelude.Stream.::, Prelude.Vect.::---Alternatives-============--The syntax ``(| option1, option2, option3, ... |)`` type checks each-of the options in turn until one of them works. This is used, for-example, when translating integer literals.--::--    Idris> the Nat (| "foo", Z, (-3) |)-    0 : Nat---This can also be used to give simple automated proofs, for example: trying-some constructors of proofs.--::--    syntax Trivial = (| Oh, Refl |)---Totality checking assertions-============================--All definitions are checked for *coverage* (i.e. all well-typed-applications are handled) and either for *termination* (i.e. all-well-typed applications will eventually produce an answer) or, if-returning codata, for productivity (in practice, all recursive calls are-constructor guarded).--Obviously, termination checking is undecidable. In practice, the-termination checker looks for *size change* - every cycle of recursive-calls must have a decreasing argument, such as a recursive argument of a-strictly positive data type.--There are two built-in functions which can be used to give the totality-checker a hint:---  ``assert_total x`` asserts that the expression ``x`` is terminating-   and covering, even if the totality checker cannot tell. This can be-   used for example if ``x`` uses a function which does not cover all-   inputs, but the caller knows that the specific input is covered.--  ``assert_smaller p x`` asserts that the expression ``x`` is-   structurally smaller than the pattern ``p``.--For example, the following function is not checked as total:--::--    qsort : Ord a => List a -> List a-    qsort [] = []-    qsort (x :: xs) = qsort (filter (<= x) xs) ++ (x :: qsort (filter (>= x) xs)))--This is because the checker cannot tell that ``filter`` will always-produce a value smaller than the pattern ``x :: xs`` for the recursive-call to ``qsort``. We can assert that this will always be true as-follows:--::--    total-    qsort : Ord a => List a -> List a-    qsort [] = []-    qsort (x :: xs) = qsort (assert_smaller (x :: xs) (filter (<= x) xs)) ++-                      (x :: qsort (assert_smaller (x :: xs) (filter (>= x) xs))))---Preorder reasoning-==================--This syntax is defined in the module ``Syntax.PreorderReasoning`` in the-``base`` package. It provides a syntax for composing proofs of-reflexive-transitive relations, using overloadable functions called-``step`` and ``qed``. This module also defines ``step`` and ``qed``-functions allowing the syntax to be used for demonstrating equality.-Here is an example:--.. code:: idris--    import Syntax.PreorderReasoning-    multThree : (a, b, c : Nat) -> a * b * c = c * a * b-    multThree a b c =-      (a * b * c) ={ sym (multAssociative a b c) }=-      (a * (b * c)) ={ cong (multCommutative b c) }=-      (a * (c * b)) ={ multAssociative a c b }=-      (a * c * b) ={ cong {f = (* b)} (multCommutative a c) }=-      (c * a * b) QED--Note that the parentheses are required -- only a simple expression can-be on the left of ``={ }=`` or ``QED``. Also, when using preorder-reasoning syntax to prove things about equality, remember that you can-only relate the entire expression, not subexpressions. This might-occasionally require the use of ``cong``.--Finally, although equality is the most obvious application of preorder-reasoning, it can be used for any reflexive-transitive relation.-Something like ``step1 ={ just1 }= step2 ={ just2 }= end QED`` is-translated to ``(step step1 just1 (step step2 just2 (qed end)))``,-selecting the appropriate definitions of ``step`` and ``qed`` through-the normal disambiguation process. The standard library, for example,-also contains an implementation of preorder reasoning on isomorphisms.---Pattern matching on Implicit Arguments-======================================--Pattern matching is only allowed on implicit arguments when they are-referred by name, e.g.--.. code:: idris--    foo : {n : Nat} -> Nat-    foo {n = Z} = Z-    foo {n = S k} = k--or--.. code:: idris--    foo : {n : Nat} -> Nat-    foo {n = n} = n--The latter could be shortened to the following:--.. code:: idris--    foo : {n : Nat} -> Nat-    foo {n} = n--That is, ``{x}`` behaves like ``{x=x}``.---Existence of an implementation-==============================--In order to show that an implementation of some interface is defined for some-type, one could use the ``%implementation`` keyword:--.. code:: idris--    foo : Num Nat-    foo = %implementation--'match' application-===================--``ty <== name`` applies the function ``name`` in such a way that it has-the type ``ty``, by matching ``ty`` against the function's type. This-can be used in proofs, for example:--::--    plus_comm : (n : Nat) -> (m : Nat) -> (n + m = m + n)-    -- Base case-    (Z + m = m + Z) <== plus_comm =-        rewrite ((m + Z = m) <== plusZeroRightNeutral) ==>-                (Z + m = m) in Refl--    -- Step case-    (S k + m = m + S k) <== plus_comm =-        rewrite ((k + m = m + k) <== plus_comm) in-        rewrite ((S (m + k) = m + S k) <== plusSuccRightSucc) in-            Refl--Reflection-==========--Including ``%reflection`` functions and ``quoteGoal x by fn in t``,-which applies ``fn`` to the expected type of the current expression, and-puts the result in ``x`` which is in scope when elaborating ``t``.--Bash Completion-================--Use of ``optparse-applicative`` allows Idris to support Bash-completion.  You can obtain the completion script for Idris using the-following command::--   idris --bash-completion-script `which idris`---To enable completion for the lifetime of your current session, run the-following command::--   source <(idris --bash-completion-script `which idris`)---To enable completion permanently you must either:--* Modify your bash init script with the above command.--* Add the completion script to the appropriate ``bash_completion.d/``-  folder on your machine.
− docs/reference/packages.rst 
@@ -1,150 +0,0 @@-.. _ref-sect-packages:--********-Packages-********--Idris includes a simple system for building packages from a-package description file. These files can be used with the Idris-compiler to manage the development process of your Idris-programmes and packages.--Package Descriptions-====================--A package description includes the following:--+ A header, consisting of the keyword package followed by the package-  name. Package names can be any valid Idris identifier. The iPKG-  format also takes a quoted version that accepts any valid filename.-+ Fields describing package contents, ``<field> = <value>``--At least one field must be the modules field, where the value is a-comma separated list of modules.  For example, a library test which-has two modules ``foo.idr`` and ``bar.idr`` as source files would be-written as follows::--    package test--    modules = foo, bar--Other examples of package files can be found in the ``libs`` directory-of the main Idris repository, and in `third-party libraries <https://github.com/idris-lang/Idris-dev/wiki/Libraries>`_.--Metadata-----------From Idris `v0.12` the `iPKG` format supports additional metadata-associated with the package.-The added fields are:--+ ``brief = "<text>"``, a string literal containing a brief description-  of the package.--+ ``version = <text>``, a version string to associate with the package.--+ ``readme = <file>``, location of the README file.--+ ``license = <text>``, a string description of the licensing-  information.--+ ``author = <text>``, the author information.--+ ``maintainer = <text>``, Maintainer information.--+ ``homepage = <url>``, the website associated with the package.--+ ``sourceloc = <url>``, the location of the DVCS where the source-  can be found.--+ ``bugtracker = <url>``, the location of the project's bug tracker.---Common Fields----------------Other common fields which may be present in an ``ipkg`` file are:--+ ``sourcedir = <dir>``, which takes the directory (relative to the-  current directory) which contains the source. Default is the current-  directory.--+ ``executable = <output>``, which takes the name of the executable-  file to generate. Executable names can be any valid Idris-  identifier. the iPKG format also takes a quoted version that accepts-  any valid filename.--+ ``main = <module>``, which takes the name of the main module, and-  must be present if the executable field is present.--+ ``opts = "<idris options>"``, which allows options to be passed to-  Idris.--+ ``pkgs = <pkg name> (',' <pkg name>)+``, a comma separated list of-  package names that the Idris package requires.--Binding to C---------------In more advanced cases, particularly to support creating bindings to-external ``C`` libraries, the following options are available:--+ ``makefile = <file>``, which specifies a ``Makefile``, to be built-  before the Idris modules, for example to support linking with a-  ``C`` library. When building, Idris sets the environment variables-  ``IDRIS_INCLUDES`` (with C include flags) and ``IDRIS_LDFLAGS``-  (with C linking flags) so they can be used from inside the-  ``Makefile``.--+ ``libs = <libs>``, which takes a comma separated list of libraries-  which must be present for the package to be usable.--+ ``objs = <objs>``, which takes a comma separated list of additional-  files to be installed (object files, headers), perhaps generated-  by the ``Makefile``.--Testing-----------For testing Idris packages there is a rudimentary testing harness, run in the ``IO`` context.-The ``iPKG`` file is used to specify the functions used for testing.-The following option is available:--+ ``tests = <test functions>``, which takes the qualified names of all test functions to be run.--.. IMPORTANT::-  The modules containing the test functions must also be added to the list of modules.--Comments------------Package files support comments using the standard Idris singleline ``--`` and multiline ``{- -}`` format.--Using Package files-===================--Given an Idris package file ``test.ipkg`` it can be used with the Idris compiler as follows:--+ ``idris --build test.ipkg`` will build all modules in the package--+ ``idris --install test.ipkg`` will install the package, making it-  accessible by other Idris libraries and programs.--+ ``idris --clean test.ipkg`` will delete all intermediate code and-  executable files generated when building.--+ ``idris --mkdoc test.ipkg`` will build HTML documentation for your package in the folder ``test_doc`` in your project's root directory.--+ ``idris --installdoc test.ipkg`` will install the packages documentation into Idris' central documentation folder located at ``idris --docdir``.--+ ``idris --checkpkg test.ipkg`` will type check all modules in the package only. This differs from build that type checks **and** generates code.--+ ``idris --testpkg test.ipkg`` will compile and run any embedded tests you have specified in the ``tests`` parameter.--When building or install packages the commandline flag ``--warnipkg`` will audit the project and warn of any potentiable problems.--Once the test package has been installed, the command line option-``--package test`` makes it accessible (abbreviated to ``-p test``).-For example::--    idris -p test Main.idr
− docs/reference/partial-evaluation.rst 
@@ -1,305 +0,0 @@-****************************************-Static Arguments and Partial Evaluation-****************************************--As of version 0.9.15, Idris has support for *partial evaluation* of-statically known arguments. This involves creating specialised versions-of functions with arguments annotated as ``%static``.--(This is an implementation of the partial evaluator described in `this-ICFP 2010-paper <http://eb.host.cs.st-andrews.ac.uk/writings/icfp10.pdf>`__.-Please refer to this for more precise definitions of what follows.)--Partial evaluation is switched off by default since Idris 1.0. It can-be enabled with the ``--partial-eval`` flag.--Introductory Example-----------------------Consider the power function over natural numbers, defined as follows-(we'll call it ``my_pow`` since ``pow`` already exists in the Prelude):--::--    my_pow : Nat -> Nat -> Nat-    my_pow x Z = 1-    my_pow x (S k) = mult x (my_pow x k)--This is implemented by recursion on the second argument, and we can-evaluate the definition further if the second argument is known, even if-the first isn't. For example, we can build a function at the REPL to-cube a number as follows:--::--    *pow> \x => my_pow x 3-    \x => mult x (mult x (mult x 1)) : Nat -> Nat-    *pow> it 3-    27 : Nat--Note that in the resulting function the recursion has been eliminated,-since ``my_pow`` is implemented by recursion on the known argument. We-have no such luck if the first argument is known and the second isn't:--::--    *pow> \x => my_pow 2 x-    \x => my_pow 2 x : Nat -> Nat--Now, consider the following definition which calculates x^2 + 1:--::--    powFn : Nat -> Nat-    powFn x = plus (my_pow x (S (S Z))) (S Z)--Since the second argument to ``my_pow`` here is statically known, it-seems a shame to have to make the recursive calls every time. However,-Idris will not in general inline recursive definitions, in particular-since they may diverge or duplicate work without some deeper analysis.--We can, however, give Idris some hints that here we really would like to-create a specialised version of ``my_pow``.--Automatic specialisation of ``pow``-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~--The trick is to mark the statically known arguments with the-``%static`` flag:--::--    my_pow : Nat -> %static Nat -> Nat-    my_pow k Z = 1-    my_pow k (S j) = mult k (my_pow k j)--When an argument is annotated in this way, Idris will try to create a-specialised version whenever it accounts a call with a concrete value-(i.e. a constant, constructor form, or globally defined function) in a-``%static`` position. If ``my_pow`` is defined this way, and ``powFn``-defined as above, we can see the effect by typing ``:printdef powFn`` at-the REPL:--::--    *pow> :printdef powFn-    powFn : Nat -> Nat-    powFn x = plus (PE_my_pow_3f3e5ad8 x) 1--What is this mysterious ``PE_my_pow_3f3e5ad8``? It's a specialised power-function where the statically known argument has been specialised away.-The name is generated from a hash of the specialised arguments, and we-can see its definition with ``:printdef`` too:--::--    *petest> :printdef PE_my_pow_3f3e5ad8-    PE_my_pow_3f3e5ad8 : Nat -> Nat-    PE_my_pow_3f3e5ad8 (0arg) = mult (0arg) (mult (0arg) (PE_fromInteger_7ba9767f 1))--The ``(0arg)`` is an internal argument name (programmers can't give-variable names beginning with a digit after all). Notice also that there-is a specialised version of ``fromInteger`` for ``Nat``\ s, since type-class dictionaries are themselves a particularly common case of-statically known arguments!--Specialising Type Classes----------------------------Type class dictionaries are very often statically known, so Idris-automatically marks any type class constraint as ``%static`` and builds-specialised versions of top level functions where the class is-instantiated. For example, given:--::--    calc : Int -> Int-    calc x = (x * x) + x--If we print this definition, we'll see a specialised version of ``+`` is-used:--::--    *petest> :printdef calc-    calc : Int -> Int-    calc x = PE_+_954510b4 (PE_*_954510b4 x x) x--More interestingly, consider ``vadd`` which adds corresponding elements-in a vector of anything numeric:--::--    vadd : Num a => Vect n a -> Vect n a -> Vect n a-    vadd [] [] = []-    vadd (x :: xs) (y :: ys) = x + y :: vadd xs ys--If we use this on something concrete as follows...--::--    test : List Int -> List Int-    test xs = let xs' = fromList xs in-                  toList $ vadd xs' xs'--...then in fact, we get a specialised version of ``vadd`` in the-definition of ``test``, and indeed the specialised version of-``toList``:--::--    test : List Int -> List Int-    test xs = let xs' = fromList xs-              in PE_toList_888ae67 (PE_vadd_33f98d3d xs' xs')--Here's the specialised version of ``vadd``:--::--    PE_vadd_33f98d3d : Vect n Int -> Vect n Int -> Vect n Int-    PE_vadd_33f98d3d [] [] = []-    PE_vadd_33f98d3d (x :: xs) (y :: ys) = ((PE_+_954510b4 x y) ::-                                           (PE_vadd_33f98d3d xs ys))--Note that the recursive structure has been preserved, and the recursive-call to ``vadd`` has been replaced with a recursive call to the-specialised version. We've also got the same specialised version of-``+`` that we had above in ``calc``.--Specialising Higher Order Functions--------------------------------------Another case where partial evaluation can be useful is in automatically-making specialised versions of higher order functions. Unlike type class-dictionaries, this is not done automatically, but we might consider-writing ``map`` as follows:--::--    my_map : %static (a -> b) -> List a -> List b-    my_map f [] = []-    my_map f (x :: xs) = f x :: my_map f xs--Then using ``my_map`` will yield specialised versions, for example to-double every value in a list of ``Int``\ s we could write:--::--    doubleAll : List Int -> List Int-    doubleAll xs = my_map (*2) xs--This would yield a specialised version of ``my_map``, used in-``doubleAll`` as follows:--::--    doubleAll : List Int -> List Int-    doubleAll xs = PE_my_map_1f8225c4 xs--    PE_my_map_1f8225c4 : List Int -> List Int-    PE_my_map_1f8225c4 [] = []-    PE_my_map_1f8225c4 (x :: xs) = ((PE_*_954510b4 x 2) :: (PE_my_map_1f8225c4 xs))--Specialising Interpreters----------------------------A particularly useful situation where partial evaluation becomes-effective is in defining an interpreter for a well-typed expression-language, defined as follows (see the `Idris tutorial, section-4 <http://eb.host.cs.st-andrews.ac.uk/writings/idris-tutorial.pdf>`__-for more details on how this works):--::--    data Expr : Vect n Ty -> Ty -> Type where-         Var : HasType i gamma t -> Expr gamma t-         Val : (x : Int) -> Expr gamma TyInt-         Lam : Expr (a :: gamma) t -> Expr gamma (TyFun a t)-         App : Lazy (Expr gamma (TyFun a t)) -> Expr gamma a -> Expr gamma t-         Op  : (interpTy a -> interpTy b -> interpTy c) -> Expr gamma a -> Expr gamma-               Expr gamma c-         If  : Expr gamma TyBool -> Expr gamma a -> Expr gamma a -> Expr gamma a--    dsl expr-        lambda = Lam-        variable = Var-        index_first = stop-        index_next = pop--We can write a couple of test functions in this language as follows,-using the ``dsl`` notation to overload lambdas; first a function which-multiplies two inputs:--::--    eMult : Expr gamma (TyFun TyInt (TyFun TyInt TyInt))-    eMult = expr (\x, y => Op (*) x y)--Then, a function which calculates the factorial of its input:--::--    eFac : Expr gamma (TyFun TyInt TyInt)-    eFac = expr (\x => If (Op (==) x (Val 0))-                (Val 1)-                (App (App eMult (App eFac (Op (-) x (Val 1)))) x))--The interpreter's type is written as follows, marking the expression to-be evaluated as ``%static``:--::--    interp : (env : Env gamma) -> %static (e : Expr gamma t) -> interpTy t--This means that if we write an Idris program to calculate a factorial by-calling ``interp`` on ``eFac``, the resulting definition will be-specialised, partially evaluating away the interpreter:--::--    runFac : Int -> Int-    runFac x = interp [] eFac x--We can see that the call to ``interp`` has been partially evaluated away-as follows:--::--    *interp> :printdef runFac-    runFac : Int -> Int-    runFac x = PE_interp_ed1429e [] x--If we look at ``PE_interp_ed1429e`` we'll see that it follows exactly-the structur of ``eFac``, with the interpreter evaluated away:--::--    *interp> :printdef PE_interp_ed1429e-    PE_interp_ed1429e : Env gamma -> Int -> Int-    PE_interp_ed1429e (3arg) = \x =>-                                 boolElim (x == 0)-                                          (Delay 1)-                                          (Delay (PE_interp_b5c2d0ff (x :: (3arg))-                                                                     (PE_interp_ed1429e (x :: (3arg)) (x - 1)) x))---For the sake of readability, I have simplified this slightly: what you-will really see also includes specialised versions of ``==``, ``-`` and-``fromInteger``. Note that ``PE_interp_ed1429e``, which represents-``eFac`` has become a recursive function following the structure of-``eFac``. There is also a call to ``PE_interp_b5c2d0ff`` which is a-specialised interpeter for ``eMult``.--These definitions arise because the partial evaluator will only-specialise a definition by a specific concrete argument once, then it is-cached for future use. So any future applications of ``interp`` on-``eFac`` will also be translated to ``PE_interp_ed1429e``.--The specialised version of ``eMult``, without any simplification for-readability, is:--::--    PE_interp_b5c2d0ff : Env gamma -> Int -> Int -> Int-    PE_interp_b5c2d0ff (3arg) = \x => \x1 => PE_*_954510b4 x x1
− docs/reference/repl.rst 
@@ -1,546 +0,0 @@-.. _sect-repl:--**************-The Idris REPL-**************--Idris comes with a ``REPL``.--Evaluation-==========--Being a fully dependently typed language, Idris has two phases where it-evaluates things, compile-time and run-time. At compile-time it will only-evaluate things which it knows to be total (i.e. terminating and covering all-possible inputs) in order to keep type checking decidable. The compile-time-evaluator is part of the Idris kernel, and is implemented in Haskell using a-HOAS (higher order abstract syntax) style representation of values. Since-everything is known to have a normal form here, the evaluation strategy doesn't-actually matter because either way it will get the same answer, and in practice-it will do whatever the Haskell run-time system chooses to do.--The REPL, for convenience, uses the compile-time notion of evaluation. As well-as being easier to implement (because we have the evaluator available) this can-be very useful to show how terms evaluate in the type checker. So you can see-the difference between:--.. code-block:: idris--    Idris> \n, m => (S n) + m-    \n => \m => S (plus n m) : Nat -> Nat -> Nat--    Idris> \n, m => n + (S m)-    \n => \m => plus n (S m) : Nat -> Nat -> Nat--Customisation-=============--Idris supports initialisation scripts.--Initialisation scripts-~~~~~~~~~~~~~~~~~~~~~~--When the Idris REPL starts up, it will attempt to open the file-repl/init in Idris's application data directory. The application data-directory is the result of the Haskell function call-``getAppUserDataDirectory "idris"``, which on most Unix-like systems-will return $HOME/.idris and on various versions of Windows will return-paths such as ``C:/Documents And Settings/user/Application Data/appName``.--The file repl/init is a newline-separate list of REPL commands. Not all-commands are supported in initialisation scripts — only the subset that-will not interfere with the normal operation of the REPL. In particular,-setting colours, display options such as showing implicits, and log-levels are supported.--Example initialisation script-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~-::--    :colour prompt white italic bold-    :colour implicit magenta italic----The ``REPL`` Commands-=====================--The current set of supported commands are:--+----------------+------------------------------+----------------------------------------------------------------------------------------------------------+-|Command         | Arguments                    | Purpose                                                                                                  |-+================+==============================+==========================================================================================================+-|<expr>          |                              | Evaluate an expression                                                                                   |-+----------------+------------------------------+----------------------------------------------------------------------------------------------------------+-|:t :type        | <expr>                       | Check the type of an expression                                                                          |-+----------------+------------------------------+----------------------------------------------------------------------------------------------------------+-|:core           | <expr>                       | View the core language representation of a term                                                          |-+----------------+------------------------------+----------------------------------------------------------------------------------------------------------+-|:miss :missing  | <name>                       | Show missing clauses                                                                                     |-+----------------+------------------------------+----------------------------------------------------------------------------------------------------------+-|:doc            | <name>                       | Show internal documentation                                                                              |-+----------------+------------------------------+----------------------------------------------------------------------------------------------------------+-|:mkdoc          | <namespace>                  | Generate IdrisDoc for namespace(s) and dependencies                                                      |-+----------------+------------------------------+----------------------------------------------------------------------------------------------------------+-|:apropos        | [<package list>] <name>      | Search names, types, and documentation                                                                   |-+----------------+------------------------------+----------------------------------------------------------------------------------------------------------+-|:s :search      | [<package list>] <expr>      | Search for values by type                                                                                |-+----------------+------------------------------+----------------------------------------------------------------------------------------------------------+-|:wc :whocalls   | <name>                       | List the callers of some name                                                                            |-+----------------+------------------------------+----------------------------------------------------------------------------------------------------------+-|:cw :callswho   | <name>                       | List the callees of some name                                                                            |-+----------------+------------------------------+----------------------------------------------------------------------------------------------------------+-|:browse         | <namespace>                  | List the contents of some namespace                                                                      |-+----------------+------------------------------+----------------------------------------------------------------------------------------------------------+-|:total          | <name>                       | Check the totality of a name                                                                             |-+----------------+------------------------------+----------------------------------------------------------------------------------------------------------+-|:r :reload      |                              | Reload current file                                                                                      |-+----------------+------------------------------+----------------------------------------------------------------------------------------------------------+-|:l :load        | <filename>                   | Load a new file                                                                                          |-+----------------+------------------------------+----------------------------------------------------------------------------------------------------------+-|:cd             | <filename>                   | Change working directory                                                                                 |-+----------------+------------------------------+----------------------------------------------------------------------------------------------------------+-|:module         | <module>                     | Import an extra module                                                                                   |-+----------------+------------------------------+----------------------------------------------------------------------------------------------------------+-|:e :edit        |                              | Edit current file using $EDITOR or $VISUAL                                                               |-+----------------+------------------------------+----------------------------------------------------------------------------------------------------------+-|:m :metavars    |                              | Show remaining proof obligations (holes)                                                                 |-+----------------+------------------------------+----------------------------------------------------------------------------------------------------------+-|:p :prove       | <hole>                       | Prove a hole                                                                                             |-+----------------+------------------------------+----------------------------------------------------------------------------------------------------------+-|:a :addproof    | <name>                       | Add proof to source file                                                                                 |-+----------------+------------------------------+----------------------------------------------------------------------------------------------------------+-|:rmproof        | <name>                       | Remove proof from proof stack                                                                            |-+----------------+------------------------------+----------------------------------------------------------------------------------------------------------+-|:showproof      | <name>                       | Show proof                                                                                               |-+----------------+------------------------------+----------------------------------------------------------------------------------------------------------+-|:proofs         |                              | Show available proofs                                                                                    |-+----------------+------------------------------+----------------------------------------------------------------------------------------------------------+-|:x              | <expr>                       | Execute IO actions resulting from an expression using the interpreter                                    |-+----------------+------------------------------+----------------------------------------------------------------------------------------------------------+-|:c :compile     | <filename>                   | Compile to an executable [codegen] <filename>                                                            |-+----------------+------------------------------+----------------------------------------------------------------------------------------------------------+-|:exec :execute  | [<expr>]                     | Compile to an executable and run                                                                         |-+----------------+------------------------------+----------------------------------------------------------------------------------------------------------+-|:dynamic        | <filename>                   | Dynamically load a C library (similar to %dynamic)                                                       |-+----------------+------------------------------+----------------------------------------------------------------------------------------------------------+-|:dynamic        |                              | List dynamically loaded C libraries                                                                      |-+----------------+------------------------------+----------------------------------------------------------------------------------------------------------+-|:? :h :help     |                              | Display this help text                                                                                   |-+----------------+------------------------------+----------------------------------------------------------------------------------------------------------+-|:set            | <option>                     | Set an option (errorcontext, showimplicits, originalerrors, autosolve, nobanner, warnreach, evaltypes,   |-|                |                              | desugarnats)                                                                                             |-+----------------+------------------------------+----------------------------------------------------------------------------------------------------------+-|:unset          | <option>                     | Unset an option                                                                                          |-+----------------+------------------------------+----------------------------------------------------------------------------------------------------------+-|:color :colour  | <option>                     | Turn REPL colours on or off; set a specific colour                                                       |-+----------------+------------------------------+----------------------------------------------------------------------------------------------------------+-|:consolewidth   | auto|infinite|<number>       | Set the width of the console                                                                             |-+----------------+------------------------------+----------------------------------------------------------------------------------------------------------+-|:printerdepth   | <number-or-blank>            | Set the maximum pretty-printing depth, or infinite if nothing specified                                  |-+----------------+------------------------------+----------------------------------------------------------------------------------------------------------+-|:q :quit        |                              | Exit the Idris system                                                                                    |-+----------------+------------------------------+----------------------------------------------------------------------------------------------------------+-|:w :warranty    |                              | Displays warranty information                                                                            |-+----------------+------------------------------+----------------------------------------------------------------------------------------------------------+-|:let            | (<top-level-declaration>)... | Evaluate a declaration, such as a function definition, instance implementation, or fixity declaration    |-+----------------+------------------------------+----------------------------------------------------------------------------------------------------------+-|:unlet :undefine|(<name>)...                   | Remove the listed repl definitions, or all repl definitions if no names given                            |-+----------------+------------------------------+----------------------------------------------------------------------------------------------------------+-|:printdef       | <name>                       | Show the definition of a function                                                                        |-+----------------+------------------------------+----------------------------------------------------------------------------------------------------------+-|:pp :pprint     | <option> <number> <name>     | Pretty prints an Idris function in either LaTeX or HTML and for a specified width.                       |-+----------------+------------------------------+----------------------------------------------------------------------------------------------------------+---Using the REPL-==============---Getting help-~~~~~~~~~~~~--The command ``:help`` (or ``:h`` or ``:?``) prints a short summary of-the available commands.--Quitting Idris-~~~~~~~~~~~~~~--If you would like to leave Idris, simply use ``:q`` or ``:quit``.--Evaluating expressions-~~~~~~~~~~~~~~~~~~~~~~--To evaluate an expression, simply type it. If Idris is unable to infer-the type, it can be helpful to use the operator ``the`` to manually-provide one, as Idris's syntax does not allow for direct type-annotations. Examples of ``the`` include:--::--    Idris> the Nat 4-    4 : Nat-    Idris> the Int 4-    4 : Int-    Idris> the (List Nat) [1,2]-    [1,2] : List Nat-    Idris> the (Vect _ Nat) [1,2]-    [1,2] : Vect 2 Nat--This may not work in cases where the expression still involves ambiguous-names. The name can be disambiguated by using the ``with`` keyword:--::--    Idris> sum [1,2,3]-    When elaborating an application of function Prelude.Foldable.sum:-            Can't disambiguate name: Prelude.List.::,-                                     Prelude.Stream.::,-                                     Prelude.Vect.::-    Idris> with List sum [1,2,3]-    6 : Integer--Adding let bindings-~~~~~~~~~~~~~~~~~~~--To add a let binding to the REPL, use ``:let``. It's likely you'll also-need to provide a type annotation. ``:let`` also works for other-declarations as well, such as ``data``.--::--    Idris> :let x : String; x = "hello"-    Idris> x-    "hello" : String-    Idris> :let y = 10-    Idris> y-    10 : Integer-    Idris> :let data Foo : Type where Bar : Foo-    Idris> Bar-    Bar : Foo--Getting type information-~~~~~~~~~~~~~~~~~~~~~~~~--To ask Idris for the type of some expression, use the ``:t`` command.-Additionally, if used with an overloaded name, Idris will provide all-overloadings and their types. To ask for the type of an infix operator,-surround it in parentheses.--::--    Idris> :t "foo"-    "foo" : String-    Idris> :t plus-    Prelude.Nat.plus : Nat -> Nat -> Nat-    Idris> :t (++)-    Builtins.++ : String -> String -> String-    Prelude.List.++ : (List a) -> (List a) -> List a-    Prelude.Vect.++ : (Vect m a) -> (Vect n a) -> Vect (m + n) a-    Idris> :t plus 4-    plus (Builtins.fromInteger 4) : Nat -> Nat--You can also ask for basic information about interfaces with ``:doc``:--::--    Idris> :doc Monad-    Interface Monad--    Parameters:-        m--    Methods:-        (>>=) : Monad m => m a -> (a -> m b) -> m b--            infixl 5--    Instances:-        Monad id-        Monad PrimIO-        Monad IO-        Monad Maybe--    ...--Other documentation is also available from ``:doc``:--::--    Idris> :doc (+)-    Prelude.Interfaces.(+) : Num ty => ty -> ty -> ty--    infixl 8--    The function is Total--::--    Idris> :doc Vect-    Data type Prelude.Vect.Vect : Nat -> Type -> Type--    Arguments:-            Nat-            Type--    Constructors:--    Prelude.Vect.Nil : (a : Type) -> Vect 0 a---    Prelude.Vect.:: : (a : Type) -> (n : Nat) -> a -> (Vect n a) -> Vect (S n) a--    infixr 7--    Arguments:-            a-            Vect n a--::--    Idris> :doc Monad-    Interface Monad--    Parameters:-        m--    Methods:-        (>>=) : Monad m => m a -> (a -> m b) -> m b-            Also called bind.-            infixl 5--            The function is Total-        join : Monad m => m (m a) -> m a-            Also called flatten or mu--            The function is Total-    Implementations:-        Monad (IO' ffi)-        Monad Stream-        Monad Provider-        Monad Elab-        Monad PrimIO-        Monad Maybe-        Monad (Either e)-        Monad List--Finding things-~~~~~~~~~~~~~~--The command ``:apropos`` searches names, types, and documentation for-some string, and prints the results. For example:--::--    Idris> :apropos eq-    eqPtr : Ptr -> Ptr -> IO Bool---    eqSucc : (left : Nat) -> (right : Nat) -> (left = right) -> S left = S right-    S preserves equality--    lemma_both_neq : ((x = x') -> _|_) -> ((y = y') -> _|_) -> ((x, y) = (x', y')) -> _|_---    lemma_fst_neq_snd_eq : ((x = x') -> _|_) -> (y = y') -> ((x, y) = (x', y)) -> _|_---    lemma_snd_neq : (x = x) -> ((y = y') -> _|_) -> ((x, y) = (x, y')) -> _|_---    lemma_x_eq_xs_neq : (x = y) -> ((xs = ys) -> _|_) -> (x :: xs = y :: ys) -> _|_---    lemma_x_neq_xs_eq : ((x = y) -> _|_) -> (xs = ys) -> (x :: xs = y :: ys) -> _|_---    lemma_x_neq_xs_neq : ((x = y) -> _|_) -> ((xs = ys) -> _|_) -> (x :: xs = y :: ys) -> _|_---    prim__eqB16 : Bits16 -> Bits16 -> Int--    prim__eqB16x8 : Bits16x8 -> Bits16x8 -> Bits16x8--    prim__eqB32 : Bits32 -> Bits32 -> Int--    prim__eqB32x4 : Bits32x4 -> Bits32x4 -> Bits32x4--    prim__eqB64 : Bits64 -> Bits64 -> Int--    prim__eqB64x2 : Bits64x2 -> Bits64x2 -> Bits64x2--    prim__eqB8 : Bits8 -> Bits8 -> Int--    prim__eqB8x16 : Bits8x16 -> Bits8x16 -> Bits8x16--    prim__eqBigInt : Integer -> Integer -> Int--    prim__eqChar : Char -> Char -> Int--    prim__eqFloat : Double -> Double -> Int--    prim__eqInt : Int -> Int -> Int--    prim__eqString : String -> String -> Int--    prim__syntactic_eq : (a : Type) -> (b : Type) -> (x : a) -> (y : b) -> Maybe (x = y)--    sequence : Traversable t => Applicative f => (t (f a)) -> f (t a)---    sequence_ : Foldable t => Applicative f => (t (f a)) -> f ()---    Eq : Type -> Type-    The Eq interface defines inequality and equality.--    GTE : Nat -> Nat -> Type-    Greater than or equal to--    LTE : Nat -> Nat -> Type-    Proofs that n is less than or equal to m--    gte : Nat -> Nat -> Bool-    Boolean test than one Nat is greater than or equal to another--    lte : Nat -> Nat -> Bool-    Boolean test than one Nat is less than or equal to another--    ord : Char -> Int-    Convert the number to its ASCII equivalent.--    replace : (x = y) -> (P x) -> P y-    Perform substitution in a term according to some equality.--    sym : (l = r) -> r = l-    Symmetry of propositional equality--    trans : (a = b) -> (b = c) -> a = c-    Transitivity of propositional equality--``:search`` does a type-based search, in the spirit of Hoogle. See `Type-directed search (:search) <https://github.com/idris-lang/Idris-dev/wiki/Type-directed-search-%28%3Asearch%29>`_ for more details. Here is an example:--::--    Idris> :search a -> b -> a-    = Prelude.Basics.const : a -> b -> a-    Constant function. Ignores its second argument.--    = assert_smaller : a -> b -> b-    Assert to the totality checker than y is always structurally-    smaller than x (which is typically a pattern argument)--    > malloc : Int -> a -> a---    > Prelude.pow : Num a => a -> Nat -> a---    > Prelude.Interfaces.(*) : Num a => a -> a -> a---    > Prelude.Interfaces.(+) : Num a => a -> a -> a-    ... (More results)--``:search`` can also look for dependent types:--::--    Idris> :search plus (S n) n = plus n (S n)-    < Prelude.Nat.plusSuccRightSucc : (left : Nat) ->-                                      (right : Nat) ->-                                      S (left + right) = left + S right--Loading and reloading Idris code-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~--The command ``:l File.idr`` will load File.idr into the-currently-running REPL, and ``:r`` will reload the last file that was-loaded.--Totality-~~~~~~~~--All Idris definitions are checked for totality. The command-``:total <NAME>`` will display the result of that check. If a definition-is not total, this may be due to an incomplete pattern match. If that is-the case, ``:missing`` or ``:miss`` will display the missing cases.--Editing files-~~~~~~~~~~~~~--The command ``:e`` launches your default editor on the current module.-After control returns to Idris, the file is reloaded.--Invoking the compiler-~~~~~~~~~~~~~~~~~~~~~--The current module can be compiled to an executable using the command-``:c <FILENAME>`` or ``:compile <FILENAME>``. This command allows to-specify codegen, so for example JavaScript can be generated using-``:c javascript <FILENAME>``. The ``:exec`` command will compile the-program to a temporary file and run the resulting executable.--IO actions-~~~~~~~~~~--Unlike GHCI, the Idris REPL is not inside of an implicit IO monad. This-means that a special command must be used to execute IO actions.-``:x tm`` will execute the IO action ``tm`` in an Idris interpreter.--Dynamically loading C libraries-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~--Sometimes, an Idris program will depend on external libraries written in-C. In order to use these libraries from the Idris interpreter, they must-first be dynamically loaded. This is achieved through the-``%dynamic <LIB>`` directive in Idris source files or through the-``:dynamic <LIB>`` command at the REPL. The current set of dynamically-loaded libraries can be viewed by executing ``:dynamic`` with no-arguments. These libraries are available through the Idris FFI in `type-providers <#type-providers>`__ and ``:exec``.--Colours-=======--Idris terms are available in amazing colour! By default, the Idris REPL-uses colour to distinguish between data constructors, types or type-constructors, operators, bound variables, and implicit arguments. This-feature is available on all POSIX-like systems, and there are plans to-allow it to work on Windows as well.--If you do not like the default colours, they can be turned off using the-command--::--    :colour off--and, when boredom strikes, they can be re-enabled using the command--::--    :colour on--To modify a colour, use the command--::--    :colour <CATEGORY> <OPTIONS>--where ``<CATEGORY`` is one of ``keyword``, ``boundvar``, ``implicit``,-``function``, ``type``, ``data``, or ``prompt``, and is a-space-separated list drawn from the colours and the font options. The-available colours are ``default``, ``black``, ``yellow``, ``cyan``,-``red``, ``blue``, ``white``, ``green``, and ``magenta``. If more than-one colour is specified, the last one takes precedence. The available-options are ``dull`` and ``vivid``, ``bold`` and ``nobold``, ``italic``-and ``noitalic``, ``underline`` and ``nounderline``, forming pairs of-opposites. The colour ``default`` refers to your terminal's default-colour.--The colours used at startup can be changed using REPL initialisation-scripts.--Colour can be disabled at startup by the ``--nocolour`` command-line-option.
− docs/reference/semantic-highlighting.rst 
@@ -1,50 +0,0 @@-****************************************-Semantic Highlighting & Pretty Printing-****************************************--Since ``v0.9.18`` Idris comes with support for semantic highlighting.-When using the ``REPL`` or IDE support, Idris will highlight your code accordingly to its meaning within the Idris structure. A precursor to semantic highlighting support is the pretty printing of definitions to console, LaTeX, or HTML.--The default styling scheme used was inspired by Conor McBride's own set of stylings, informally known as *Conor Colours*.---Legend-======--The concepts and their default stylings are as follows:--+----------------+---------------+----------------+----------------+-| Idris Term     | HTML          | LaTeX          | IDE/REPL       |-+================+===============+================+================+-| Bound Variable | Purple        | Magenta        |                |-+----------------+---------------+----------------+----------------+-| Keyword        | Bold          | Underlined     |                |-+----------------+---------------+----------------+----------------+-| Function       | Green         | Green          |                |-+----------------+---------------+----------------+----------------+-| Type           | Blue          | Blue           |                |-+----------------+---------------+----------------+----------------+-| Data           | Red           | Red            |                |-+----------------+---------------+----------------+----------------+-| Implicit       | Italic Purple | Italic Magenta |                |-+----------------+---------------+----------------+----------------+--Pretty Printing-===============--Idris also supports the pretty printing of code to HTML and LaTeX using the commands:--+ ``:pp <latex|html> <width> <function name>``-+ ``:pprint <latex|html> <width> <function name>``---Customisation-=============--If you are not happy with the colours used, the VIM and Emacs editor support allows for customisation of the colours. When pretty printing Idris code as LaTeX and HTML, commands and a CSS style are provided. The colours used by the REPL can be customised through the initialisation script.---Further Information-===================--Please also see the `Idris Extras <https://github.com/idris-hackers/idris-extras>`_ project for links to editor support, and pre-made style files for LaTeX and HTML.
− docs/reference/syntax-guide.rst 
@@ -1,489 +0,0 @@-**************-Syntax Guide-**************--Examples are mostly adapted from the Idris tutorial.--Source File Structure------------------------Source files consist of:--1. An optional :ref:`syntax-module-headers`.-2. Zero or more :ref:`syntax-imports`.-3. Zero or more declarations, e.g. :ref:`syntax-variables`,-   :ref:`syntax-data-types`, etc.--For example:--.. code:: idris--    module MyModule   -- module header--    import Data.Vect  -- an import--    %default total    -- a directive--    foo : Nat         -- a declaration-    foo = 5--.. _syntax-module-headers:--Module Header-~~~~~~~~~~~~~--A file can start with a module header, introduced by the ``module`` keyword:--.. code-block:: idris--  module Semantics--Module names can be hierarchical, with parts separated by ``.``:--.. code-block:: idris--  module Semantics.Transform--Each file can define only a single module, which includes everything defined in-that file.--Like with declarations, a :ref:`docstring <syntax-comments>` can be used to-provide documentation for a module:--.. code-block:: idris--  ||| Implementation of predicate transformer semantics.-  module Semantics.Transform--.. _syntax-imports:--Imports-~~~~~~~--An ``import`` makes the names in another module available for use by the current-module:--.. code-block:: idris--    import Data.Vect--All the declarations in an imported module are available for use in the file.-In a case where a name is ambiguous --- e.g. because it is imported from-multiple modules, or appears in multiple visible namespaces --- the ambiguity can be resolved using :ref:`syntax-qualified-names`.  (Often, the compiler can-resolve the ambiguity for you, using the types involved.)--Imported modules can be given aliases to make qualified names more compact:--.. code-block:: idris--    import Data.Vect as V--Note that names made visible by import are not, by default, re-exported to-users of the module being written.  This can be done using ``import public``:--.. code-block:: idris--    import public Data.Vect--.. _syntax-variables:--Variables------------A variable is always defined by defining its type on one line, and its-value on the next line, using the syntax--::--    <id> : <type>-    <id> = <value>--Examples--.. code:: idris--    x : Int-    x = 100-    hello : String-    hello = "hello"--Types--------In Idris, types are first class values. So a type declaration is the-same as just declaration of a variable whose type is ``Type``. In Idris,-variables that denote a type need not be capitalised. Example:--.. code:: idris--    MyIntType : Type-    MyIntType = Int--a more interesting example:--.. code:: idris--    MyListType : Type-    MyListType = List Int--While capitalising types is not required, the rules for generating implicit-arguments mean it is often a good idea.--.. _syntax-data-types:--Data types-~~~~~~~~~~--Idris provides two kinds of syntax for defining data types. The first,-Haskell style syntax, defines a regular algebraic data type. For example--.. code:: idris--    data Either a b = Left a | Right b--or--.. code:: idris--    data List a = Nil | (::) a (List a)--The second, more general kind of data type, is defined using Agda or-GADT style syntax. This syntax defines a data type that is parameterised-by some values (in the ``Vect`` example, a value of type ``Nat`` and a-value of type ``Type``).--.. code:: idris--    data Vect : Nat -> Type -> Type where-      Nil  : Vect Z a-      (::) : (x : a) -> (xs : Vect n a) -> Vect (S n) a--The signature of type constructors may use dependent types--.. code:: idris--    data DPair : (a : Type) -> (a -> Type) -> Type where-      MkDPair : {P : a -> Type} -> (x : a) -> (pf : P x) -> DPair a P--Records-~~~~~~~--There is a special syntax for data types with one constructor and-multiple fields.--.. code:: idris--    record A a where-      constructor MkA-      foo, bar : a-      baz : Nat--This defines a constructor as well as getter and setter function for-each field.--.. code:: idris--    MkA : a -> a -> Nat -> A a-    foo : A a -> a-    set_foo : a -> A a -> A a--The types of record fields may depend on the value of other fields--.. code:: idris--    record Collection a where-      constructor MkCollection-      size : Nat-      items : Vect size a--Setter functions are only provided for fields that do not use dependant-types. In the example above neither ``set_size`` nor ``set_items`` are-defined.---Co-data-~~~~~~~--Inifinite data structures can be introduced with the ``codata``-keyword.--.. code:: idris--  codata Stream : Type -> Type where-    (::) a -> Stream a -> Stream a--This is syntactic sugar for the following, which is usually preferred:--.. code:: idris--  data Stream : Type -> Type where-    (::) a -> Inf (Stream a) -> Stream a--Every occurence of the defined type in a constructor argument will be-wrapped in the ``Inf`` type constructor. This has the effect of delaying the-evaluation of the second argument when the data constructor is applied.-An ``Inf`` argument is constructed using ``Delay`` (which Idris will insert-implicitly) and evaluated using ``Force`` (again inserted implicitly).--Furthermore, recursive calls under a ``Delay`` must be guarded by a constructor-to pass the totality checker.--Operators------------Arithmetic-~~~~~~~~~~--::--    x + y-    x - y-    x * y-    x / y-    (x * y) + (a / b)--Equality and Relational-~~~~~~~~~~~~~~~~~~~~~~~--::--    x == y-    x /= y-    x >= y-    x > y-    x <= y-    x < y--Conditional-~~~~~~~~~~~--::--    x && y-    x || y-    not x--Conditionals---------------If Then Else-~~~~~~~~~~~~--::--    if <test> then <true> else <false>--Case Expressions-~~~~~~~~~~~~~~~~--::--    case <test> of-        <case 1>  => <expr>-        <case 2>  => <expr>-        ...-        otherwise => <expr>--Functions------------Named-~~~~~--Named functions are defined in the same way as variables, with the type-followed by the definition.--::--    <id> : <argument type> -> <return type>-    <id> arg = <expr>--Example--.. code:: idris--    plusOne : Int -> Int-    plusOne x = x + 1--Functions can also have multiple inputs, for example--.. code:: idris--    makeHello : String -> String -> String-    makeHello first last = "hello, my name is " ++ first ++ " " ++ last--Functions can also have named arguments. This is required if you want to-annotate parameters in a docstring. The following shows the same-``makeHello`` function as above, but with named parameters which are-also annotated in the docstring--.. code:: idris--    ||| Makes a string introducing a person-    ||| @first The person's first name-    ||| @last The person's last name-    makeHello : (first : String) -> (last : String) -> String-    makeHello first last = "hello, my name is " ++ first ++ " " ++ last--Like Haskell, Idris functions can be defined by pattern matching. For-example--.. code:: idris--    sum : List Int -> Int-    sum []        = 0-    sum (x :: xs) = x + (sum xs)--Similarly case analysis looks like--.. code:: idris--    answerString : Bool -> String-    answerString False = "Wrong answer"-    answerString True = "Correct answer"--Dependent Functions-~~~~~~~~~~~~~~~~~~~--Dependent functions are functions where the type of the return value-depends on the input value. In order to define a dependent function,-named parameters must be used, since the parameter will appear in the-return type. For example, consider--.. code:: idris--    zeros : (n : Nat) -> Vect n Int-    zeros Z     = []-    zeros (S k) = 0 :: (zeros k)--In this example, the return type is ``Vect n Int`` which is an-expression which depends on the input parameter ``n``.--Anonymous-~~~~~~~~~--Arguments in anonymous functions are separated by comma.--::--    (\x => <expr>)-    (\x, y => <expr>)--Modifiers-~~~~~~~~~--Visibility-^^^^^^^^^^--::--    public export-    export-    private--Totality-^^^^^^^^--::--    total-    partial-    covering--Sets explicitly to which extent pattern matching is terminating and/or-exhaustive. A ``partial`` pattern matching makes no assumption. A ``covering``-pattern matching ensures that pattern matching is exhaustive on its clauses.-Furthermore, a ``total`` pattern matching enforces both exhaustivity and-termination of the evaluation of its clauses.--Implicit Coercion-^^^^^^^^^^^^^^^^^--::--    implicit--Options-^^^^^^^--::--    %export-    %hint-    %no_implicit-    %error_handler-    %error_reverse-    %reflection-    %specialise [<name list>]--Misc-------.. _syntax-qualified-names:--Qualified Names-~~~~~~~~~~~~~~~--If multiple declarations with the same name are visible, using the name can-result in an ambiguous situation.  The compiler will attempt to resolve the-ambiguity using the types involved.  If it's unable --- for example, because-the declarations with the same name also have the same type signatures --- the-situation can be cleared up using a *qualified name*.--A qualified name has the symbol's namespace prefixed, separated by a ``.``:--.. code-block:: idris--  Data.Vect.length--This would specifically reference a ``length`` declaration from ``Data.Vect``.--Qualified names can be written using two different shorthands:--1. Names in modules that are :ref:`imported <syntax-imports>` using an alias-   can be qualified by the alias.--2. The name can be qualified by the *shortest unique suffix* of the-   namespace in question.  For example, the ``length`` case above can likely-   be shortened to ``Vect.length``.--.. _syntax-comments:--Comments-~~~~~~~~--::--    -- Single Line-    {- Multiline -}-    ||| Docstring (goes before definition)--Multi line String literals-~~~~~~~~~~~~~~~~~~~~~~~~~~--::--    foo = """-    this is a-    string literal"""--.. _syntax-directives:--Directives-------------::--    %lib <path>-    %link <path>-    %flag <path>-    %include <path>-    %hide <function>-    %freeze <name>-    %access <accessibility>-    %default <totality>-    %logging <level 0--11>-    %dynamic <list of libs>-    %name <list of names>-    %error_handlers <list of names>-    %language <extension>
− docs/reference/syntax-reference.rst 
@@ -1,422 +0,0 @@-*****************-Syntax Reference-*****************--Here we present a rough description of Idris' surface syntax as an eBNF grammar.-This presentend grammar may differ from syntax that Idris' parser can handle due to the parser and grammar description not being in sync.--=========-Notation-=========--Grammar shortcut notation::--  ~CHARSEQ = complement of char sequence (i.e. any character except CHARSEQ)-  RULE? = optional rule (i.e. RULE or nothing)-  RULE* = repeated rule (i.e. RULE zero or more times)-  RULE+ = repeated rule with at least one match (i.e. RULE one or more times)-  RULE! = invalid rule (i.e. rule that is not valid in context, report meaningful error in case)-  RULE{n} = rule repeated n times---=============-Main Grammar-=============--.. productionlist::-   ModuleHeader : `DocComment_t`? "module" `Identifier_t` ";"? ;-   Import       : "import" `Identifier_t` ";"? ;-   Prog         : `Decl`* `EOF`;-   Decl         : `DeclP`-                : | `Using`-                : | `Params`-                : | `Mutual`-                : | `Namespace`-                : | `Interface`-                : | `Implementation`-                : | `DSL`-                : | `Directive`-                : | `Provider`-                : | `Transform`-                : | `Import`!-                : | `RunElabDecl` ;-   DeclP : `Fixity`-         : | `FunDecl`-         : | `Data`-         : | `Record`-         : | `SyntaxDecl` ;------------------------Syntax Declarations-----------------------.. productionlist::-   SyntaxDecl : `SyntaxRule` ;-   SyntaxRuleOpts : "term" | "pattern" ;-   SyntaxRule : `SyntaxRuleOpts`? "syntax" `SyntaxSym`+ "=" `TypeExpr` `Terminator`;-   SyntaxSym :   '[' `Name_t` ']'-             : |  '{' `Name_t` '}'-             : |  `Name_t`-             : |  `StringLiteral_t`;-   SyntaxSym :    '[' `Name_t` ']'-             : |  '{' `Name_t` '}'-             : |  `Name_t`-             : |  `StringLiteral_t`;-------------Functions-------------.. productionlist::-   FunDecl : `FunDeclP`;-   FunDeclP : `DocComment_t`? `FnOpts`* `Accessibility`? `FnOpts`* `FnName` `TypeSig` `Terminator`-            : | `Postulate`-            : | `Pattern`-            : | `CAF` ;-   FnOpts : `FnOpt`* `Accessibility` `FnOpt`* ;-   FnOpt :   'total'-         : | 'partial'-         : | 'covering'-         : | 'implicit'-         : | '%' 'no_implicit'-         : | '%' 'assert_total'-         : | '%' 'error_handler'-         : | '%' 'reflection'-         : | '%' 'specialise' '[' `NameTimesList`? ']' ;-   NameTimes : `FnName` `Natural`?;-   NameTimesList : `NameTimes` | `NameTimes` ',' `NameTimesList` ;-   Postulate : `DocComment_t`? 'postulate' `FnOpts`* `Accesibility`? `FnOpts`* `FnName` `TypeSig` `Terminator` ;-----------------------Blocks & Namespaces-----------------------.. productionlist::-  Using : 'using' '(' `UsingDeclList` ')' `OpenBlock` `Decl`* `CloseBlock` ;-  UsingDeclList : `UsingDeclListP` | `NameList TypeSig`;-  UsingDeclListP : `UsingDecl` | `UsingDecl` ',' `UsingDeclListP` ;-  NameList : `Name` | `Name` ',' `NameList` ;-  UsingDecl : `FnName` `TypeSig` | `FnName` `FnName`+ ;-  Params : 'parameters' '(' `TypeDeclList` ')' `OpenBlock` `Decl`* `CloseBlock`;-  Mutual : 'mutual' `OpenBlock` `Decl`* `CloseBlock` ;-  Namespace : 'namespace' `identifier` `OpenBlock` `Decl`+ `CloseBlock` ;-------------------------------Interfaces & Implementation-------------------------------.. productionlist::-  ImplementationBlock : 'where' `OpenBlock` `FnDecl`* `CloseBlock` ;-  MethodOrImplementation : `FnDecl` | `Implementation`;-  InterfaceBlock : 'where' `OpenBlock` `Constructor`? `MethodOrImplementation`* `CloseBlock` ;-  InterfaceArgument : `Name` | '(' `Name` ':' `Expr` ')';-  Interface ::= `DocComment_t`? `Accessibility`? 'interface' `ConstraintList`? `Name` `InterfaceArgument`* `InterfaceBlock`?;-  Implementation : `DocComment_t`? 'implementation' `ImplementationName`? `ConstraintList`? `Name` `SimpleExpr`* `ImplementationBlock`? ;-  ImplementationName : '[' `Name` ']';-----------Bodies----------.. productionlist::-  Pattern : `Clause`;-  CAF : 'let' `FnName` '=' `Expr` `Terminator`;-  ArgExpr : `HSimpleExpr` | "In Pattern External (User-defined) Expression";-  RHS :    '='             `Expr`-      : | '?='  `RHSName`? `Expr`-      : |  `Impossible` ;-  RHSName : '{' `FnName` '}' ;-  RHSOrWithBlock : `RHS` `WhereOrTerminator`-                 : | 'with' `SimpleExpr` `OpenBlock` `FnDecl`+ `CloseBlock`;-  Clause :   `WExpr`+ `RHSOrWithBlock`-         : | `SimpleExpr` '<=='  `FnName` `RHS` `WhereOrTerminator`-         : | `ArgExpr` `Operator` `ArgExpr` `WExpr`* `RHSOrWithBlock` {- Except "=" and "?=" operators to avoid ambiguity -}-         : | `FnName` `ConstraintArg`* `ImplicitOrArgExpr`*    `WExpr`* `RHSOrWithBlock`;-  ImplicitOrArgExpr ::= `ImplicitArg` | `ArgExpr`;-  WhereOrTerminator ::= `WhereBlock` | `Terminator`;-  WExpr ::= '|' `Expr`';-  WhereBlock : 'where' `OpenBlock` `Decl`+ `CloseBlock`;-------------Directives-------------.. productionlist::-  Codegen: 'C'-         : | 'Java'-         : | 'JavaScript'-         : | 'Node'-         : | 'LLVM'-         : | 'Bytecode' ;-  StringList : `String` | `String` ',' `StringList` ;-  Directive : '%' `DirectiveP`;-  DirectiveP :   'lib'            `CodeGen` `String_t`-             : | 'link'           `CodeGen` `String_t`-             : | 'flag'           `CodeGen` `String_t`-             : | 'include'        `CodeGen` `String_t`-             : | 'hide'           `Name`-             : | 'freeze'         `Name`-             : | 'thaw'           `Name`-             : | 'access'         `Accessibility`-             : | 'default'        `Totality`-             : | 'logging'        `Natural`-             : | 'dynamic'        `StringList`-             : | 'name'           `Name` `NameList`-             : | 'error_handlers' `Name` `NameList`-             : | 'language'       'TypeProviders'-             : | 'language'       'ErrorReflection'-             : | 'deprecated' `Name` `String`-             : | 'fragile'    `Name` `Reason` ;-  LangExt :   "TypeProviders"-          : | "ErrorReflection"-          : | "UniquenessTypes"-          : | "LinearTypes"-          : | "DSLNotation"-          : | "ElabReflection"-          : | "FirstClassReflection" ;-  Totality : 'partial' | 'total' | 'covering'-  Provider : `DocComment_t`? '%' 'provide' `Provider_What`? '(' `FnName` `TypeSig` ')' 'with' `Expr`;-  ProviderWhat : 'proof' | 'term' | 'type' | 'postulate'-  Transform : '%' 'transform' `Expr` '==>' `Expr`;-  RunElabDecl : '%' 'runElab' `Expr`;---===========-Expressions-===========--.. productionlist::-  FullExpr : `Expr` `EOF_t` ;-  Expr     : `Pi` ;-  OpExpr   : "Expression Parser with Operators based on ExprP" ;-  ExprP    : "External (User-defined) Syntax" |  `InternalExpr` ;-  InternalExpr : `UnifyLog`-               : | `RecordType`-               : | `SimpleExpr`-               : | `Lambda`-               : | `QuoteGoal`-               : | `Let`-               : | `If`-               : | `RewriteTerm`-               : | `CaseExpr`-               : | `DoBlock`-               : | `App` ;----------Bodies----------.. productionlist::-  Impossible : `impossible` ;-  CaseExpr : "case" `Expr` "of" `OpenBlock` `CaseOption`+ `CloseBlock` ;-  CaseOption : `Expr` (`Impossible` | "=>" `Expr`) `Terminator` ;-  ProofExpr : "proof" `OpenBlock` `Tactic'`* `CloseBlock` ;-  TacticsExpr : "tactics" `OpenBlock` `Tactic'`* `CloseBlock` ;-  SimpleExpr : "External (User-defined) Simple Expression"-             : | "?" `Name`-             : | "%" "implementation"-             : | "Refl" ("{" `Expr` "}")?-             : | `ProofExpr`-             : | `TacticsExpr`-             : | `FnName`-             : | `Idiom`-             : | `List`-             : | `Alt`-             : | `Bracketed`-             : | `Constant`-             : | `Type`-             : | "Void"-             : | `Quasiquote`-             : | `NameQuote`-             : | `Unquote`-             : | "_" ;-  Bracketed : "(" `BracketedP` ;-  BracketedP : ")"-             : | `Expr` ")"-             : | `ExprList` ")"-             : | `DependentPair` ")"-             : | `Operator` `Expr` ")"-             : | `Expr` `Operator` ")" ;-  Alt : "(|" `Expr_List` "|)" ;-  Expr_List : `Expr'` | `Expr'` "," `Expr_List` ;-  HSimpleExpr : "." `SimpleExpr` | `SimpleExpr` ;-  UnifyLog : "%" "unifyLog" `SimpleExpr` ;-  RunTactics : "%" "runElab" `SimpleExpr` ;-  Disamb : "with" `NameList` `Expr` ;-  NoImplicits : "%" "noImplicits" `SimpleExpr` ;-  App : "mkForeign" `Arg` `Arg`*-      : | `MatchApp`-      : | `SimpleExpr` `Arg`* ;-  MatchApp : `SimpleExpr` "<==" `FnName` ;-  Arg :` ImplicitArg` | `ConstraintArg` | `SimpleExpr` ;-  ImplicitArg : "{" `Name` ("=" `Expr`)? "}" ;-  ConstraintArg : "@{" `Expr` "}" ;-  Quasiquote : "`(" `Expr` ")" ;-  Unquote : "," `Expr` ;-  RecordType : "record" "{" `FieldTypeList` "}" ;-  FieldTypeList : `FieldType` | `FieldType` "," `FieldTypeList` ;-  FieldType : `FnName` "=" `Expr` ;-  TypeSig : ":" `Expr` ;-  TypeExpr : `ConstraintList`? `Expr` ;-  Lambda : "\\" `TypeOptDeclList` `LambdaTail`-         : | "\\" `SimpleExprList`  `LambdaTail` ;-  SimpleExprList : `SimpleExpr` | `SimpleExpr` "," `SimpleExprList` ;-  LambdaTail : `Impossible` | "=>" `Expr` ;-  RewriteTerm : "rewrite" `Expr` ("==>" `Expr`)? "in" `Expr` ;-  RigCount: "1" : "0" ;-  Let : "let" `Name` `TypeSig`"? "=" `Expr`  "in" `Expr`-      : | "let" `Expr'`            "=" `Expr'` "in" `Expr` ;-  TypeSig' : ":" `Expr'` ;-  If : "if" `Expr` "then" `Expr` "else" `Expr` ;-  QuoteGoal : "quoteGoal" `Name` "by" `Expr` "in" `Expr` ;-------Pies-------.. productionlist::-  Pi : `PiOpts` `Static`? `PiP` ;-  PiP : `OpExpr` ("->" `Pi`)?-      : | "(" `TypeDeclList`           ")"            "->" `Pi`-      : | "{" `TypeDeclList`           "}"            "->" `Pi`-      : | "{" "auto"    `TypeDeclList` "}"            "->" `Pi`-      : | "{" "default" `SimpleExpr` `TypeDeclList` "}" "->" `Pi` ;-  PiOpts : "."? ;-  ConstraintList : "(" `Expr_List` ")" "=>"-                 : | `Expr`              "=>" ;-  TypeDeclList : `FunctionSignatureList`-               : | `NameList` `TypeSig` ;-  FunctionSignatureList : `Name` `TypeSig`-                        : | `Name` `TypeSig` "," `FunctionSignatureList` ;-  TypeOptDeclList : `NameOrPlaceholder` `TypeSig`?-                  : | `NameOrPlaceholder` `TypeSig`? "," `TypeOptDeclList` ;-  NameOrPlaceHolder : `Name` : "_" ;-  ListExpr : "[" "]" | "[" `Expr` "|" `DoList` "]" | "[" `ExprList` "]" ;-  ExprList : `Expr` | `Expr` "," `ExprList` ;-----------------------Do Blocks & Idioms----------------------.. productionlist::-  DoList : `Do` : `Do` "," `DoList` ;-  Do' : `Do` `KeepTerminator` ;-  DoBlock : "do" `OpenBlock` `Do'`+ `CloseBlock` ;-  Do : "let" `Name`  `TypeSig`"?      "=" `Expr`-     : | "let" `Expr'`                  "=" `Expr`-     : | "rewrite" `Expr`-     : | `Name`  "<-" `Expr`-     : | `Expr'` "<-" `Expr`-     : | `Expr` ;-  Idiom : "[|" `Expr` "|]" ;--------------Constants-------------.. productionlist::-  Constant : | "Integer"-           : | "Int"-           : | "Char"-           : | "Double"-           : | "String"-           : | "Bits8"-           : | "Bits16"-           : | "Bits32"-           : | "Bits64"-           : | `Float_t`-           : | `Natural_t`-           : | `VerbatimString_t`-           : | `String_t`-           : | `Char_t` ;-  VerbatimString_t : "\"\"\"" ~"\"\"\"" "\""* "\"\"\"" ;----------Tactics----------.. productionlist::-  Tactic : "intro" `NameList`?-         : |  "intros"-         : |  "refine"      `Name` `Imp`+-         : |  "mrefine"     `Name`-         : |  "rewrite"     `Expr`-         : |  "induction"   `Expr`-         : |  "equiv"       `Expr`-         : |  "let"         `Name` ":" `Expr'` "=" `Expr`-         : |  "let"         `Name`            "=" `Expr`-         : |  "focus"       `Name`-         : |  "exact"       `Expr`-         : |  "applyTactic" `Expr`-         : |  "reflect"     `Expr`-         : |  "fill"        `Expr`-         : |  "try"         `Tactic` "|" `Tactic`-         : |  "{" `TacticSeq` "}"-         : |  "compute"-         : |  "trivial"-         : |  "solve"-         : |  "attack"-         : |  "state"-         : |  "term"-         : |  "undo"-         : |  "qed"-         : |  "abandon"-         : |  ":" "q" ;-  TacticSeq : `Tactic` ";" `Tactic` | `Tactic` ";" `TacticSeq` ;-------Misc-------.. productionlist::-  Imp : "?" | "_" ;-  Static : "%static" ;--=====-Data-=====--.. productionlist::-  Record : `DocComment` `Accessibility`? "record" `FnName` `TypeSig` "where" `OpenBlock` `Constructor` `KeepTerminator` `CloseBlock`;-  DataI : "data" | "codata";-  Data : `DocComment`? `Accessibility`? `DataI` `FnName` `TypeSig` `ExplicitTypeDataRest`?-       : `DocComment`? `Accessibility`? `DataI` `FnName` `Name`* `DataRest`? ;-  Constructor': `Constructor` `KeepTerminator` ;-  ExplicitTypeDataRest : "where" `OpenBlock` `Constructor'`* `CloseBlock`;-  DataRest : "=" `SimpleConstructorList` `Terminator` | "where"!;-  SimpleConstructorList : `SimpleConstructor` | `SimpleConstructor` "|" `SimpleConstructorList`;-  Constructor : `DocComment`? `FnName` `TypeSig`;-  SimpleConstructor : `FnName` `SimpleExpr`* `DocComment`?;-  DSL : "dsl" `FnName` `OpenBlock` `Overload'`+ `CloseBlock`;-  OverloadIdentifier : "let" | `Identifier`;-  Overload : `OverloadIdentifier` "=" `Expr`;---=========-Operators-=========--.. productionlist::-  BacktickOperator: `Name` ;-  OperatorName: `SymbolicOperator` : `BacktickOperator` ;-  OperatorFront: "(" "=" ")" | (`Identifier_t` ".")? "(" `Operator_t` ")" ;-  FnName: `Name` | `OperatorFront`;-  Fixity: `FixityType` `Natural_t` `OperatorList` `Terminator`;-  FixityType: "infixl" | "infixr" | "infix" | "prefix";---==============-Documentation-==============--.. productionlist::-  SingleLineComment_t: "--" ~`EOL_t`* `EOL_t` ;-  MultiLineComment_t: "{" ..  "}" | "{ -" `InCommentChars_t` ;-  InCommentChars_t : "- }" | `MultiLineComment_t` `InCommentChars_t` | ~"- }"+ `InCommentChars_t`;-  DocComment_t : `DocCommentLine` (`ArgCommentLine` `DocCommentLine`*)* ;-  DocCommentLine : "|||" ~`EOL_t`* `EOL_t` ;-  ArgCommentLine : "|||" "@" ~`EOL_t`* `EOL_t` ;
− docs/reference/tactics.rst 
@@ -1,204 +0,0 @@-****************************************-DEPRECATED: Tactics and Theorem Proving-****************************************--.. warning::-   The interactive theorem-proving interface documented here has been-   deprecated in favor of :ref:`elaborator-reflection`.--Idris supports interactive theorem proving, and the analyse of context-through holes.  To list all unproven holes, use the command ``:m``.-This will display their qualified names and the expected types. To-interactively prove a holes, use the command ``:p name`` where ``name``-is the hole. Once the proof is complete, the command ``:a`` will append-it to the current module.--Once in the interactive prover, the following commands are available:--Basic commands-==============---  ``:q`` - Quits the prover (gives up on proving current lemma).--  ``:abandon`` - Same as :q--  ``:state`` - Displays the current state of the proof.--  ``:term`` - Displays the current proof term complete with its-   yet-to-be-filled holes (is only really useful for debugging).--  ``:undo`` - Undoes the last tactic.--  ``:qed`` - Once the interactive theorem prover tells you "No more-   goals," you get to type this in celebration! (Completes the proof and-   exits the prover)--Commonly Used Tactics-=====================--Compute-----------  ``compute`` - Normalises all terms in the goal (note: does not-   normalise assumptions)--::--    ----------                 Goal:                  -----------     (Vect (S (S Z + (S Z) + (S n))) Nat) -> Vect (S (S (S (S n)))) Nat-    -lemma> compute-    ----------                 Goal:                  -----------     (Vect (S (S (S (S n)))) Nat) -> Vect (S (S (S (S n)))) Nat-    -lemma>--Exact---------  ``exact`` - Provide a term of the goal type directly.--::--    ----------                 Goal:                  -----------     Nat-    -lemma> exact Z-    lemma: No more goals.-    -lemma>--Refine----------  ``refine`` - Use a name to refine the goal. If the name needs-   arguments, introduce them as new goals.--Trivial-----------  ``trivial`` - Satisfies the goal using an assumption that matches its-   type.--::--    ----------              Assumptions:              -----------     value : Nat-    ----------                 Goal:                  -----------     Nat-    -lemma> trivial-    lemma: No more goals.-    -lemma>--Intro---------  ``intro`` - If your goal is an arrow, turns the left term into an-   assumption.--::--    ----------                 Goal:                  -----------     Nat -> Nat -> Nat-    -lemma> intro-    ----------              Assumptions:              -----------     n : Nat-    ----------                 Goal:                  -----------     Nat -> Nat-    -lemma>--You can also supply your own name for the assumption:--::--    ----------                 Goal:                  -----------    Nat -> Nat -> Nat-    -lemma> intro number-    ----------              Assumptions:              -----------     number : Nat-    ----------                 Goal:                  -----------    Nat -> Nat---Intros----------  ``intros`` - Exactly like intro, but it operates on all left terms at-   once.--::--    ----------                 Goal:                  -----------     Nat -> Nat -> Nat-    -lemma> intros-    ----------              Assumptions:              -----------     n : Nat-     m : Nat-    ----------                 Goal:                  -----------     Nat-    -lemma>--let-------  ``let`` - Introduces a new assumption; you may use current-   assumptions to define the new one.--::--    ----------              Assumptions:              -----------     n : Nat-    ----------                 Goal:                  -----------     BigInt-    -lemma> let x = toIntegerNat n-    ----------              Assumptions:              -----------     n : Nat-      x = toIntegerNat n: BigInt-    ----------                 Goal:                  -----------     BigInt-    -lemma>--rewrite-----------  ``rewrite`` - Takes an expression with an equality type (x = y), and-   replaces all instances of x in the goal with y. Is often useful in-   combination with 'sym'.--::--    ----------              Assumptions:              -----------     n : Nat-     a : Type-     value : Vect Z a-    ----------                 Goal:                  -----------     Vect (mult n Z) a-    -lemma> rewrite sym (multZeroRightZero n)-    ----------              Assumptions:              -----------     n : Nat-     a : Type-     value : Vect Z a-    ----------                 Goal:                  -----------     Vect Z a-    -lemma>--sourceLocation------------------  ``sourceLocation`` - Solve the current goal with information about-   the location in the source code where the tactic was invoked. This is-   mostly for embedded DSLs and programmer tools like assertions that-   need to know where they are called. See-   ``Language.Reflection.SourceLocation`` for more information.--Less commonly-used tactics-==========================---  ``applyTactic`` - Apply a user-defined tactic. This should be a-   function of type ``List (TTName, Binder TT) -> TT -> Tactic``, where-   the first argument represents the proof context and the second-   represents the goal. If your tactic will produce a proof term-   directly, use the ``Exact`` constructor from ``Tactic``.--  ``attack`` - ?--  ``equiv`` - Replaces the goal with a new one that is convertible with-   the old one--  ``fill`` - ?--  ``focus`` - ?--  ``mrefine`` - Refining by matching against a type--  ``reflect`` - ?--  ``solve`` - Takes a guess with the correct type and fills a hole with-   it, closing a proof obligation. This happens automatically in the-   interactive prover, so ``solve`` is really only relevant in tactic-   scripts used for helping implicit argument resolution.--  ``try`` - ?
− docs/reference/type-directed-search.rst 
@@ -1,336 +0,0 @@-*********************************-Type Directed Search ``:search``-*********************************--Idris' ``:search`` command searches for terms according to their-approximate type signature (much like-`Hoogle <http://www.haskell.org/hoogle/>`__ for Haskell). For-example::--    Idris> :search e -> List e -> List e-    = Prelude.List.(::) : a -> List a -> List a-    Cons cell--    = Prelude.List.intersperse : a -> List a -> List a-    Insert some separator between the elements of a list.--    > Prelude.List.delete : Eq a => a -> List a -> List a---    < assert_smaller : a -> b -> b-    Assert to the totality checker than y is always structurally-    smaller than x (which is typically a pattern argument)--    < Prelude.Basics.const : a -> b -> a-    Constant function. Ignores its second argument.--The best results are listed first. As we can see, ``(::)`` and-``intersperse`` are exact matches; the ``=`` symbol to the left of those-results tells us the types of ``(::)`` and ``intersperse`` are-effectively the same as the type that was searched.--The next result is ``delete``, whose type is more specific than the type-that was searched; that's indicated by the ``>`` symbol. If we had a-function with the signature ``e -> List e -> List e``, we could have-given it the type ``Eq a => a -> List a -> List a``, but not necessarily-the other way around.--The final two results, ``assert_smaller`` and ``const``, have types more-general than the type that was searched, and so they have ``<`` symbols-to their left. For example, ``e -> List e -> List e`` would be a valid-type for ``assert_smaller``. The correspondence for ``const`` is more-complicated than any of the four previous results. ``:search`` shows-this result because we could change the order of the arguments! That is,-the following definition would be legal:--.. code:: idris--    f : e -> List e -> List e-    f x xs = const xs x--About :search results------------------------:search's functionality is based on the notion of type isomorphism.-Informally, two types are isomorphic if we can identify terms of one-type exactly with terms of the other. For example, we can consider the-types ``Nat -> a -> List a`` and ``a -> Nat -> List a`` to be-isomorphic, because if we have ``f : Nat -> a -> List a``, then-``flip f : a -> Nat -> List a``. Similarly, if-``g : a -> Nat -> List a``, then ``flip g : Nat -> a -> List a``.--With :search, we create a partial order on types; that is, given two-types ``A`` and ``B``, we may choose to say that ``A <= B``, ``A >= B``,-or both (in which case we say ``A == B``), or neither. For :search, we-say that ``A >= B`` if all of the terms inhabiting ``A`` correspond to-terms of ``B``, but it need not necessarily be the case that *all* the-terms of ``B`` correspond to terms of ``A``. Here's an example:--::--    a -> a            >=          Nat -> Nat--The left-hand type has just a single inhabitant, ``id``, which-corresponds to the term ``id {a = Nat}``, which has the right-hand type.-However, there are various terms inhabiting the right-hand type (such as-``S``) which cannot correspond with terms of type ``a -> a``.--We can consider the partial order for ``:search`` to be, in some sense,-inductively generated by several classes of "edits" which are described-below.--Possible edits-~~~~~~~~~~~~~~--Here is a simple approximate list of the edits that are possible in-``:search``. They are not entirely formal, and do not necessarily-reflect the ``:search`` command's actual behavior. For example, the-*argument application* rule may be used directly on arguments that are-bound after other arguments, without using several applications of the-*argument transposition* rule.---  **Argument transposition**--   ::--          A : Type          B : Type           a : A, b : B  |-  M : Type-       -----------------------------------------------------------------------------       (x : A) -> (y : B) -> [x,y/a,b]M      ==    (y : B) -> (x : A) -> [x,y/a,b]M--   Score: 1 point--Example:--::--    a -> Vect n a -> Vect (S n) a    ==    Vect n a -> a -> Vect (S n) a--Note that in order for it to make sense to change the order of-arguments, neither of the arguments' types may depend on the value bound-by the other argument!---  **Symmetry of equality**--   ::--       A = B : Type      t : Type  |-  M : Type-       -----------------------------------------        [A = B/t]M        ==       [B = A/t]M--   Score: 1 point--Example:--::--    (x,y,z : Nat) -> x + (y + z) = (x + y) + z-                       ==-    (x,y,z : Nat) -> (x + y) + z = x + (y + z)--Note that this rule means that we can flip equalities anywhere they-occur (i.e., not only in the return type).---  **Argument application**--   ::--         e : A  |-  M : Type        y1 : T1, ..., yn : Tn  |-  x : A-       ------------------------------------------------------------------       (z : A) -> [z/e]M     >=   (y1 : T1) -> ... -> (yn :Tn) -> [x/e]M--   Score: <= : 3 points, >= : 9 points--Examples:--::--    a -> a            >=    Nat -> Nat-    a -> a            >=    List e -> List e-    Vect k (Fin k)    >=    Vect 5 (Fin 5)--Note that the ``n`` shown in the scheme above may be 0; that is, there-are no Pi terms to be added on the right side. For example, that's the-case for the first example shown above. This is probably the most-important, and most widely used, rule of all.---  **Type class application**--   ::--       C : Type -> TypeClass-       ,   y1 : T1, ..., yn : Tn  |-  A : Type, instance : C A-       ,   t : Type  |- M : Type-       ------------------------------------------------------------------       C a => [a/t]M     >=      (y1 : T1) -> ... -> (yn : Tn) -> [A/t]M--   Score: <= : 4 points, >= : 12 points--Examples--::--    Ord a => a                           >=    Int-    Show (List e) => List e -> String    >=    Show a => List a -> String--This rule is used by looking at the instances for a particular type-class. While the scheme is shown only for single-parameter type classes,-it naturally generalizes to multi-parameter type classes. This rule is-particularly useful in conjunction with argument application. Again,-note that the ``n`` in the scheme above may be 0.---  **Type class introduction**--   ::--       t : Type |- M : Type      C : Type -> TypeClass-       ------------------------------------------------       (t : Type) -> M      >=      C t => M--   Score: <= : 2 points, >= : 6 points--Example:--::--    a -> a -> Bool    >=    Eq a => a -> a -> Bool--Scoring and listing search results-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~--When a type ``S`` is searched, the type is compared against the types of-all of the terms which are currently in context. When :search compares-two types ``S`` and ``T``, it essentially tries to find a chain of-inequalities--::--       R1    R2     Rn    Rn+1-    S  <= A1 <= ... <= An <= T--using the edit rules listed above. It also tries to find chains going-the other way (i.e., showing ``S >= T``) as well. Each rule has an-associated score which indicates how drastic of a change the rule-corresponds to. These scores are listed above. Note that for the rules-which are not symmetric, the score depends on the direction in which the-rule is used. Finding types which are more general that the searched-typed (``S <= T``) is preferred to finding types which are less general.--The score for the entire chain is, at minimum, the sum of the scores of-the individual rules (some non-linear interactions may be added). The-:search function tries to find the chain between ``S`` and ``T`` which-results in the lowest score, and this is the score associated to the-search result for ``T``.--Search results are listed in order of ascending score. The symbol which-is shown along with the search result reflects the type of the chain-which resulted in the minimum score.--Implementation of :search----------------------------Practically, naive and undirected application of the rules enumerated-above is not possible; not only is this obviously inefficient, but the-two application rules (particularly *argument application*) are really-impossible to use without context given by other types. Therefore, we-use a heuristic algorithm that is meant to be practical, though it might-not find ways to relate two types which may actually be related by the-rules listed above.--Suppose we wish to match two types, ``S`` and ``T``. We think of the-problem as a non-deterministic state machine. There is a ``State``-datatype which keeps track of how well we've matched ``S`` and ``T`` so-far. It contains:---  Names of argument variables (Pi-bound variables) in either type which-   have yet to be matched--  A directed acyclic graph (DAG) of arguments (Pi-bindings) for ``S``-   and ``T`` which have yet to be matched--  A list of typeclass constraints for ``S`` and ``T`` which have yet to-   be matched--  A record of the rules which have been used so far to get to this-   point--A function ``nextSteps : State -> [State]`` finds the next states which-may follow from a given state. Some states, where everything has been-matched, are considered final. The algorithm can be roughly broken down-into multiple stages; if we start from having two types, ``S`` and-``T``, which we wish to match, they are as follows:--1. For each of ``S`` and ``T``, split the types up into their return-   types and directed acyclic graphs of the arguments, where there is an-   edge from argument A to argument B if the term bound in A appears in-   the type of B. The topological sorts of the DAG represent all the-   possible ways in which the arguments may be permuted.-2. For type ``T``, recursively find (saturated) uses of the ``=`` type-   constructor and produce a list of modified versions of ``T``-   containing all possible flips of the ``=`` constructor (this-   corresponds to the *symmetry of equality rule*).-3. For each modified type for ``T``, try to unify the return type of the-   modified ``T`` with ``S``, considering arguments from both ``S`` and-   ``T`` to be holes, so that the unifier may match pieces of the two-   types. For each modified version of ``T`` where this succeeds, an-   initial ``State`` can be made. The arguments and typeclasses are-   updated accordingly with the results of unification. The remainder of-   the algorithm involves applying ``nextSteps`` to these states until-   either no states remain (corresponding to no path from ``S`` to-   ``T``) or a final state is found. ``nextSteps`` also has several-   stages:-4. Try to unify arguments of ``S`` with arguments of ``T``, much like is-   done with the return types. We work "backwards" through the-   arguments: we try matching all remaining arguments of ``S`` which-   lack outgoing edges in the DAG of remaining arguments (that is, the-   bound value doesn't appear in the type of any other remaining-   arguments) with the all of the corresponding remaining arguments of-   ``T``. This is done recursively until no arguments remain for both-   ``S`` and ``T``; otherwise, we give up at this point. This step-   corresponds to application of the *argument application rule*, as-   well as the *argument transposition* rule.-5. Now, we try to match the type classes. First, we take all possible-   subsets of type class constraints for ``S`` and ``T``. So if ``S``-   and ``T`` have a total of ``n`` type class constraints, this produces-   ``2^n`` states for every state, and this quickly becomes infeasible-   as ``n`` grows large. This is probably the biggest bottleneck of the-   algorithm at the moment. This step corresponds to applications of the-   *type class introduction* rule.-6. Try to match type class constraints for ``S`` with those for ``T``.-   We attempt to unify each type class constraint for ``S`` with each-   constraint for ``T``. This may result in applications of the *type-   class application* rule. Once we are unable to match any more type-   class constraints between ``S`` and ``T``, we proceed to the final-   step.-7. Try instantiating type classes with their instances (in either ``S``-   or ``T``). This corresponds to applications of the *type class-   application* rule. After instantiating a type class, we hopefully-   open up more opportunities to match typeclass constraints of ``S``-   with those of ``T``, so we return to the previous step.--The code for :search is located in the `Idris.TypeSearch-module <https://github.com/idris-lang/Idris-dev/blob/master/src/Idris/TypeSearch.hs>`__.--Aggregating results-~~~~~~~~~~~~~~~~~~~--The search for chains of rules/edits which relate two types can be-viewed as a shortest path problem where nodes correspond to types and-edges correspond to rules relating two types. The weights or distances-on each edge correspond to the score of each rule. We then may imagine-that we have a single start node, our search type ``S``, and several-final nodes: all of the types for terms which are currently in context.-The problem, then, is to find the shortest paths (where they exist) to-all of the final nodes. In particular, we wish to find the "closest"-types (those with the minimum score) first, as we'd like to display them-first.--This problem nicely maps to usage of Dijkstra's algorithm. We search for-all types simultaneously so we can find the closest ones with the-minimum amount of work. In practice, this results in using a priority-queue of priority queues. We first ask "which goal type should we work-on next?", and then ask "which state should we expand upon next?" By-using this strategy, the best results can be shown quickly, even if it-takes a bit of time to find worse results (or at least rule them out).--Miscellaneous Notes----------------------Whether arguments are explicit or implicit does not affect search-results.
− docs/reference/uniqueness-types.rst 
@@ -1,252 +0,0 @@-****************-Uniqueness Types-****************--Uniqueness Types are an experimental feature available from Idris-0.9.15. A value with a unique type is guaranteed to have *at most one*-reference to it at run-time, which means that it can safely be updated-in-place, reducing the need for memory allocation and garbage-collection. The motivation is that we would like to be able to write-reactive systems, programs which run in limited memory environments,-device drivers, and any other system with hard real-time requirements,-ideally while giving up as little high level conveniences as possible.--They are inspired by linear types, `Uniqueness Types-<https://en.wikipedia.org/wiki/Uniqueness_type>`__ in the `Clean-<http://wiki.clean.cs.ru.nl/Clean>`__ programming language, and-ownership types and borrowed pointers in the `Rust-<https://www.rust-lang.org/>`__ programming language.--Some things we hope to be able to do eventually with uniqueness types-include:---  Safe, pure, in-place update of arrays, lists, etc--  Provide guarantees of correct resource usage, state transitions, etc--  Provide guarantees that critical program fragments will *never*-   allocate--Using Uniqueness-================--If ``x : T`` and ``T : UniqueType``, then there is at most one reference-to ``x`` at any time during run-time execution. For example, we can-declare the type of unique lists as follows:--.. code-block:: idris--    data UList : Type -> UniqueType where-         Nil   : UList a-         (::)  : a -> UList a -> UList a--If we have a value ``xs : UList a``, then there is at most one-reference to ``xs`` at run-time. The type checker preserves this-guarantee by ensuring that there is at most one reference to any value-of a unique type in a pattern clause. For example, the following-function definition would be valid:--.. code-block:: idris--    umap : (a -> b) -> UList a -> UList b-    umap f [] = []-    umap f (x :: xs) = f x :: umap f xs--In the second clause, ``xs`` is a value of a unique type, and only-appears once on the right hand side, so this clause is valid. Not only-that, since we know there can be no other reference to the ``UList a``-argument, we can reuse its space for building the result! The compiler-is aware of this, and compiles this definition to an in-place update-of the list.--The following function definition would not be valid (even assuming an-implementation of ``++``), however, since ``xs`` appears twice:--.. code-block:: idris--    dupList : UList a -> UList a-    dupList xs = xs ++ xs--This would result in a shared pointer to ``xs``, so the typechecker-reports:--.. code-block:: idris--    unique.idr:12:5:Unique name xs is used more than once--If we explicitly copy, however, the typechecker is happy:--.. code-block:: idris--    dup : UList a -> UList a-    dup [] = []-    dup (x :: xs) = x :: x :: dup xs--Note that it's fine to use ``x`` twice, because ``a`` is a ``Type``,-rather than a ``UniqueType``.--There are some other restrictions on where a ``UniqueType`` can-appear, so that the uniqueness property is preserved. In particular,-the type of the function type, ``(x : a) -> b`` depends on the type of-``a`` or ``b`` - if either is a ``UniqueType``, then the function type-is also a ``UniqueType``. Then, in a data declaration, if the type-constructor builds a ``Type``, then no constructor can have a-``UniqueType``. For example, the following definition is invalid,-since it would embed a unique value in a possible non-unique value:--.. code-block:: idris--    data BadList : UniqueType -> Type where-         Nil   : {a : UniqueType} -> BadList a-         (::)  : {a : UniqueType} -> a -> BadList a -> BadList a--Finally, types may be polymorphic in their uniqueness, to a limited-extent. Since ``Type`` and ``UniqueType`` are different types, we are-limited in how much we can use polymorphic functions on unique types.-For example, if we have function composition defined as follows:--.. code-block:: idris--    (.) : {a, b, c : Type} -> (b -> c) -> (a -> b) -> a -> c-    (.) f g x = f (g x)--And we have some functions over unique types:--.. code-block:: idris--    foo : UList a -> UList b-    bar : UList b -> UList c--Then we cannot compose ``foo`` and ``bar`` as ``bar . foo``, because-``UList`` does not compute a ``Type``! Instead, we can define-composition as follows:--.. code-block:: idris--    (.) : {a, b, c : Type*} -> (b -> c) -> (a -> b) -> a -> c-    (.) f g x = f (g x)--The ``Type*`` type stands for either unique or non-unique types. Since-such a function may be passed a ``UniqueType``, any value of type-``Type*`` must also satisfy the requirement that it appears at most-once on the right hand side.--Borrowed Types-----------------It quickly becomes obvious when working with uniqueness types that-having only one reference at a time can be painful. For example, what-if we want to display a list before updating it?--.. code-block:: idris--    showU : Show a => UList a -> String-    showU xs = "[" ++ showU' xs ++ "]" where-      showU' : UList a -> String-      showU' [] = ""-      showU' [x] = show x-      showU' (x :: xs) = show x ++ ", " ++ showU' xs--This is a valid definition of ``showU``, but unfortunately it consumes-the list! So the following function would be invalid:--.. code-block:: idris--    printAndUpdate : UList Int -> IO ()-    printAndUpdate xs = do putStrLn (showU xs)-                           let xs' = umap (*2) xs -- xs no longer available!-                           putStrLn (showU xs')--Still, one would hope to be able to display a unique list without-problem, since it merely *inspects* the list; there are no updates. We-can achieve this, using the notion of *borrowing*. A Borrowed type is-a Unique type which can be inspected at the top level (by pattern-matching, or by *lending* to another function) but no further. This-ensures that the internals (i.e. the arguments to top level patterns)-will not be passed to any function which will update them.--``Borrowed`` converts a ``UniqueType`` to a ``BorrowedType``. It is-defined as follows (along with some additional rules in the-typechecker):--.. code-block:: idris--    data Borrowed : UniqueType -> BorrowedType where-         Read : {a : UniqueType} -> a -> Borrowed a--    implicit-    lend : {a : UniqueType} -> a -> Borrowed a-    lend x = Read x--A value can be "lent" to another function using ``lend``. Arguments to-``lend`` are not counted by the type checker as a reference to a unique-value, therefore a value can be lent as many times as desired. Using-this, we can write ``showU`` as follows:--.. code-block:: idris--    showU : Show a => Borrowed (UList a) -> String-    showU xs = "[" ++ showU' xs ++ "]" where-      showU' : Borrowed (UList a) -> String-      showU' [] = ""-      showU' [x] = show x-      showU' (Read (x :: xs)) = show x ++ ", " ++ showU' (lend xs)--Unlike a unique value, a borrowed value may be referred to as many-times as desired. However, there is a restriction on how a borrowed-value can be used. After all, much like a library book or your-neighbour's lawnmower, if a function borrows a value it is expected to-return it in exactly the condition in which it was received!--The restriction is that when a ``Borrowed`` type is matched, any-pattern variables under the ``Read`` which have a unique type may not-be referred to at all on the right hand side (unless they are-themselves ``lent`` to another function).--Uniqueness information is stored in the type, and in particular in-function types. Once we're in a unique context, any new function which-is constructed will be required to have unique type, which prevents-the following sort of bad program being implemented:--.. code-block:: idris--    foo : UList Int -> IO ()-    foo xs = do let f = \x : Int => showU xs-                putStrLn $ free xs-                putStrLn $ f 42-                pure ()--Since ``lend`` is implicit, in practice for functions to lend and borrow-values merely requires the argument to be marked as ``Borrowed``. We can-therefore write ``showU`` as follows:--.. code-block:: idris--    showU : Show a => Borrowed (UList a) -> String-    showU xs = "[" ++ showU' xs ++ "]" where-      showU' : Borrowed (UList a) -> String-      showU' [] = ""-      showU' [x] = show x-      showU' (x :: xs) = show x ++ ", " ++ showU' xs--Problems/Disadvantages/Still to do...----------------------------------------This is a work in progress, there is lots to do. The most obvious-problem is the loss of abstraction. On the one hand, we have more-precise control over memory usage with ``UniqueType`` and-``BorrowedType``, but they are not in general compatible with-functions polymorphic over ``Type``. In the short term, we can start-to write reactive and low memory systems with this, but longer term it-would be nice to support more abstraction.--We also haven't checked any of the metatheory, so this could all be-fatally flawed! The implementation is based to a large extent on-`Uniqueness Typing Simplified-<http://lambda-the-ultimate.org/node/2708>`__, by de Vries et al, so-there is reason to believe things should be fine, but we still have to-do the work.--Much as there are with linear types, there are some annoyances when-trying to prove properties of functions with unique types (for-example, what counts as a use of a value). Since we require *at most*-one use of a value, rather than *exactly* one, this seems to be less-of an issue in practice, but still needs thought.
− docs/st/composing.rst 
@@ -1,774 +0,0 @@-.. _composing:--************************-Composing State Machines-************************--In the previous section, we defined a ``DataStore`` interface and used it-to implement the following small program which allows a user to log in to-the store then display the store's contents;--.. code-block:: idris--  getData : (ConsoleIO m, DataStore m) => ST m () []-  getData = do st <- connect-               OK <- login st-                  | BadPassword => do putStrLn "Failure"-                                      disconnect st-               secret <- readSecret st-               putStrLn ("Secret is: " ++ show secret)-               logout st-               disconnect st--This function only uses one state, the store itself. Usually, though,-larger programs have lots of states, and might add, delete and update-states over the course of its execution. Here, for example, a useful-extension might be to loop forever, keeping count of the number of times-there was a login failure in a state.--Furthermore, we may have *hierarchies* of state machines, in that one-state machine could be implemented by composing several others. For-example, we can have a state machine representing the state of a-graphics system, and use this to implement a *higher level* graphics API-such as turtle graphics, which uses the graphics system plus some additional-state for the turtle.--In this section, we'll see how to work with multiple states, and how to-compose state machines to make higher level state machines. We'll begin by-seeing how to add a login failure counter to ``getData``.--Working with multiple resources-===============================--To see how to work with multiple resources, we'll modify ``getData`` so-that it loops, and counts the total number of times the user fails to-log in. For example, if we write a ``main`` program which initialises the-count to zero, a session might run as follows:--.. code::--    *LoginCount> :exec main-    Enter password: Mornington Crescent-    Secret is: "Secret Data"-    Enter password: Dollis Hill-    Failure-    Number of failures: 1-    Enter password: Mornington Crescent-    Secret is: "Secret Data"-    Enter password: Codfanglers-    Failure-    Number of failures: 2-    ...--We'll start by adding a state resource to ``getData`` to keep track of the-number of failures:--.. code-block:: idris--  getData : (ConsoleIO m, DataStore m) =>-            (failcount : Var) -> ST m () [failcount ::: State Integer]--.. topic:: Type checking ``getData``--  If you're following along in the code, you'll find that ``getData``-  no longer compiles when you update this type. That is to be expected!-  For the moment, comment out the definition of ``getData``. We'll come back-  to it shortly.--Then, we can create a ``main`` program which initialises the state to ``0``-and invokes ``getData``, as follows:--.. code-block:: idris--  main : IO ()-  main = run (do fc <- new 0-                 getData fc-                 delete fc)--We'll start our implementation of ``getData`` just by adding the new-argument for the failure count:--.. code-block:: idris--  getData : (ConsoleIO m, DataStore m) =>-            (failcount : Var) -> ST m () [failcount ::: State Integer]-  getData failcount-          = do st <- connect-               OK <- login st-                  | BadPassword => do putStrLn "Failure"-                                      disconnect st-               secret <- readSecret st-               putStrLn ("Secret is: " ++ show secret)-               logout st-               disconnect st--Unfortunately, this doesn't type check, because we have the wrong resources-for calling ``connect``. The error messages shows how the resources don't-match:--.. code-block:: idris--    When checking an application of function Control.ST.>>=:-        Error in state transition:-                Operation has preconditions: []-                States here are: [failcount ::: State Integer]-                Operation has postconditions: \result => [result ::: Store LoggedOut] ++ []-                Required result states here are: st2_fn--In other words, ``connect`` requires that there are *no* resources on-entry, but we have *one*, the failure count!-This shouldn't be a problem, though: the required resources are a *subset* of-the resources we have, after all, and the additional resources (here, the-failure count) are not relevant to ``connect``. What we need, therefore,-is a way to temporarily *hide* the additional resource.--We can achieve this with the ``call`` function:--.. code-block:: idris--  getData : (ConsoleIO m, DataStore m) =>-            (failcount : Var) -> ST m () [failcount ::: State Integer]-  getData failcount-     = do st <- call connect-          ?whatNow--Here we've left a hole for the rest of ``getData`` so that you can see the-effect of ``call``. It has removed the unnecessary parts of the resource-list for calling ``connect``, then reinstated them on return. The type of-``whatNow`` therefore shows that we've added a new resource ``st``, and still-have ``failcount`` available:--.. code-block:: idris--      failcount : Var-      m : Type -> Type-      constraint : ConsoleIO m-      constraint1 : DataStore m-      st : Var-    ---------------------------------------    whatNow : STrans m () [failcount ::: State Integer, st ::: Store LoggedOut]-                          (\result => [failcount ::: State Integer])--By the end of the function, ``whatNow`` says that we need to have finished with-``st``, but still have ``failcount`` available. We can complete ``getData``-so that it works with an additional state resource by adding ``call`` whenever-we invoke one of the operations on the data store, to reduce the list of-resources:--.. code-block:: idris--  getData : (ConsoleIO m, DataStore m) =>-            (failcount : Var) -> ST m () [failcount ::: State Integer]-  getData failcount-          = do st <- call connect-               OK <- call $ login st-                  | BadPassword => do putStrLn "Failure"-                                      call $ disconnect st-               secret <- call $ readSecret st-               putStrLn ("Secret is: " ++ show secret)-               call $ logout st-               call $ disconnect st--This is a little noisy, and in fact we can remove the need for it by-making ``call`` implicit. By default, you need to add the ``call`` explicitly,-but if you import ``Control.ST.ImplicitCall``, Idris will insert ``call``-where it is necessary.--.. code-block:: idris--  import Control.ST.ImplicitCall--It's now possible to write ``getData`` exactly as before:--.. code-block:: idris--  getData : (ConsoleIO m, DataStore m) =>-            (failcount : Var) -> ST m () [failcount ::: State Integer]-  getData failcount-          = do st <- connect-               OK <- login st-                  | BadPassword => do putStrLn "Failure"-                                      disconnect st-               secret <- readSecret st-               putStrLn ("Secret is: " ++ show secret)-               logout st-               disconnect st--There is a trade off here: if you import ``Control.ST.ImplicitCall`` then-functions which use multiple resources are much easier to read, because the-noise of ``call`` has gone. On the other hand, Idris has to work a little-harder to type check your functions, and as a result it can take slightly-longer, and the error messages can be less helpful.--It is instructive to see the type of ``call``:--.. code-block:: idris--    call : STrans m t sub new_f -> {auto res_prf : SubRes sub old} ->-           STrans m t old (\res => updateWith (new_f res) old res_prf)--The function being called has a list of resources ``sub``, and-there is an implicit proof, ``SubRes sub old`` that the resource list in-the function being called is a subset of the overall resource list. The-ordering of resources is allowed to change, although resources which-appear in ``old`` can't appear in the ``sub`` list more than once (you will-get a type error if you try this).--The function ``updateWith`` takes the *output* resources of the-called function, and updates them in the current resource list. It makes-an effort to preserve ordering as far as possible, although this isn't-always possible if the called function does some complicated resource-manipulation.--.. topic:: Newly created resources in called functions--   If the called function creates any new resources, these will typically-   appear at the *end* of the resource list, due to the way ``updateWith``-   works. You can see this in the type of ``whatNow`` in our incomplete-   definition of ``getData`` above.--Finally, we can update ``getData`` so that it loops, and keeps-``failCount`` updated as necessary:--.. code-block:: idris--  getData : (ConsoleIO m, DataStore m) =>-            (failcount : Var) -> ST m () [failcount ::: State Integer]-  getData failcount-     = do st <- call connect-          OK <- login st-             | BadPassword => do putStrLn "Failure"-                                 fc <- read failcount-                                 write failcount (fc + 1)-                                 putStrLn ("Number of failures: " ++ show (fc + 1))-                                 disconnect st-                                 getData failcount-          secret <- readSecret st-          putStrLn ("Secret is: " ++ show secret)-          logout st-          disconnect st-          getData failcount--Note that here, we're connecting and disconnecting on every iteration.-Another way to implement this would be to ``connect`` first, then call-``getData``, and implement ``getData`` as follows:--.. code-block:: idris--  getData : (ConsoleIO m, DataStore m) =>-            (st, failcount : Var) -> ST m () [st ::: Store {m} LoggedOut, failcount ::: State Integer]-  getData st failcount-     = do OK <- login st-             | BadPassword => do putStrLn "Failure"-                                 fc <- read failcount-                                 write failcount (fc + 1)-                                 putStrLn ("Number of failures: " ++ show (fc + 1))-                                 getData st failcount-          secret <- readSecret st-          putStrLn ("Secret is: " ++ show secret)-          logout st-          getData st failcount--It is important to add the explicit ``{m}`` in the type of ``Store {m}-LoggedOut`` for ``st``, because this gives Idris enough information to know-which implementation of ``DataStore`` to use to find the appropriate-implementation for ``Store``. Otherwise, if we only write ``Store LoggedOut``,-there's no way to know that the ``Store`` is linked with the computation-context ``m``.--We can then ``connect`` and ``disconnect`` only once, in ``main``:--.. code-block:: idris--  main : IO ()-  main = run (do fc <- new 0-                 st <- connect-                 getData st fc-                 disconnect st-                 delete fc)--By using ``call``, and importing ``Control.ST.ImplicitCall``, we can-write programs which use multiple resources, and reduce the list of-resources as necessary when calling functions which only use a subset of-the overall resources.--Composite resources: Hierarchies of state machines-==================================================--We've now seen how to use multiple resources in one function, which is-necessary for any realistic program which manipulates state. We can think-of this as "horizontal" composition: using multiple resources at once.-We'll often also need "vertical" composition: implementing one resource-in terms of one or more other resources.--We'll see an example of this in this section. First, we'll implement a-small API for graphics, in an interface ``Draw``, supporting:--* Opening a window, creating a double-buffered surface to draw on-* Drawing lines and rectangles onto a surface-* "Flipping" buffers, displaying the surface we've just drawn onto in-  the window-* Closing a window--Then, we'll use this API to implement a higher level API for turtle graphics,-in an ``interface``.-This will require not only the ``Draw`` interface, but also a representation-of the turtle state (location, direction and pen colour).--.. topic:: SDL bindings--    For the examples in this section, you'll need to install the-    (very basic!) SDL bindings for Idris, available from-    https://github.com/edwinb/SDL-idris. These bindings implement a small-    subset of the SDL API, and are for illustrative purposes only.-    Nevertheless, they are enough to implement small graphical programs-    and demonstrate the concepts of this section.--    Once you've installed this package, you can start Idris with the-    ``-p sdl`` flag, for the SDL bindings, and the ``-p contrib`` flag,-    for the ``Control.ST`` library.--The ``Draw`` interface-------------------------We're going to use the Idris SDL bindings for this API, so you'll need-to import ``Graphics.SDL`` once you've installed the bindings.-We'll start by defining the ``Draw`` interface, which includes a data type-representing a surface on which we'll draw lines and rectangles:--.. code-block:: idris--    interface Draw (m : Type -> Type) where-        Surface : Type--We'll need to be able to create a new ``Surface`` by opening a window:--.. code-block:: idris--    initWindow : Int -> Int -> ST m Var [add Surface]--However, this isn't quite right. It's possible that opening a window-will fail, for example if our program is running in a terminal without-a windowing system available. So, somehow, ``initWindow`` needs to cope-with the possibility of failure. We can do this by returning a-``Maybe Var``, rather than a ``Var``, and only adding the ``Surface``-on success:--.. code-block:: idris--    initWindow : Int -> Int -> ST m (Maybe Var) [addIfJust Surface]--This uses a type level function ``addIfJust``, defined in ``Control.ST``-which returns an ``Action`` that only adds a resource if the operation-succeeds (that is, returns a result of the form ``Just val``.--.. topic:: ``addIfJust`` and ``addIfRight``--  ``Control.ST`` defines functions for constructing new resources if an-  operation succeeds. As well as ``addIfJust``, which adds a resource if-  an operation returns ``Just ty``, there's also ``addIfRight``:--  .. code-block:: idris--     addIfJust : Type -> Action (Maybe Var)-     addIfRight : Type -> Action (Either a Var)--  Each of these is implemented in terms of the following primitive action-  ``Add``, which takes a function to construct a resource list from the result-  of an operation:--  .. code-block:: idris--     Add : (ty -> Resources) -> Action ty--  Using this, you can create your own actions to add resources-  based on the result of an operation, if required. For example,-  ``addIfJust`` is implemented as follows:--  .. code-block:: idris--     addIfJust : Type -> Action (Maybe Var)-     addIfJust ty = Add (maybe [] (\var => [var ::: ty]))--If we create windows, we'll also need to be able to delete them:--.. code-block:: idris--    closeWindow : (win : Var) -> ST m () [remove win Surface]--We'll also need to respond to events such as keypresses and mouse clicks.-The ``Graphics.SDL`` library provides an ``Event`` type for this, and-we can ``poll`` for events which returns the last event which occurred,-if any:--.. code-block:: idris--    poll : ST m (Maybe Event) []--The remaining methods of ``Draw`` are ``flip``, which flips the buffers-displaying everything that we've drawn since the previous ``flip``, and-two methods for drawing: ``filledRectangle`` and ``drawLine``.--.. code-block:: idris--    flip : (win : Var) -> ST m () [win ::: Surface]-    filledRectangle : (win : Var) -> (Int, Int) -> (Int, Int) -> Col -> ST m () [win ::: Surface]-    drawLine : (win : Var) -> (Int, Int) -> (Int, Int) -> Col -> ST m () [win ::: Surface]--We define colours as follows, as four components (red, green, blue, alpha):--.. code-block:: idris--  data Col = MkCol Int Int Int Int--  black : Col-  black = MkCol 0 0 0 255--  red : Col-  red = MkCol 255 0 0 255--  green : Col-  green = MkCol 0 255 0 255--  -- Also blue, yellow, magenta, cyan, white, similarly...--If you import ``Graphics.SDL``, you can implement the ``Draw`` interface-using the SDL bindings as follows:--.. code-block:: idris--  implementation Draw IO where-    Surface = State SDLSurface--    initWindow x y = do Just srf <- lift (startSDL x y)-                             | pure Nothing-                        var <- new srf-                        pure (Just var)--    closeWindow win = do lift endSDL-                         delete win--    flip win = do srf <- read win-                  lift (flipBuffers srf)-    poll = lift pollEvent--    filledRectangle win (x, y) (ex, ey) (MkCol r g b a)-         = do srf <- read win-              lift $ filledRect srf x y ex ey r g b a-    drawLine win (x, y) (ex, ey) (MkCol r g b a)-         = do srf <- read win-              lift $ drawLine srf x y ex ey r g b a--In this implementation, we've used ``startSDL`` to initialise a window, which,-returns ``Nothing`` if it fails. Since the type of ``initWindow`` states that-it adds a resource when it returns a value of the form ``Just val``, we-add the surface returned by ``startSDL`` on success, and nothing on-failure.  We can only successfully initialise if ``startDSL`` succeeds.--Now that we have an implementation of ``Draw``, we can try writing some-functions for drawing into a window and execute them via the SDL bindings.-For example, assuming we have a surface ``win`` to draw onto, we can write a-``render`` function as follows which draws a line onto a black background:--.. code-block:: idris--  render : Draw m => (win : Var) -> ST m () [win ::: Surface {m}]-  render win = do filledRectangle win (0,0) (640,480) black-                  drawLine win (100,100) (200,200) red-                  flip win--The ``flip win`` at the end is necessary because the drawing primitives-are double buffered, to prevent flicker. We draw onto one buffer, off-screen,-and display the other.  When we call ``flip``, it displays the off-screen-buffer, and creates a new off-screen buffer for drawing the next frame.--To include this in a program, we'll write a main loop which renders our-image and waits for an event to indicate the user wants to close the-application:--.. code-block:: idris--  loop : Draw m => (win : Var) -> ST m () [win ::: Surface {m}]-  loop win = do render win-                Just AppQuit <- poll-                     | _ => loop win-                pure ()--Finally, we can create a main program which initialises a window, if-possible, then runs the main loop:--.. code-block:: idris--  drawMain : (ConsoleIO m, Draw m) => ST m () []-  drawMain = do Just win <- initWindow 640 480-                   | Nothing => putStrLn "Can't open window"-                loop win-                closeWindow win--We can try this at the REPL using ``run``:--.. code::--  *Draw> :exec run drawMain--A higher level interface: ``TurtleGraphics``-----------------------------------------------Turtle graphics involves a "turtle" moving around the screen, drawing a line as-it moves with a "pen". A turtle has attributes describing its location, the-direction it's facing, and the current pen colour. There are commands for-moving the turtle forwards, turning through an angle, and changing the-pen colour, among other things. One possible interface would be the-following:--.. code-block:: idris--  interface TurtleGraphics (m : Type -> Type) where-    Turtle : Type--    start : Int -> Int -> ST m (Maybe Var) [addIfJust Turtle]-    end : (t : Var) -> ST m () [Remove t Turtle]--    fd : (t : Var) -> Int -> ST m () [t ::: Turtle]-    rt : (t : Var) -> Int -> ST m () [t ::: Turtle]--    penup : (t : Var) -> ST m () [t ::: Turtle]-    pendown : (t : Var) -> ST m () [t ::: Turtle]-    col : (t : Var) -> Col -> ST m () [t ::: Turtle]--    render : (t : Var) -> ST m () [t ::: Turtle]--Like ``Draw``, we have a command for initialising the turtle (here called-``start``) which might fail if it can't create a surface for the turtle to-draw on. There is also a ``render`` method, which is intended to render the-picture drawn so far in a window.  One possible program with this interface-is the following, with draws a colourful square:--.. code-block:: idris--  turtle : (ConsoleIO m, TurtleGraphics m) => ST m () []-  turtle = with ST do-              Just t <- start 640 480-                   | Nothing => putStr "Can't make turtle\n"-              col t yellow-              fd t 100; rt t 90-              col t green-              fd t 100; rt t 90-              col t red-              fd t 100; rt t 90-              col t blue-              fd t 100; rt t 90-              render t-              end t--.. topic:: ``with ST do``--  The purpose of ``with ST do`` in ``turtle`` is to disambiguate ``(>>=)``,-  which could be either the version from the ``Monad`` interface, or the-  version from ``ST``. Idris can work this out itself, but it takes time to-  try all of the possibilities, so the ``with`` clause can-  speed up type checking.--To implement the interface, we could try using ``Surface`` to represent-the surface for the turtle to draw on:--.. code-block:: idris--    implementation Draw m => TurtleGraphics m where-      Turtle = Surface {m}--Knowing that a ``Turtle`` is represented as a ``Surface``, we can use the-methods provided by ``Draw`` to implement the turtle.  Unfortunately, though,-this isn't quite enough. We need to store more information: in particular, the-turtle has several attributes which we need to store somewhere.-So, not only do we need to represent the turtle as a ``Surface``, we need-to store some additional state. We can achieve this using a *composite*-resource.--Introducing composite resources----------------------------------A *composite* resource is built up from a list of other resources, and-is implemented using the following type, defined by ``Control.ST``:--.. code-block:: idris--  data Composite : List Type -> Type--If we have a composite resource, we can split it into its constituent-resources, and create new variables for each of those resources, using-the *split* function. For example:--.. code-block:: idris--  splitComp : (comp : Var) -> ST m () [comp ::: Composite [State Int, State String]]-  splitComp comp = do [int, str] <- split comp-                      ?whatNow--The call ``split comp`` extracts the ``State Int`` and ``State String`` from-the composite resource ``comp``, and stores them in the variables ``int``-and ``str`` respectively. If we check the type of ``whatNow``, we'll see-how this has affected the resource list:--.. code-block:: idris--      int : Var-      str : Var-      comp : Var-      m : Type -> Type-    ---------------------------------------    whatNow : STrans m () [int ::: State Int, str ::: State String, comp ::: State ()]-                          (\result => [comp ::: Composite [State Int, State String]])--So, we have two new resources ``int`` and ``str``, and the type of-``comp`` has been updated to the unit type, so currently holds no data.-This is to be expected: we've just extracted the data into individual-resources after all.--Now that we've extracted the individual resources, we can manipulate them-directly (say, incrementing the ``Int`` and adding a newline to the-``String``) then rebuild the composite resource using ``combine``:--.. code-block:: idris--  splitComp : (comp : Var) ->-              ST m () [comp ::: Composite [State Int, State String]]-  splitComp comp = do [int, str] <- split comp-                      update int (+ 1)-                      update str (++ "\n")-                      combine comp [int, str]-                      ?whatNow--As ever, we can check the type of ``whatNow`` to see the effect of-``combine``:--.. code-block:: idris--      comp : Var-      int : Var-      str : Var-      m : Type -> Type-    ---------------------------------------    whatNow : STrans m () [comp ::: Composite [State Int, State String]]-                     (\result => [comp ::: Composite [State Int, State String]])--The effect of ``combine``, therefore, is to take existing-resources and merge them into one composite resource. Before we run-``combine``, the target resource must exist (``comp`` here) and must be-of type ``State ()``.--It is instructive to look at the types of ``split`` and ``combine`` to see-the requirements on resource lists they work with. The type of ``split``-is the following:--.. code-block:: idris--    split : (lbl : Var) -> {auto prf : InState lbl (Composite vars) res} ->-            STrans m (VarList vars) res (\vs => mkRes vs ++ updateRes res prf (State ()))--The implicit ``prf`` argument says that the ``lbl`` being split must be-a composite resource. It returns a variable list, built from the composite-resource, and the ``mkRes`` function makes a list of resources of the-appropriate types. Finally, ``updateRes`` updates the composite resource to-have the type ``State ()``.--The ``combine`` function does the inverse:--.. code-block:: idris--    combine : (comp : Var) -> (vs : List Var) ->-              {auto prf : InState comp (State ()) res} ->-              {auto var_prf : VarsIn (comp :: vs) res} ->-              STrans m () res (const (combineVarsIn res var_prf))--The implicit ``prf`` argument here ensures that the target resource ``comp``-has type ``State ()``. That is, we're not overwriting any other data.-The implicit ``var_prf`` argument is similar to ``SubRes`` in ``call``, and-ensures that every variable we're using to build the composite resource-really does exist in the current resource list.--We can use composite resources to implement our higher level ``TurtleGraphics``-API in terms of ``Draw``, and any additional resources we need.--Implementing ``Turtle``--------------------------Now that we've seen how to build a new resource from an existing collection,-we can implement ``Turtle`` using a composite resource, containing the-``Surface`` to draw on, and individual states for the pen colour and the-pen location and direction. We also have a list of lines, which describes-what we'll draw onto the ``Surface`` when we call ``render``:--.. code-block:: idris--  Turtle = Composite [Surface {m}, -- surface to draw on-                      State Col,  -- pen colour-                      State (Int, Int, Int, Bool), -- pen location/direction/d-                      State (List Line)] -- lines to draw on render--A ``Line`` is defined as a start location, and end location, and a colour:--.. code-block:: idris--  Line : Type-  Line = ((Int, Int), (Int, Int), Col)--To implement ``start``, which creates a new ``Turtle`` (or returns ``Nothing``-if this is impossible), we begin by initialising the drawing surface then-all of the components of the state. Finally, we combine all of these-into a composite resource for the turtle:--.. code-block:: idris--    start x y = do Just srf <- initWindow x y-                        | Nothing => pure Nothing-                   col <- new white-                   pos <- new (320, 200, 0, True)-                   lines <- new []-                   turtle <- new ()-                   combine turtle [srf, col, pos, lines]-                   pure (Just turtle)--To implement ``end``, which needs to dispose of the turtle,-we deconstruct the composite resource, close the window,-then remove each individual resource. Remember that we can only ``delete``-a ``State``, so we need to ``split`` the composite resource, close the-drawing surface cleanly with ``closeWindow``, then ``delete`` the states:--.. code-block:: idris--    end t = do [srf, col, pos, lines] <- split t-               closeWindow srf; delete col; delete pos; delete lines; delete t--For the other methods, we need to ``split`` the resource to get each-component, and ``combine`` into a composite resource when we're done.-As an example, here's ``penup``:--.. code-block:: idris--    penup t = do [srf, col, pos, lines] <- split t -- Split the composite resource-                 (x, y, d, _) <- read pos          -- Deconstruct the pen position-                 write pos (x, y, d, False)        -- Set the pen down flag to False-                 combine t [srf, col, pos, lines]  -- Recombine the components--The remaining operations on the turtle follow a similar pattern. See-``samples/ST/Graphics/Turtle.idr`` in the Idris distribution for the full-details. It remains to render the image created by the turtle:--.. code-block:: idris--    render t = do [srf, col, pos, lines] <- split t -- Split the composite resource-                  filledRectangle srf (0, 0) (640, 480) black -- Draw a background-                  drawAll srf !(read lines)         -- Render the lines drawn by the turtle-                  flip srf                          -- Flip the buffers to display the image-                  combine t [srf, col, pos, lines]-                  Just ev <- poll-                    | Nothing => render t           -- Keep going until a key is pressed-                  case ev of-                       KeyUp _ => pure ()           -- Key pressed, so quit-                       _ => render t-     where drawAll : (srf : Var) -> List Line -> ST m () [srf ::: Surface {m}]-           drawAll srf [] = pure ()-           drawAll srf ((start, end, col) :: xs)-              = do drawLine srf start end col       -- Draw a line in the appropriate colour-                   drawAll srf xs
− docs/st/examples.rst 
@@ -1,439 +0,0 @@-.. _netexample:--***********************************-Example: Network Socket Programming-***********************************--The POSIX sockets API supports communication between processes across a-network. A *socket* represents an endpoint of a network communication, and can be-in one of several states: --* ``Ready``, the initial state-* ``Bound``, meaning that it has been bound to an address ready for incoming-  connections-* ``Listening``, meaning that it is listening for incoming connections-* ``Open``, meaning that it is ready for sending and receiving data;-* ``Closed``, meaning that it is no longer active.--The following diagram shows how the operations provided by the API modify the-state, where ``Ready`` is the initial state:--|netstate|--If a connection is ``Open``, then we can also ``send`` messages to the-other end of the connection, and ``recv`` messages from it.--The ``contrib`` package provides a module ``Network.Socket`` which-provides primitives for creating sockets and sending and receiving-messages. It includes the following functions:--.. code-block:: idris--    bind : (sock : Socket) -> (addr : Maybe SocketAddress) -> (port : Port) -> IO Int-    connect : (sock : Socket) -> (addr : SocketAddress) -> (port : Port) -> IO ResultCode-    listen : (sock : Socket) -> IO Int-    accept : (sock : Socket) -> IO (Either SocketError (Socket, SocketAddress))-    send : (sock : Socket) -> (msg  : String) -> IO (Either SocketError ResultCode)-    recv : (sock : Socket) -> (len : ByteLength) -> IO (Either SocketError (String, ResultCode))-    close : Socket -> IO ()--These functions cover the state transitions in the diagram above, but-none of them explain how the operations affect the state! It's perfectly-possible, for example, to try to send a message on a socket which is-not yet ready, or to try to receive a message after the socket is closed.--Using ``ST``, we can provide a better API which explains exactly how-each operation affects the state of a connection. In this section, we'll-define a sockets API, then use it to implement an "echo" server which-responds to requests from a client by echoing back a single message sent-by the client.--Defining a ``Sockets`` interface-================================--Rather than using ``IO`` for low level socket programming, we'll implement-an interface using ``ST`` which describes precisely how each operation-affects the states of sockets, and describes when sockets are created-and removed. We'll begin by creating a type to describe the abstract state-of a socket:--.. code-block:: idris--  data SocketState = Ready | Bound | Listening | Open | Closed--Then, we'll begin defining an interface, starting with a ``Sock`` type -for representing sockets, parameterised by their current state:--.. code-block:: idris--  interface Sockets (m : Type -> Type) where-    Sock : SocketState -> Type--We create sockets using the ``socket`` method. The ``SocketType`` is defined-by the sockets library, and describes whether the socket is TCP, UDP,-or some other form. We'll use ``Stream`` for this throughout, which indicates a-TCP socket.-    -.. code-block:: idris--    socket : SocketType -> ST m (Either () Var) [addIfRight (Sock Ready)]--Remember that ``addIfRight`` adds a resource if the result of the operation-is of the form ``Right val``. By convention in this interface, we'll use-``Either`` for operations which might fail, whether or not they might carry-any additional information about the error, so that we can consistently-use ``addIfRight`` and some other type level functions.--To define a server, once we've created a socket, we need to ``bind`` it-to a port. We can do this with the ``bind`` method:--.. code-block:: idris--    bind : (sock : Var) -> (addr : Maybe SocketAddress) -> (port : Port) ->-           ST m (Either () ()) [sock ::: Sock Ready :-> (Sock Closed `or` Sock Bound)]--Binding a socket might fail, for example if there is already a socket-bound to the given port, so again it returns a value of type ``Either``.-The action here uses a type level function ``or``, and says that:--* If ``bind`` fails, the socket moves to the ``Sock Closed`` state-* If ``bind`` succeeds, the socket moves to the ``Sock Bound`` state, as-  shown in the diagram above--``or`` is implemented as follows:--.. code-block:: idris--    or : a -> a -> Either b c -> a-    or x y = either (const x) (const y)--So, the type of ``bind`` could equivalently be written as:--.. code-block:: idris--    bind : (sock : Var) -> (addr : Maybe SocketAddress) -> (port : Port) ->-           STrans m (Either () ()) [sock ::: Sock Ready]-                        (either [sock ::: Sock Closed] [sock ::: Sock Bound])--However, using ``or`` is much more concise than this, and attempts to-reflect the state transition diagram as directly as possible while still-capturing the possibility of failure.--Once we've bound a socket to a port, we can start listening for connections-from clients:--.. code-block:: idris--    listen : (sock : Var) ->-             ST m (Either () ()) [sock ::: Sock Bound :-> (Sock Closed `or` Sock Listening)]--A socket in the ``Listening`` state is ready to accept connections from-individual clients:--.. code-block:: idris--    accept : (sock : Var) ->-             ST m (Either () Var)-                  [sock ::: Sock Listening, addIfRight (Sock Open)]--If there is an incoming connection from a client, ``accept`` adds a *new*-resource to the end of the resource list (by convention, it's a good idea-to add resources to the end of the list, because this works more tidily-with ``updateWith``, as discussed in the previous section). So, we now-have *two* sockets: one continuing to listen for incoming connections,-and one ready for communication with the client.--We also need methods for sending and receiving data on a socket:--.. code-block:: idris--    send : (sock : Var) -> String ->-           ST m (Either () ()) [sock ::: Sock Open :-> (Sock Closed `or` Sock Open)]-    recv : (sock : Var) ->-           ST m (Either () String) [sock ::: Sock Open :-> (Sock Closed `or` Sock Open)]--Once we've finished communicating with another machine via a socket, we'll-want to ``close`` the connection and remove the socket:--.. code-block:: idris--    close : (sock : Var) ->-            {auto prf : CloseOK st} -> ST m () [sock ::: Sock st :-> Sock Closed]-    remove : (sock : Var) ->-             ST m () [Remove sock (Sock Closed)]--We have a predicate ``CloseOK``, used by ``close`` in an implicit proof-argument, which describes when it is okay to close a socket: --.. code-block:: idris--  data CloseOK : SocketState -> Type where-       CloseOpen : CloseOK Open-       CloseListening : CloseOK Listening--That is, we can close a socket which is ``Open``, talking to another machine,-which causes the communication to terminate.  We can also close a socket which-is ``Listening`` for incoming connections, which causes the server to stop-accepting requests.--In this section, we're implementing a server, but for completeness we may-also want a client to connect to a server on another machine. We can do-this with ``connect``:--.. code-block:: idris--    connect : (sock : Var) -> SocketAddress -> Port ->-              ST m (Either () ()) [sock ::: Sock Ready :-> (Sock Closed `or` Sock Open)]--For reference, here is the complete interface:--.. code-block:: idris--  interface Sockets (m : Type -> Type) where-    Sock : SocketState -> Type-    socket : SocketType -> ST m (Either () Var) [addIfRight (Sock Ready)]-    bind : (sock : Var) -> (addr : Maybe SocketAddress) -> (port : Port) ->-           ST m (Either () ()) [sock ::: Sock Ready :-> (Sock Closed `or` Sock Bound)]-    listen : (sock : Var) ->-             ST m (Either () ()) [sock ::: Sock Bound :-> (Sock Closed `or` Sock Listening)]-    accept : (sock : Var) ->-             ST m (Either () Var) [sock ::: Sock Listening, addIfRight (Sock Open)]-    connect : (sock : Var) -> SocketAddress -> Port ->-              ST m (Either () ()) [sock ::: Sock Ready :-> (Sock Closed `or` Sock Open)]-    close : (sock : Var) -> {auto prf : CloseOK st} ->-            ST m () [sock ::: Sock st :-> Sock Closed]-    remove : (sock : Var) -> ST m () [Remove sock (Sock Closed)]-    send : (sock : Var) -> String ->-           ST m (Either () ()) [sock ::: Sock Open :-> (Sock Closed `or` Sock Open)]-    recv : (sock : Var) -> -           ST m (Either () String) [sock ::: Sock Open :-> (Sock Closed `or` Sock Open)]--We'll see how to implement this shortly; mostly, the methods can be implemented-in ``IO`` by using the raw sockets API directly. First, though, we'll see-how to use the API to implement an "echo" server.--Implementing an "Echo" server with ``Sockets``-==============================================--At the top level, our echo server begins and ends with no resources available,-and uses the ``ConsoleIO`` and ``Sockets`` interfaces:--.. code-block:: idris--  startServer : (ConsoleIO m, Sockets m) => ST m () []--The first thing we need to do is create a socket for binding to a port-and listening for incoming connections, using ``socket``. This might fail,-so we'll need to deal with the case where it returns ``Right sock``, where-``sock`` is the new socket variable, or where it returns ``Left err``:--.. code-block:: idris--  startServer : (ConsoleIO m, Sockets m) => ST m () []-  startServer =-    do Right sock <- socket Stream-             | Left err => pure ()-       ?whatNow--It's a good idea to implement this kind of function interactively, step by-step, using holes to see what state the overall system is in after each-step. Here, we can see that after a successful call to ``socket``, we-have a socket available in the ``Ready`` state:--.. code-block:: idris--      sock : Var-      m : Type -> Type-      constraint : ConsoleIO m-      constraint1 : Sockets m-    ---------------------------------------    whatNow : STrans m () [sock ::: Sock Ready] (\result1 => [])--Next, we need to bind the socket to a port, and start listening for-connections. Again, each of these could fail. If they do, we'll remove-the socket. Failure always results in a socket in the ``Closed`` state,-so all we can do is ``remove`` it:--.. code-block:: idris--  startServer : (ConsoleIO m, Sockets m) => ST m () []-  startServer =-    do Right sock <- socket Stream        | Left err => pure ()-       Right ok <- bind sock Nothing 9442 | Left err => remove sock-       Right ok <- listen sock            | Left err => remove sock-       ?runServer--Finally, we have a socket which is listening for incoming connections:--.. code-block:: idris--      ok : ()-      sock : Var-      ok1 : ()-      m : Type -> Type-      constraint : ConsoleIO m-      constraint1 : Sockets m-    ---------------------------------------    runServer : STrans m () [sock ::: Sock Listening]-                       (\result1 => [])--We'll implement this in a separate function. The type of ``runServer``-tells us what the type of ``echoServer`` must be (noting that we need-to give the ``m`` argument to ``Sock`` explicitly):--.. code-block:: idris--  echoServer : (ConsoleIO m, Sockets m) => (sock : Var) ->-               ST m () [remove sock (Sock {m} Listening)]--We can complete the definition of ``startServer`` as follows:--.. code-block:: idris--  startServer : (ConsoleIO m, Sockets m) => ST m () []-  startServer =-    do Right sock <- socket Stream        | Left err => pure ()-       Right ok <- bind sock Nothing 9442 | Left err => remove sock-       Right ok <- listen sock            | Left err => remove sock-       echoServer sock--In ``echoServer``, we'll keep accepting requests and responding to them-until something fails, at which point we'll close the sockets and-return. We begin by trying to accept an incoming connection:--.. code-block:: idris--  echoServer : (ConsoleIO m, Sockets m) => (sock : Var) ->-               ST m () [remove sock (Sock {m} Listening)]-  echoServer sock =-    do Right new <- accept sock | Left err => do close sock; remove sock-       ?whatNow--If ``accept`` fails, we need to close the ``Listening`` socket and-remove it before returning, because the type of ``echoServer`` requires-this.--As always, implementing ``echoServer`` incrementally means that we can check-the state we're in as we develop. If ``accept`` succeeds, we have the-existing ``sock`` which is still listening for connections, and a ``new``-socket, which is open for communication:--.. code-block:: idris--      new : Var-      sock : Var-      m : Type -> Type-      constraint : ConsoleIO m-      constraint1 : Sockets m-    ---------------------------------------    whatNow : STrans m () [sock ::: Sock Listening, new ::: Sock Open]-                          (\result1 => [])--To complete ``echoServer``, we'll receive a message on the ``new``-socket, and echo it back. When we're done, we close the ``new`` socket,-and go back to the beginning of ``echoServer`` to handle the next-connection:--.. code-block:: idris--  echoServer : (ConsoleIO m, Sockets m) => (sock : Var) ->-               ST m () [remove sock (Sock {m} Listening)]-  echoServer sock =-    do Right new <- accept sock | Left err => do close sock; remove sock-       Right msg <- recv new | Left err => do close sock; remove sock; remove new-       Right ok <- send new ("You said " ++ msg)-             | Left err => do remove new; close sock; remove sock-       close new; remove new; echoServer sock--Implementing ``Sockets``-========================--To implement ``Sockets`` in ``IO``, we'll begin by giving a concrete type-for ``Sock``. We can use the raw sockets API (implemented in-``Network.Socket``) for this, and use a ``Socket`` stored in a ``State``, no-matter what abstract state the socket is in:--.. code-block:: idris--  implementation Sockets IO where-    Sock _ = State Socket--Most of the methods can be implemented by using the raw socket API-directly, returning ``Left`` or ``Right`` as appropriate. For example,-we can implement ``socket``, ``bind`` and ``listen`` as follows:--.. code-block:: idris--    socket ty = do Right sock <- lift $ Socket.socket AF_INET ty 0-                        | Left err => pure (Left ())-                   lbl <- new sock-                   pure (Right lbl)-    bind sock addr port = do ok <- lift $ bind !(read sock) addr port-                             if ok /= 0-                                then pure (Left ())-                                else pure (Right ())-    listen sock = do ok <- lift $ listen !(read sock)-                     if ok /= 0-                        then pure (Left ())-                        else pure (Right ())--There is a small difficulty with ``accept``, however, because when we-use ``new`` to create a new resource for the open connection, it appears-at the *start* of the resource list, not the end. We can see this by-writing an incomplete definition, using ``returning`` to see what the-resources need to be if we return ``Right lbl``:--.. code-block:: idris--    accept sock = do Right (conn, addr) <- lift $ accept !(read sock)-                           | Left err => pure (Left ())-                     lbl <- new conn-                     returning (Right lbl) ?fixResources--It's convenient for ``new`` to add the resource to the beginning of the-list because, in general, this makes automatic proof construction with-an ``auto``-implicit easier for Idris. On the other hand, when we use-``call`` to make a smaller set of resources, ``updateWith`` puts newly-created resources at the *end* of the list, because in general that reduces-the amount of re-ordering of resources. --If we look at the type of-``fixResources``, we can see what we need to do to finish ``accept``:--.. code-block:: idris--      _bindApp0 : Socket-      conn : Socket-      addr : SocketAddress-      sock : Var-      lbl : Var-    ---------------------------------------    fixResources : STrans IO () [lbl ::: State Socket, sock ::: State Socket]-                          (\value => [sock ::: State Socket, lbl ::: State Socket])--The current list of resources is ordered ``lbl``, ``sock``, and we need them-to be in the order ``sock``, ``lbl``. To help with this situation,-``Control.ST`` provides a primitive ``toEnd`` which moves a resource to the-end of the list. We can therefore complete ``accept`` as follows:--.. code-block:: idris--    accept sock = do Right (conn, addr) <- lift $ accept !(read sock)-                           | Left err => pure (Left ())-                     lbl <- new conn-                     returning (Right lbl) (toEnd lbl)--For the complete implementation of ``Sockets``, take a look at-``samples/ST/Net/Network.idr`` in the Idris distribution. You can also-find the complete echo server there, ``EchoServer.idr``. There is also-a higher level network protocol, ``RandServer.idr``, using a hierarchy of-state machines to implement a high level network communication protocol-in terms of the lower level sockets API. This also uses threading, to-handle incoming requests asynchronously. You can find some more detail-on threading and the random number server in the draft paper-`State Machines All The Way Down <https://www.idris-lang.org/drafts/sms.pdf>`_-by Edwin Brady.--.. |netstate| image:: ../image/netstate.png-                      :width: 300px-
− docs/st/index.rst 
@@ -1,27 +0,0 @@-.. _st-tutorial-index:--##########################################################-Implementing State-aware Systems in Idris: The ST Tutorial-##########################################################--A tutorial on implementing state-aware systems using -the `Control.ST` library in `Idris`.--.. note::--   The documentation for Idris has been published under the Creative-   Commons CC0 License. As such to the extent possible under law, *The-   Idris Community* has waived all copyright and related or neighbouring-   rights to Documentation for Idris.--   More information concerning the CC0 can be found online at: http://creativecommons.org/publicdomain/zero/1.0/--.. toctree::-   :maxdepth: 1--   introduction-   state-   machines-   composing-   examples-
− docs/st/introduction.rst 
@@ -1,93 +0,0 @@-********-Overview-********--Pure functional languages with dependent types such as `Idris-<http://www.idris-lang.org/>`_ support reasoning about programs directly-in the type system, promising that we can *know* a program will run-correctly (i.e. according to the specification in its type) simply-because it compiles. --Realistically, though,  software relies on state, and many components rely on state machines. For-example, they describe network transport protocols like TCP, and-implement event-driven systems and regular expression matching. Furthermore,-many fundamental resources like network sockets and files are, implicitly,-managed by state machines, in that certain operations are only valid on-resources in certain states, and those operations can change the states of the-underlying resource. For example, it only makes sense to send a message on a-connected network socket, and closing a socket changes its state from "open" to-"closed". State machines can also encode important security properties. For-example, in the software which implements an ATM, it’s important that the ATM-dispenses cash only when the machine is in a state where a card has been-inserted and the PIN verified.--In this tutorial we will introduce the ``Control.ST`` library, which is included-with the Idris distribution (currently as part of the ``contrib`` package)-and supports programming and reasoning with state and side effects.  This-tutorial assumes familiarity with pure programming in Idris, as described in-:ref:`tutorial-index`.-For further background information, the ``ST`` library is based on ideas-discussed in Chapter 13 (available as a free sample chapter) and Chapter 14-of `Type-Driven Development with Idris <https://www.manning.com/books/type-driven-development-with-idris>`_.--The ``ST`` library allows us to write programs which are composed of multiple-state transition systems. It supports composition in two ways: firstly, we can-use several independently implemented state transition systems at once;-secondly, we can implement one state transition system in terms of others.---Introductory example: a data store requiring a login-====================================================--Many software components rely on some form of state, and there may be-operations which are only valid in specific states. For example, consider-a secure data store in which a user must log in before getting access to-some secret data. This system can be in one of two states:--* ``LoggedIn``, in which the user is allowed to read the secret-* ``LoggedOut``, in which the user has no access to the secret--We can provide commands to log in, log out, and read the data, as illustrated-in the following diagram:--|login|--The ``login`` command, if it succeeds, moves the overall system state from-``LoggedOut`` to ``LoggedIn``. The ``logout`` command moves the state from-``LoggedIn`` to ``LoggedOut``. Most importantly, the ``readSecret`` command-is only valid when the system is in the ``LoggedIn`` state.--We routinely use type checkers to ensure that variables and arguments are used-consistently. However, statically checking that operations are performed only-on resources in an appropriate state is not well supported by mainstream type-systems. In the data store example, for example, it's important to check that-the user is successfully logged in before using ``readSecret``. The-``ST`` library allows us to represent this kind of *protocol* in the type-system, and ensure at *compile-time* that the secret is only read when the-user is logged in.--Outline-=======--This tutorial starts (:ref:`introst`) by describing how to manipulate-individual states, introduces a data type ``STrans`` for describing stateful-functions, and ``ST`` which describes top level state transitions.-Next (:ref:`smstypes`) it describes how to represent state machines in-types, and how to define *interfaces* for describing stateful systems.-Then (:ref:`composing`) it describes how to compose systems of multiple-state machines. It explains how to implement systems which use several-state machines at once, and how to implement a high level stateful system-in terms of lower level systems.-Finally (:ref:`netexample`) we'll see a specific example of a stateful-API in practice, implementing the POSIX network sockets API.--The ``Control.ST`` library is also described in a draft paper by-`Edwin Brady <https://edwinb.wordpress.com/>`_, "State Machines All The Way-Down", available `here <https://www.idris-lang.org/drafts/sms.pdf>`_.-This paper presents many of the examples from this tutorial, and describes-the motivation, design and implementation of the library in more depth. --.. |login| image:: ../image/login.png-                   :width: 500px--
− docs/st/machines.rst 
@@ -1,536 +0,0 @@-.. _smstypes:--***********************-State Machines in Types-***********************--In the introduction, we saw the following state transition diagram representing-the (abstract) states of a data store, and the actions we can perform on the-store:--|login|--We say that these are the *abstract* states of the store, because the concrete-state will contain a lot more information: for example, it might contain-user names, hashed passwords, the store contents, and so on. However, as far-as we are concerned for the actions ``login``, ``logout`` and ``readSecret``, -it's whether we are logged in or not which affects which are valid.--We've seen how to manipulate states using ``ST``, and some small examples-of dependent types in states. In this section, we'll see how to use-``ST`` to provide a safe API for the data store. In the API, we'll encode-the above diagram in the types, in such a way that we can only execute the-operations ``login``, ``logout`` and ``readSecret`` when the state is-valid.--So far, we've used ``State`` and the primitive operations, ``new``, ``read``,-``write`` and ``delete`` to manipulate states. For the data store API,-however, we'll begin by defining an *interface* (see :ref:`sect-interfaces` in-the Idris tutorial) which describes the operations on the store, and explains-in their types exactly when each operation is valid, and how it affects-the store's state. By using an interface, we can be sure that -this is the *only* way to access the store.--Defining an interface for the data store-========================================--We'll begin by defining a data type, in a file ``Login.idr``, which represents-the two abstract states of the store, either ``LoggedOut`` or ``LoggedIn``:--.. code-block:: idris--    data Access = LoggedOut | LoggedIn--We can define a data type for representing the current state of a store,-holding all of the necessary information (this might be user names, hashed-passwords, store contents and so on) and parameterise it by the logged in-status of the store:--.. code-block:: idris--  Store : Access -> Type--Rather than defining a concrete type now, however, we'll include this in-a data store *interface* and define a concrete type later:--.. code-block:: idris--  interface DataStore (m : Type -> Type) where-    Store : Access -> Type--We can continue to populate this interface with operations on the store.  Among-other advantages, by separating the *interface* from its *implementation* we-can provide different concrete implementations for different contexts.-Furthermore, we can write programs which work with a store without needing-to know any details of how the store is implemented.--We'll need to be able to ``connect`` to a store, and ``disconnect`` when-we're done. Add the following methods to the ``DataStore`` interface:--.. code-block:: idris--    connect : ST m Var [add (Store LoggedOut)]-    disconnect : (store : Var) -> ST m () [remove store (Store LoggedOut)]--The type of ``connect`` says that it returns a new resource which has the-initial type ``Store LoggedOut``. Conversely, ``disconnect``, given a-resource in the state ``Store LoggedOut``, removes that resource.-We can see more clearly what ``connect`` does by trying the following-(incomplete) definition:--.. code-block:: idris--  doConnect : DataStore m => ST m () []-  doConnect = do st <- connect-                 ?whatNow--Note that we're working in a *generic* context ``m``, constrained so that-there must be an implementation of ``DataStore`` for ``m`` to be able to-execute ``doConnect``.-If we check the type of ``?whatNow``, we'll see that the remaining-operations begin with a resource ``st`` in the state ``Store LoggedOut``,-and we need to finish with no resources.--.. code-block:: idris--      m : Type -> Type-      constraint : DataStore m-      st : Var-    ---------------------------------------    whatNow : STrans m () [st ::: Store LoggedOut] (\result => [])--Then, we can remove the resource using ``disconnect``:--.. code-block:: idris--  doConnect : DataStore m => ST m () []-  doConnect = do st <- connect-                 disconnect st-                 ?whatNow--Now checking the type of ``?whatNow`` shows that we have no resources-available:--.. code-block:: idris--      m : Type -> Type-      constraint : DataStore m-      st : Var-    ---------------------------------------    whatNow : STrans m () [] (\result => [])--To continue our implementation of the ``DataStore`` interface, next we'll add a-method for reading the secret data. This requires that the ``store`` is in the-state ``Store LoggedIn``:--.. code-block:: idris--    readSecret : (store : Var) -> ST m String [store ::: Store LoggedIn]--At this point we can try writing a function which connects to a store,-reads the secret, then disconnects. However, it will be unsuccessful, because-``readSecret`` requires us to be logged in:--.. code-block:: idris--  badGet : DataStore m => ST m () []-  badGet = do st <- connect-              secret <- readSecret st-              disconnect st--This results in the following error, because ``connect`` creates a new-store in the ``LoggedOut`` state, and ``readSecret`` requires the store-to be in the ``LoggedIn`` state:--.. code-block:: idris--    When checking an application of function Control.ST.>>=:-        Error in state transition:-                Operation has preconditions: [st ::: Store LoggedOut]-                States here are: [st ::: Store LoggedIn]-                Operation has postconditions: \result => []-                Required result states here are: \result => []--The error message explains how the required input states (the preconditions)-and the required output states (the postconditions) differ from the states-in the operation. In order to use ``readSecret``, we'll need a way to get-from a ``Store LoggedOut`` to a ``Store LoggedIn``. As a first attempt,-we can try the following type for ``login``:--.. code-block:: idris--    login : (store : Var) -> ST m () [store ::: Store LoggedOut :-> Store LoggedIn] -- Incorrect type!--Note that in the *interface* we say nothing about *how* ``login`` works;-merely how it affects the overall state. Even so, there is a problem with-the type of ``login``, because it makes the assumption that it will always-succeed. If it fails - for example because the implementation prompts for-a password and the user enters the password incorrectly - then it must not-result in a ``LoggedIn`` store.--Instead, therefore, ``login`` will return whether logging in was successful,-via the following type;--.. code-block:: idris--    data LoginResult = OK | BadPassword--Then, we can *calculate* the result state (see :ref:`depstate`) from the-result. Add the following method to the ``DataStore`` interface:--.. code-block:: idris--    login : (store : Var) ->-            ST m LoginResult [store ::: Store LoggedOut :->-                               (\res => Store (case res of-                                                    OK => LoggedIn-                                                    BadPassword => LoggedOut))]--If ``login`` was successful, then the state after ``login`` is-``Store LoggedIn``. Otherwise, the state is ``Store LoggedOut``.--To complete the interface, we'll add a method for logging out of the store.-We'll assume that logging out is always successful, and moves the store-from the ``Store LoggedIn`` state to the ``Store LoggedOut`` state.--.. code-block:: idris--    logout : (store : Var) -> ST m () [store ::: Store LoggedIn :-> Store LoggedOut]--This completes the interface, repeated in full for reference below:--.. code-block:: idris--  interface DataStore (m : Type -> Type) where-    Store : Access -> Type--    connect : ST m Var [add (Store LoggedOut)]-    disconnect : (store : Var) -> ST m () [remove store (Store LoggedOut)]--    readSecret : (store : Var) -> ST m String [store ::: Store LoggedIn]-    login : (store : Var) ->-            ST m LoginResult [store ::: Store LoggedOut :->-                               (\res => Store (case res of-                                                    OK => LoggedIn-                                                    BadPassword => LoggedOut))]-    logout : (store : Var) -> ST m () [store ::: Store LoggedIn :-> Store LoggedOut]--Before we try creating any implementations of this interface, let's see how-we can write a function with it, to log into a data store, read the secret-if login is successful, then log out again.--Writing a function with the data store-======================================--As an example of working with the ``DataStore`` interface, we'll write a-function ``getData``, which connects to a store in order to read some data from-it. We'll write this function interactively, step by step, using the types of-the operations to guide its development. It has the following type:--.. code-block:: idris--  getData : (ConsoleIO m, DataStore m) => ST m () []--This type means that there are no resources available on entry or exit.-That is, the overall list of actions is ``[]``, meaning that at least-externally, the function has no overall effect on the resources. In other-words, for every resource we create during ``getData``, we'll also need to-delete it before exit.--Since we want to use methods of the ``DataStore`` interface, we'll-constraint the computation context ``m`` so that there must be an-implementation of ``DataStore``. We also have a constraint ``ConsoleIO m``-so that we can display any data we read from the store, or any error-messages.--We start by connecting to the store, creating a new resource ``st``, then-trying to ``login``:--.. code-block:: idris--  getData : (ConsoleIO m, DataStore m) => ST m () []-  getData = do st <- connect-               ok <- login st-               ?whatNow--Logging in will either succeed or fail, as reflected by the value of-``ok``. If we check the type of ``?whatNow``, we'll see what state the-store currently has:--.. code-block:: idris--      m : Type -> Type-      constraint : ConsoleIO m-      constraint1 : DataStore m-      st : Var-      ok : LoginResult-    ---------------------------------------    whatNow : STrans m () [st ::: Store (case ok of   -                                              OK => LoggedIn -                                              BadPassword => LoggedOut)]-                          (\result => [])--The current state of ``st`` therefore depends on the value of ``ok``,-meaning that we can make progress by case splitting on ``ok``:--.. code-block:: idris--  getData : (ConsoleIO m, DataStore m) => ST m () []-  getData = do st <- connect-               ok <- login st-               case ok of-                    OK => ?whatNow_1-                    BadPassword => ?whatNow_2--The types of the holes in each branch, ``?whatNow_1`` and ``?whatNow_2``,-show how the state changes depending on whether logging in was successful.-If it succeeded, the store is ``LoggedIn``:--.. code-block:: idris--    ---------------------------------------    whatNow_1 : STrans m () [st ::: Store LoggedIn] (\result => [])--On the other hand, if it failed, the store is ``LoggedOut``:--.. code-block:: idris--    ---------------------------------------    whatNow_2 : STrans m () [st ::: Store LoggedOut] (\result => [])--In ``?whatNow_1``, since we've successfully logged in, we can now read-the secret and display it to the console:--.. code-block:: idris--  getData : (ConsoleIO m, DataStore m) => ST m () []-  getData = do st <- connect-               ok <- login st-               case ok of-                    OK => do secret <- readSecret st-                             putStrLn ("Secret is: " ++ show secret)-                             ?whatNow_1-                    BadPassword => ?whatNow_2--We need to finish the ``OK`` branch with no resources available. We can-do this by logging out of the store then disconnecting:--.. code-block:: idris--  getData : (ConsoleIO m, DataStore m) => ST m () []-  getData = do st <- connect-               ok <- login st-               case ok of-                    OK => do secret <- readSecret st-                             putStrLn ("Secret is: " ++ show secret)-                             logout st-                             disconnect st-                    BadPassword => ?whatNow_2--Note that we *must* ``logout`` of ``st`` before calling ``disconnect``,-because ``disconnect`` requires that the store is in the ``LoggedOut``-state.--Furthermore, we can't simply use ``delete`` to remove the resource, as-we did with the ``State`` examples in the previous section, because-``delete`` only works when the resource has type ``State ty``, for some-type ``ty``. If we try to use ``delete`` instead of ``disconnect``, we'll-see an error message like the following:--.. code-block:: idris--    When checking argument prf to function Control.ST.delete:-            Can't find a value of type-                    InState st (State st) [st ::: Store LoggedOut]--In other words, the type checker can't find a proof that the resource-``st`` has a type of the form ``State st``, because its type is-``Store LoggedOut``. Since ``Store`` is part of the ``DataStore`` interface,-we *can't* yet know the concrete representation of the ``Store``, so we-need to remove the resource via the interface, with ``disconnect``, rather-than directly with ``delete``.--We can complete ``getData`` as follows, using a pattern matching bind-alternative (see the Idris tutorial, :ref:`monadsdo`) rather than a-``case`` statement to catch the possibility of an error with ``login``:--.. code-block:: idris--  getData : (ConsoleIO m, DataStore m) => ST m () []-  getData = do st <- connect-               OK <- login st-                  | BadPassword => do putStrLn "Failure"-                                      disconnect st-               secret <- readSecret st-               putStrLn ("Secret is: " ++ show secret)-               logout st-               disconnect st--We can't yet try this out, however, because we don't have any implementations-of ``DataStore``! If we try to execute it in an ``IO`` context, for example,-we'll get an error saying that there's no implementation of ``DataStore IO``:--.. code::--    *Login> :exec run {m = IO} getData-    When checking an application of function Control.ST.run:-            Can't find implementation for DataStore IO--The final step in implementing a data store which correctly follows the-state transition diagram, therefore, is to provide an implementation-of ``DataStore``.--Implementing the interface-==========================--To execute ``getData`` in ``IO``, we'll need to provide an implementation-of ``DataStore`` which works in the ``IO`` context. We can begin as-follows:--.. code-block:: idris--  implementation DataStore IO where--Then, we can ask Idris to populate the interface with skeleton definitions-for the necessary methods (press ``Ctrl-Alt-A`` in Atom for "add definition"-or the corresponding shortcut for this in the Idris mode in your favourite-editor):--.. code-block:: idris--  implementation DataStore IO where-    Store x = ?DataStore_rhs_1-    connect = ?DataStore_rhs_2-    disconnect store = ?DataStore_rhs_3-    readSecret store = ?DataStore_rhs_4-    login store = ?DataStore_rhs_5-    logout store = ?DataStore_rhs_6--The first decision we'll need to make is how to represent the data store.-We'll keep this simple, and store the data as a single ``String``, using-a hard coded password to gain access. So, we can define ``Store`` as-follows, using a ``String`` to represent the data no matter whether we-are ``LoggedOut`` or ``LoggedIn``:--.. code-block:: idris--    Store x = State String--Now that we've given a concrete type for ``Store``, we can implement operations-for connecting, disconnecting, and accessing the data. And, since we used-``State``, we can use ``new``, ``delete``, ``read`` and ``write`` to-manipulate the store.--Looking at the types of the holes tells us how we need to manipulate the-state. For example, the ``?DataStore_rhs_2`` hole tells us what we need-to do to implement ``connect``. We need to return a new ``Var`` which -represents a resource of type ``State String``:--.. code-block:: idris--    ---------------------------------------    DataStore_rhs_2 : STrans IO Var [] (\result => [result ::: State String])--We can implement this by creating a new variable with some data for the-content of the store (we can use any ``String`` for this) and returning-that variable:--.. code-block:: idris--    connect = do store <- new "Secret Data"-                 pure store--For ``disconnect``, we only need to delete the resource:--.. code-block:: idris--    disconnect store = delete store--For ``readSecret``, we need to read the secret data and return the-``String``. Since we now know the concrete representation of the data is-a ``State String``, we can use ``read`` to access the data directly:--.. code-block:: idris--    readSecret store = read store--We'll do ``logout`` next and return to ``login``. Checking the hole-reveals the following:--.. code-block:: idris--      store : Var-    ---------------------------------------    DataStore_rhs_6 : STrans IO () [store ::: State String] (\result => [store ::: State String])--So, in this minimal implementation, we don't actually have to do anything!--.. code-block:: idris--    logout store = pure ()--For ``login``, we need to return whether logging in was successful. We'll-do this by prompting for a password, and returning ``OK`` if it matches-a hard coded password, or ``BadPassword`` otherwise:--.. code-block:: idris--    login store = do putStr "Enter password: "-                     p <- getStr-                     if p == "Mornington Crescent"-                        then pure OK-                        else pure BadPassword--For reference, here is the complete implementation which allows us to-execute a ``DataStore`` program at the REPL:--.. code-block:: idris--  implementation DataStore IO where-    Store x = State String-    connect = do store <- new "Secret Data"-                 pure store-    disconnect store = delete store-    readSecret store = read store-    login store = do putStr "Enter password: "-                     p <- getStr-                     if p == "Mornington Crescent"-                        then pure OK-                        else pure BadPassword-    logout store = pure ()--Finally, we can try this at the REPL as follows (Idris defaults to the-``IO`` context at the REPL if there is an implementation available, so no-need to give the ``m`` argument explicitly here):--.. code:: --    *Login> :exec run getData-    Enter password: Mornington Crescent-    Secret is: "Secret Data"--    *Login> :exec run getData-    Enter password: Dollis Hill-    Failure--We can only use ``read``, ``write``, ``new`` and ``delete`` on a resource-with a ``State`` type. So, *within* the implementation of ``DataStore``,-or anywhere where we know the context is ``IO``, we can access the data store-however we like: this is where the internal details of ``DataStore`` are-implemented. However, if we merely have a constraint ``DataStore m``, we can't-know how the store is implemented, so we can only access via the API given-by the ``DataStore`` interface.--It is therefore good practice to use a *generic* context ``m`` for functions-like ``getData``, and constrain by only the interfaces we need, rather than-using a concrete context ``IO``.--We've now seen how to manipulate states, and how to encapsulate state-transitions for a specific system like the data store in an interface.-However, realistic systems will need to *compose* state machines. We'll-either need to use more than one state machine at a time, or implement one-state machine in terms of one or more others. We'll see how to achieve this-in the next section.--.. |login| image:: ../image/login.png-                   :width: 500px
− docs/st/state.rst 
@@ -1,654 +0,0 @@-.. _introst:--**********************************-Introducing ST: Working with State-**********************************--The ``Control.ST`` library provides facilities for creating, reading, writing-and destroying state in Idris functions, and tracking changes of state in-a function's type. It is based around the concept of *resources*, which are,-essentially, mutable variables, and a dependent type, ``STrans`` which tracks-how those resources change when a function runs:--.. code-block:: idris--    STrans : (m : Type -> Type) ->-             (resultType : Type) ->-             (in_res : Resources) ->-             (out_res : resultType -> Resources) ->-             Type--A value of type ``STrans m resultType in_res out_res_fn`` represents a sequence-of actions which can manipulate state. The arguments are:--* ``m``, which is an underlying *computation context* in which the actions will be executed.-  Usually, this will be a generic type with a ``Monad`` implementation, but-  it isn't necessarily so. In particular, there is no need to understand monads-  to be able to use ``ST`` effectively!-* ``resultType``, which is the type of the value the sequence will produce-* ``in_res``, which is a list of *resources* available *before* executing the actions.-* ``out_res``, which is a list of resources available *after* executing the actions,-  and may differ depending on the result of the actions.--We can use ``STrans`` to describe *state transition systems* in a function's-type. We'll come to the definition of ``Resources`` shortly, but for the moment-you can consider it an abstract representation of the "state of the world".-By giving the input resources (``in_res``) and the output resources-(``out_res``) we are describing the *preconditions* under which a function-is allowed to execute, and *postconditions* which describe how a function-affects the overall state of the world.--We'll begin in this section by looking at some small examples of ``STrans``-functions, and see how to execute them. We'll also introduce ``ST``,-a type-level function which allows us to describe the state transitions of-a stateful function concisely.--.. topic:: Type checking the examples--    For the examples in this section, and throughout this tutorial,-    you'll need to ``import Control.ST`` and add the ``contrib`` package by-    passing the ``-p contrib`` flag to ``idris``.---Introductory examples: manipulating ``State``-=============================================--An ``STrans`` function explains, in its type, how it affects a collection of-``Resources``. A resource has a *label* (of type ``Var``), which we use to-refer to the resource throughout the function, and we write the state of a-resource, in the ``Resources`` list, in the form ``label ::: type``.--For example, the following function-has a resource ``x`` available on input, of type ``State Integer``, and that-resource is still a ``State Integer`` on output:--.. code-block:: idris--  increment : (x : Var) -> STrans m () [x ::: State Integer]-                                       (const [x ::: State Integer])-  increment x = do num <- read x-                   write x (num + 1)--.. sidebar:: Verbosity of the type of ``increment``--    The type of ``increment`` may seem somewhat verbose, in that the-    *input* and *output* resources are repeated, even though they are the-    same. We'll introduce a much more concise way of writing this type at the-    end of this section (:ref:`sttype`), when we describe the ``ST`` type-    itself.--This function reads the value stored at the resource ``x`` with ``read``,-increments it then writes the result back into the resource ``x`` with-``write``. We'll see the types of ``read`` and ``write`` shortly-(see :ref:`stransprimops`). We can also create and delete resources:--.. code-block:: idris--  makeAndIncrement : Integer -> STrans m Integer [] (const [])-  makeAndIncrement init = do var <- new init-                             increment var-                             x <- read var-                             delete var-                             pure x--The type of ``makeAndIncrement`` states that it has *no* resources available on-entry (``[]``) or exit (``const []``). It creates a new ``State`` resource with-``new`` (which takes an initial value for the resource), increments the value,-reads it back, then deletes it using ``delete``, returning the final value-of the resource. Again, we'll see the types of ``new`` and ``delete``-shortly.--The ``m`` argument to ``STrans`` (of type ``Type -> Type``) is the *computation context* in-which the function can be run. Here, the type level variable indicates that we-can run it in *any* context. We can run it in the identity context with-``runPure``. For example, try entering the above definitions in a file-``Intro.idr`` then running the following at the REPL:--.. code::--    *Intro> runPure (makeAndIncrement 93)-    94 : Integer--It's a good idea to take an interactive, type-driven approach to implementing-``STrans`` programs. For example, after creating the resource with ``new init``,-you can leave a *hole* for the rest of the program to see how creating the-resource has affected the type:--.. code-block:: idris--  makeAndIncrement : Integer -> STrans m Integer [] (const [])-  makeAndIncrement init = do var <- new init-                             ?whatNext--If you check the type of ``?whatNext``, you'll see that there is now-a resource available, ``var``, and that by the end of the function there-should be no resource available:--.. code-block:: idris--      init : Integer-      m : Type -> Type-      var : Var-    ---------------------------------------    whatNext : STrans m Integer [var ::: State Integer] (\value => [])--These small examples work in any computation context ``m``. However, usually,-we are working in a more restricted context. For example, we might want to-write programs which only work in a context that supports interactive-programs. For this, we'll need to see how to *lift* operations from the-underlying context.--Lifting: Using the computation context-======================================--Let's say that, instead of passing an initial integer to ``makeAndIncrement``,-we want to read it in from the console. Then, instead of working in a generic-context ``m``, we can work in the specific context ``IO``:--.. code-block:: idris--    ioMakeAndIncrement : STrans IO () [] (const [])--This gives us access to ``IO`` operations, via the ``lift`` function. We-can define ``ioMakeAndIncrement`` as follows:--.. code-block:: idris--  ioMakeAndIncrement : STrans IO () [] (const [])-  ioMakeAndIncrement-     = do lift $ putStr "Enter a number: "-          init <- lift $ getLine-          var <- new (cast init)-          lift $ putStrLn ("var = " ++ show !(read var))-          increment var-          lift $ putStrLn ("var = " ++ show !(read var))-          delete var--The ``lift`` function allows us to use functions from the underlying-computation context (``IO`` here) directly. Again, we'll see the exact type-of ``lift`` shortly.--.. topic:: !-notation--    In ``ioMakeAndIncrement`` we've used ``!(read var)`` to read from the-    resource. You can read about this ``!``-notation in the main Idris tutorial-    (see :ref:`monadsdo`). In short, it allows us to use an ``STrans``-    function inline, rather than having to bind the result to a variable-    first.--    Conceptually, at least, you can think of it as having the following type:--    .. code-block:: idris--        (!) : STrans m a state_in state_out -> a--    It is syntactic sugar for binding a variable immediately before the-    current action in a ``do`` block, then using that variable in place of-    the ``!``-expression.---In general, though, it's bad practice to use a *specific* context like-``IO``. Firstly, it requires us to sprinkle ``lift`` liberally throughout-our code, which hinders readability. Secondly, and more importantly, it will-limit the safety of our functions, as we'll see in the next section-(:ref:`smstypes`).--So, instead, we define *interfaces* to restrict the computation context.-For example, ``Control.ST`` defines a ``ConsoleIO`` interface which-provides the necessary methods for performing basic console interaction:--.. code-block:: idris--    interface ConsoleIO (m : Type -> Type) where-      putStr : String -> STrans m () res (const res)-      getStr : STrans m String res (const res)--That is, we can write to and read from the console with any available-resources ``res``, and neither will affect the available resources.-This has the following implementation for ``IO``:--.. code-block:: idris--    ConsoleIO IO where-      putStr str = lift (Interactive.putStr str)-      getStr = lift Interactive.getLine--Now, we can define ``ioMakeAndIncrement`` as follows:--.. code-block:: idris--  ioMakeAndIncrement : ConsoleIO io => STrans io () [] (const [])-  ioMakeAndIncrement-     = do putStr "Enter a number: "-          init <- getStr-          var <- new (cast init)-          putStrLn ("var = " ++ show !(read var))-          increment var-          putStrLn ("var = " ++ show !(read var))-          delete var--Instead of working in ``IO`` specifically, this works in a generic context-``io``, provided that there is an implementation of ``ConsoleIO`` for that-context. This has several advantages over the first version:--* All of the calls to ``lift`` are in the implementation of the interface,-  rather than ``ioMakeAndIncrement``-* We can provide alternative implementations of ``ConsoleIO``, perhaps-  supporting exceptions or logging in addition to basic I/O.-* As we'll see in the next section (:ref:`smstypes`), it will allow us to-  define safe APIs for manipulating specific resources more precisely.--Earlier, we used ``runPure`` to run ``makeAndIncrement`` in the identity-context. Here, we use ``run``, which allows us to execute an ``STrans`` program-in any context (as long as it has an implementation of ``Applicative``) and we-can execute ``ioMakeAndIncrement`` at the REPL as follows:--.. code::--    *Intro> :exec run ioMakeAndIncrement-    Enter a number: 93-    var = 93-    var = 94--.. _depstate:--Manipulating ``State`` with dependent types-===========================================--In our first example of ``State``, when we incremented the value its-*type* remained the same. However, when we're working with-*dependent* types, updating a state may also involve updating its type.-For example, if we're adding an element to a vector stored in a state,-its length will change:--.. code-block:: idris--  addElement : (vec : Var) -> (item : a) ->-               STrans m () [vec ::: State (Vect n a)]-                    (const [vec ::: State (Vect (S n) a)])-  addElement vec item = do xs <- read vec-                           write vec (item :: xs)--Note that you'll need to ``import Data.Vect`` to try this example.--.. topic:: Updating a state directly with ``update``--    Rather than using ``read`` and ``write`` separately, you can also-    use ``update`` which reads from a ``State``, applies a function to it,-    then writes the result. Using ``update`` you could write ``addElement``-    as follows:--    .. code-block:: idris--      addElement : (vec : Var) -> (item : a) ->-                   STrans m () [vec ::: State (Vect n a)]-                        (const [vec ::: State (Vect (S n) a)])-      addElement vec item = update vec (item ::)--We don't always know *how* exactly the type will change in the course of a-sequence actions, however. For example, if we have a state containing a-vector of integers, we might read an input from the console and only add it-to the vector if the input is a valid integer. Somehow, we need a different-type for the output state depending on whether reading the integer was-successful, so neither of the following types is quite right:--.. code-block:: idris--  readAndAdd_OK : ConsoleIO io => (vec : Var) ->-                  STrans m ()  -- Returns an empty tuple-                              [vec ::: State (Vect n Integer)]-                       (const [vec ::: State (Vect (S n) Integer)])-  readAndAdd_Fail : ConsoleIO io => (vec : Var) ->-                    STrans m ()  -- Returns an empty tuple-                                [vec ::: State (Vect n Integer)]-                         (const [vec ::: State (Vect n Integer)])--Remember, though, that the *output* resource types can be *computed* from-the result of a function. So far, we've used ``const`` to note that the-output resources are always the same, but here, instead, we can use a type-level function to *calculate* the output resources. We start by returning-a ``Bool`` instead of an empty tuple, which is ``True`` if reading the input-was successful, and leave a *hole* for the output resources:--.. code-block:: idris--  readAndAdd : ConsoleIO io => (vec : Var) ->-               STrans m Bool [vec ::: State (Vect n Integer)]-                             ?output_res--If you check the type of ``?output_res``, you'll see that Idris expects-a function of type ``Bool -> Resources``, meaning that the output resource-type can be different depending on the result of ``readAndAdd``:--.. code-block:: idris--      n : Nat-      m : Type -> Type-      io : Type -> Type-      constraint : ConsoleIO io-      vec : Var-    ---------------------------------------    output_res : Bool -> Resources--So, the output resource is either a ``Vect n Integer`` if the input is-invalid (i.e. ``readAndAdd`` returns ``False``) or a ``Vect (S n) Integer``-if the input is valid. We can express this in the type as follows:--.. code-block:: idris--  readAndAdd : ConsoleIO io => (vec : Var) ->-               STrans io Bool [vec ::: State (Vect n Integer)]-                     (\res => [vec ::: State (if res then Vect (S n) Integer-                                                     else Vect n Integer)])--Then, when we implement ``readAndAdd`` we need to return the appropriate-value for the output state. If we've added an item to the vector, we need to-return ``True``, otherwise we need to return ``False``:--.. code-block:: idris--  readAndAdd : ConsoleIO io => (vec : Var) ->-               STrans io Bool [vec ::: State (Vect n Integer)]-                     (\res => [vec ::: State (if res then Vect (S n) Integer-                                                     else Vect n Integer)])-  readAndAdd vec = do putStr "Enter a number: "-                      num <- getStr-                      if all isDigit (unpack num)-                         then do-                           update vec ((cast num) ::)-                           pure True     -- added an item, so return True-                         else pure False -- didn't add, so return False--There is a slight difficulty if we're developing interactively, which is-that if we leave a hole, the required output state isn't easily visible-until we know the value that's being returned. For example. in the following-incomplete definition of ``readAndAdd`` we've left a hole for the-successful case:--.. code-block:: idris--  readAndAdd vec = do putStr "Enter a number: "-                      num <- getStr-                      if all isDigit (unpack num)-                         then ?whatNow-                         else pure False--We can look at the type of ``?whatNow``, but it is unfortunately rather less-than informative:--.. code-block:: idris--      vec : Var-      n : Nat-      io : Type -> Type-      constraint : ConsoleIO io-      num : String-    ---------------------------------------    whatNow : STrans io Bool [vec ::: State (Vect (S n) Integer)]-                     (\res =>-                        [vec :::-                         State (ifThenElse res-                                           (Delay (Vect (S n) Integer))-                                           (Delay (Vect n Integer)))])--The problem is that we'll only know the required output state when we know-the value we're returning. To help with interactive development, ``Control.ST``-provides a function ``returning`` which allows us to specify the return-value up front, and to update the state accordingly. For example, we can-write an incomplete ``readAndAdd`` as follows:--.. code-block:: idris--  readAndAdd vec = do putStr "Enter a number: "-                      num <- getStr-                      if all isDigit (unpack num)-                         then returning True ?whatNow-                         else pure False--This states that, in the successful branch, we'll be returning ``True``, and-``?whatNow`` should explain how to update the states appropriately so that-they are correct for a return value of ``True``. We can see this by checking-the type of ``?whatNow``, which is now a little more informative:--.. code-block:: idris--      vec : Var-      n : Nat-      io : Type -> Type-      constraint : ConsoleIO io-      num : String-    ---------------------------------------    whatnow : STrans io () [vec ::: State (Vect n Integer)]-                     (\value => [vec ::: State (Vect (S n) Integer)])--This type now shows, in the output resource list of ``STrans``,-that we can complete the definition by adding an item to ``vec``, which-we can do as follows:--.. code-block:: idris--  readAndAdd vec = do putStr "Enter a number: "-                      num <- getStr-                      if all isDigit (unpack num)-                         then returning True (update vec ((cast num) ::))-                         else returning False (pure ()) -- returning False, so no state update required--.. _stransprimops:--``STrans`` Primitive operations-===============================--Now that we've written a few small examples of ``STrans`` functions, it's-a good time to look more closely at the types of the state manipulation-functions we've used. First, to read and write states, we've used-``read`` and ``write``:--.. code-block:: idris--    read : (lbl : Var) -> {auto prf : InState lbl (State ty) res} ->-           STrans m ty res (const res)-    write : (lbl : Var) -> {auto prf : InState lbl ty res} ->-            (val : ty') ->-            STrans m () res (const (updateRes res prf (State ty')))--These types may look a little daunting at first, particularly due to the-implicit ``prf`` argument, which has the following type:--.. code-block:: idris--    prf : InState lbl (State ty) res--This relies on a predicate ``InState``. A value of type ``InState x ty res``-means that the reference ``x`` must have type ``ty`` in the list of-resources ``res``. So, in practice, all this type means is that we can-only read or write a resource if a reference to it exists in the list of-resources.--Given a resource label ``res``, and a proof that ``res`` exists in a list-of resources, ``updateRes`` will update the type of that resource. So,-the type of ``write`` states that the type of the resource will be updated-to the type of the given value.--The type of ``update`` is similar to that for ``read`` and ``write``, requiring-that the resource has the input type of the given function, and updating it to-have the output type of the function:--.. code-block:: idris--    update : (lbl : Var) -> {auto prf : InState lbl (State ty) res} ->-             (ty -> ty') ->-             STrans m () res (const (updateRes res prf (State ty')))--The type of ``new`` states that it returns a ``Var``, and given an initial-value of type ``state``, the output resources contains a new resource-of type ``State state``:--.. code-block:: idris--    new : (val : state) ->-          STrans m Var res (\lbl => (lbl ::: State state) :: res)--It's important that the new resource has type ``State state``, rather than-merely ``state``, because this will allow us to hide implementation details-of APIs. We'll see more about what this means in the next section,-:ref:`smstypes`.--The type of ``delete`` states that the given label will be removed from-the list of resources, given an implicit proof that the label exists in-the input resources:--.. code-block:: idris--    delete : (lbl : Var) -> {auto prf : InState lbl (State st) res} ->-             STrans m () res (const (drop res prf))--Here, ``drop`` is a type level function which updates the resource list,-removing the given resource ``lbl`` from the list.--We've used ``lift`` to run functions in the underlying context. It has the-following type:--.. code-block:: idris--    lift : Monad m => m t -> STrans m t res (const res)--Given a ``result`` value, ``pure`` is an ``STrans`` program which produces-that value, provided that the current list of resources is correct when-producing that value:--.. code-block:: idris--    pure : (result : ty) -> STrans m ty (out_fn result) out_fn--We can use ``returning`` to break down returning a value from an-``STrans`` functions into two parts: providing the value itself, and updating-the resource list so that it is appropriate for returning that value:--.. code-block:: idris--    returning : (result : ty) ->-                STrans m () res (const (out_fn result)) ->-                STrans m ty res out_fn--Finally, we've used ``run`` and ``runPure`` to execute ``STrans`` functions-in a specific context. ``run`` will execute a function in any context,-provided that there is an ``Applicative`` implementation for that context,-and ``runPure`` will execute a function in the identity context:--.. code-block:: idris--    run : Applicative m => STrans m a [] (const []) -> m a-    runPure : STrans Basics.id a [] (const []) -> a--Note that in each case, the input and output resource list must be empty.-There's no way to provide an initial resource list, or extract the final-resources. This is deliberate: it ensures that *all* resource management is-carried out in the controlled ``STrans`` environment and, as we'll see, this-allows us to implement safe APIs with precise types explaining exactly how-resources are tracked throughout a program.--These functions provide the core of the ``ST`` library; there are some-others which we'll encounter later, for more advanced situations, but the-functions we have seen so far already allow quite sophisticated state-aware-programming and reasoning in Idris.--.. _sttype:--`ST`: Representing state transitions directly-=============================================--We've seen a few examples of small ``STrans`` functions now, and-their types can become quite verbose given that we need to provide explicit-input and output resource lists. This is convenient for giving types for-the primitive operations, but for more general use it's much more convenient-to be able to express *transitions* on individual resources, rather than-giving input and output resource lists in full. We can do this with-``ST``:--.. code-block:: idris--    ST : (m : Type -> Type) ->-         (resultType : Type) ->-         List (Action resultType) -> Type--``ST`` is a type level function which computes an appropriate ``STrans``-type given a list of *actions*, which describe transitions on resources.-An ``Action`` in a function type can take one of the following forms (plus-some others which we'll see later in the tutorial):--* ``lbl ::: ty`` expresses that the resource ``lbl`` begins and ends in-  the state ``ty``-* ``lbl ::: ty_in :-> ty_out`` expresses that the resource ``lbl`` begins-  in state ``ty_in`` and ends in state ``ty_out``-* ``lbl ::: ty_in :-> (\res -> ty_out)`` expresses that the resource ``lbl``-  begins in state ``ty_in`` and ends in a state ``ty_out``, where ``ty_out``-  is computed from the result of the function ``res``.--So, we can write some of the function types we've seen so far as follows:--.. code-block:: idris--  increment : (x : Var) -> ST m () [x ::: State Integer]--That is, ``increment`` begins and ends with ``x`` in state ``State Integer``.--.. code-block:: idris--  makeAndIncrement : Integer -> ST m Integer []--That is, ``makeAndIncrement`` begins and ends with no resources.--.. code-block:: idris--  addElement : (vec : Var) -> (item : a) ->-               ST m () [vec ::: State (Vect n a) :-> State (Vect (S n) a)]--That is, ``addElement`` changes ``vec`` from ``State (Vect n a)`` to-``State (Vect (S n) a)``.--.. code-block:: idris--  readAndAdd : ConsoleIO io => (vec : Var) ->-               ST io Bool-                     [vec ::: State (Vect n Integer) :->-                      \res => State (if res then Vect (S n) Integer-                                            else Vect n Integer)]--By writing the types in this way, we express the minimum necessary to explain-how each function affects the overall resource state. If there is a resource-update depending on a result, as with ``readAndAdd``, then we need to describe-it in full. Otherwise, as with ``increment`` and ``makeAndIncrement``, we can-write the input and output resource lists without repetition.--An ``Action`` can also describe *adding* and *removing* states:--* ``add ty``, assuming the operation returns a ``Var``, adds a new resource-  of type ``ty``.-* ``remove lbl ty`` expresses that the operation removes the resource named-  ``lbl``, beginning in state ``ty`` from the resource list.--So, for example, we can write:--.. code-block:: idris--  newState : ST m Var [add (State Int)]-  removeState : (lbl : Var) -> ST m () [remove lbl (State Int)]--The first of these, ``newState``, returns a new resource label, and adds that-resource to the list with type ``State Int``. The second, ``removeState``,-given a label ``lbl``, removes the resource from the list. These types are-equivalent to the following:--.. code-block:: idris--  newState : STrans m Var [] (\lbl => [lbl ::: State Int])-  removeState : (lbl : Var) -> STrans m () [lbl ::: State Int] (const [])--These are the primitive methods of constructing an ``Action``.  Later, we will-encounter some other ways using type level functions to help with readability.--In the remainder of this tutorial, we will generally use ``ST`` except on-the rare occasions we need the full precision of ``STrans``. In the next-section, we'll see how to use the facilities provided by ``ST`` to write-a precise API for a system with security properties: a data store requiring-a login.
− docs/tutorial/conclusions.rst 
@@ -1,54 +0,0 @@-.. _sect-concs:--***************-Further Reading-***************--Further information about Idris programming, and programming with-dependent types in general, can be obtained from various sources:---  The Idris web site (http://www.idris-lang.org/) and by asking-   questions on the mailing list.---  The IRC channel ``#idris``, on-   `webchat.freenode.net <https://webchat.freenode.net/>`__.--- The wiki (https://github.com/idris-lang/Idris-dev/wiki/) has further-   user provided information, in particular:--   -  https://github.com/idris-lang/Idris-dev/wiki/Manual--   -  https://github.com/idris-lang/Idris-dev/wiki/Language-Features--- Examining the prelude and exploring the ``samples`` in the-   distribution. The Idris source can be found online at:-   https://github.com/idris-lang/Idris-dev.---  Existing projects on the ``Idris Hackers`` web space:-   http://idris-hackers.github.io.--- Various papers (e.g. [1]_, [2]_, and [3]_).  Although these mostly-   describe older versions of Idris.--.. [1] Edwin Brady and Kevin Hammond. 2012. Resource-Safe systems-       programming with embedded domain specific languages. In-       Proceedings of the 14th international conference on Practical-       Aspects of Declarative Languages (PADL'12), Claudio Russo and-       Neng-Fa Zhou (Eds.). Springer-Verlag, Berlin, Heidelberg,-       242-257. DOI=10.1007/978-3-642-27694-1_18-       http://dx.doi.org/10.1007/978-3-642-27694-1_18--.. [2] Edwin C. Brady. 2011. IDRIS ---: systems programming meets full-       dependent types. In Proceedings of the 5th ACM workshop on-       Programming languages meets program verification (PLPV-       '11). ACM, New York, NY, USA,-       43-54. DOI=10.1145/1929529.1929536-       http://doi.acm.org/10.1145/1929529.1929536--.. [3] Edwin C. Brady and Kevin Hammond. 2010. Scrapping your-       inefficient engine: using partial evaluation to improve-       domain-specific language implementation. In Proceedings of the-       15th ACM SIGPLAN international conference on Functional-       programming (ICFP '10). ACM, New York, NY, USA,-       297-308. DOI=10.1145/1863543.1863587-       http://doi.acm.org/10.1145/1863543.1863587
− docs/tutorial/index.rst 
@@ -1,37 +0,0 @@-.. _tutorial-index:--##################-The Idris Tutorial-##################--This is the Idris Tutorial.-It provides a brief introduction to programming in the Idris Language.-It covers the core language features, and assumes some familiarity with an-existing functional programming language such as Haskell or OCaml.--.. note::-   The documentation for Idris has been published under the Creative-   Commons CC0 License. As such to the extent possible under law, *The-   Idris Community* has waived all copyright and related or neighboring-   rights to Documentation for Idris.--   More information concerning the CC0 can be found online at: http://creativecommons.org/publicdomain/zero/1.0/---.. toctree::-   :maxdepth: 1--   introduction-   starting-   typesfuns-   interfaces-   modules-   packages-   interp-   views-   theorems-   provisional-   interactive-   syntax-   miscellany-   conclusions
− docs/tutorial/interactive.rst 
@@ -1,257 +0,0 @@-.. _sect-interactive:--*******************-Interactive Editing-*******************--By now, we have seen several examples of how Idris’ dependent type-system can give extra confidence in a function’s correctness by giving-a more precise description of its intended behaviour in its *type*. We-have also seen an example of how the type system can help with EDSL-development by allowing a programmer to describe the type system of an-object language. However, precise types give us more than verification-of programs — we can also exploit types to help write programs which-are *correct by construction*.--The Idris REPL provides several commands for inspecting and-modifying parts of programs, based on their types, such as case-splitting on a pattern variable, inspecting the type of a-hole, and even a basic proof search mechanism. In this-section, we explain how these features can be exploited by a text-editor, and specifically how to do so in `Vim-<https://github.com/idris-hackers/idris-vim>`_. An interactive mode-for `Emacs <https://github.com/idris-hackers/idris-mode>`_ is also-available.--Editing at the REPL-===================--The REPL provides a number of commands, which we will describe-shortly, which generate new program fragments based on the currently-loaded module. These take the general form:--::--    :command [line number] [name]--That is, each command acts on a specific source line, at a specific-name, and outputs a new program fragment. Each command has an-alternative form, which *updates* the source file in-place:--::--    :command! [line number] [name]--When the REPL is loaded, it also starts a background process which-accepts and responds to REPL commands, using ``idris --client``. For-example, if we have a REPL running elsewhere, we can execute commands-such as:--::--    $ idris --client ':t plus'-    Prelude.Nat.plus : Nat -> Nat -> Nat-    $ idris --client '2+2'-    4 : Integer--A text editor can take advantage of this, along with the editing-commands, in order to provide interactive editing support.--Editing Commands-================--:addclause-------------The ``:addclause n f`` command, abbreviated ``:ac n f``, creates a-template definition for the function named ``f`` declared on line-``n``. For example, if the code beginning on line 94 contains:--.. code-block:: idris--    vzipWith : (a -> b -> c) ->-               Vect n a -> Vect n b -> Vect n c--then ``:ac 94 vzipWith`` will give:--.. code-block:: idris--    vzipWith f xs ys = ?vzipWith_rhs--The names are chosen according to hints which may be given by a-programmer, and then made unique by the machine by adding a digit if-necessary. Hints can be given as follows:--.. code-block:: idris--    %name Vect xs, ys, zs, ws--This declares that any names generated for types in the ``Vect`` family-should be chosen in the order ``xs``, ``ys``, ``zs``, ``ws``.--:casesplit-------------The ``:casesplit n x`` command, abbreviated ``:cs n x``, splits the-pattern variable ``x`` on line ``n`` into the various pattern forms it-may take, removing any cases which are impossible due to unification-errors. For example, if the code beginning on line 94 is:--.. code-block:: idris--    vzipWith : (a -> b -> c) ->-               Vect n a -> Vect n b -> Vect n c-    vzipWith f xs ys = ?vzipWith_rhs--then ``:cs 96 xs`` will give:--.. code-block:: idris--    vzipWith f [] ys = ?vzipWith_rhs_1-    vzipWith f (x :: xs) ys = ?vzipWith_rhs_2--That is, the pattern variable ``xs`` has been split into the two-possible cases ``[]`` and ``x :: xs``. Again, the names are chosen-according to the same heuristic. If we update the file (using-``:cs!``) then case split on ``ys`` on the same line, we get:--.. code-block:: idris--    vzipWith f [] [] = ?vzipWith_rhs_3--That is, the pattern variable ``ys`` has been split into one case-``[]``, Idris having noticed that the other possible case ``y ::-ys`` would lead to a unification error.--:addmissing--------------The ``:addmissing n f`` command, abbreviated ``:am n f``, adds the-clauses which are required to make the function ``f`` on line ``n``-cover all inputs. For example, if the code beginning on line 94 is:--.. code-block:: idris--    vzipWith : (a -> b -> c) ->-               Vect n a -> Vect n b -> Vect n c-    vzipWith f [] [] = ?vzipWith_rhs_1--then ``:am 96 vzipWith`` gives:--.. code-block:: idris--    vzipWith f (x :: xs) (y :: ys) = ?vzipWith_rhs_2--That is, it notices that there are no cases for empty vectors,-generates the required clauses, and eliminates the clauses which would-lead to unification errors.--:proofsearch---------------The ``:proofsearch n f`` command, abbreviated ``:ps n f``, attempts to-find a value for the hole ``f`` on line ``n`` by proof search,-trying values of local variables, recursive calls and constructors of-the required family. Optionally, it can take a list of *hints*, which-are functions it can try applying to solve the hole. For-example, if the code beginning on line 94 is:--.. code-block:: idris--    vzipWith : (a -> b -> c) ->-               Vect n a -> Vect n b -> Vect n c-    vzipWith f [] [] = ?vzipWith_rhs_1-    vzipWith f (x :: xs) (y :: ys) = ?vzipWith_rhs_2--then ``:ps 96 vzipWith_rhs_1`` will give--.. code-block:: idris--    []--This works because it is searching for a ``Vect`` of length 0, of-which the empty vector is the only possibility. Similarly, and perhaps-surprisingly, there is only one possibility if we try to solve ``:ps-97 vzipWith_rhs_2``:--.. code-block:: idris--    f x y :: (vzipWith f xs ys)--This works because ``vzipWith`` has a precise enough type: The-resulting vector has to be non-empty (a ``::``); the first element-must have type ``c`` and the only way to get this is to apply ``f`` to-``x`` and ``y``; finally, the tail of the vector can only be built-recursively.--:makewith------------The ``:makewith n f`` command, abbreviated ``:mw n f``, adds a-``with`` to a pattern clause. For example, recall ``parity``. If line-10 is:--.. code-block:: idris--    parity (S k) = ?parity_rhs--then ``:mw 10 parity`` will give:--.. code-block:: idris--    parity (S k) with (_)-      parity (S k) | with_pat = ?parity_rhs--If we then fill in the placeholder ``_`` with ``parity k`` and case-split on ``with_pat`` using ``:cs 11 with_pat`` we get the following-patterns:--.. code-block:: idris--      parity (S (plus n n)) | even = ?parity_rhs_1-      parity (S (S (plus n n))) | odd = ?parity_rhs_2--Note that case splitting has normalised the patterns here (giving-``plus`` rather than ``+``). In any case, we see that using-interactive editing significantly simplifies the implementation of-dependent pattern matching by showing a programmer exactly what the-valid patterns are.--Interactive Editing in Vim-==========================--The editor mode for Vim provides syntax highlighting, indentation and-interactive editing support using the commands described above.-Interactive editing is achieved using the following editor commands,-each of which update the buffer directly:--- ``\d`` adds a template definition for the name declared on the-   current line (using ``:addclause``).--- ``\c`` case splits the variable at the cursor (using-   ``:casesplit``).--- ``\m`` adds the missing cases for the name at the cursor (using-   ``:addmissing``).--- ``\w`` adds a ``with`` clause (using ``:makewith``).--- ``\o`` invokes a proof search to solve the hole under the-   cursor (using ``:proofsearch``).--- ``\p`` invokes a proof search with additional hints to solve the-   hole under the cursor (using ``:proofsearch``).--There are also commands to invoke the type checker and evaluator:--- ``\t`` displays the type of the (globally visible) name under the-   cursor. In the case of a hole, this displays the context-   and the expected type.--- ``\e`` prompts for an expression to evaluate.--- ``\r`` reloads and type checks the buffer.--Corresponding commands are also available in the Emacs mode. Support-for other editors can be added in a relatively straightforward manner-by using ``idris –client``.
− docs/tutorial/interfaces.rst 
@@ -1,633 +0,0 @@-.. _sect-interfaces:--**********-Interfaces-**********--We often want to define functions which work across several different-data types. For example, we would like arithmetic operators to work on-``Int``, ``Integer`` and ``Double`` at the very least. We would like-``==`` to work on the majority of data types. We would like to be able-to display different types in a uniform way.--To achieve this, we use *interfaces*, which are similar to type classes in-Haskell or traits in Rust. To define an interface, we provide a collection of-overloadable functions. A simple example is the ``Show``-interface, which is defined in the prelude and provides an interface for-converting values to ``String``:--.. code-block:: idris--    interface Show a where-        show : a -> String--This generates a function of the following type (which we call a-*method* of the ``Show`` interface):--.. code-block:: idris--    show : Show a => a -> String--We can read this as: “under the constraint that ``a`` has an implementation-of ``Show``, take an input ``a`` and return a ``String``.” An implementation-of an interface is defined by giving definitions of the methods of the interface.-For example, the ``Show`` implementation for ``Nat`` could be defined as:--.. code-block:: idris--    Show Nat where-        show Z = "Z"-        show (S k) = "s" ++ show k--::--    Idris> show (S (S (S Z)))-    "sssZ" : String--Only one implementation of an interface can be given for a type — implementations may-not overlap. Implementation declarations can themselves have constraints.-To help with resolution, the arguments of an implementation must be-constructors (either data or type constructors) or variables-(i.e. you cannot give an implementation for a function). For-example, to define a ``Show`` implementation for vectors, we need to know-that there is a ``Show`` implementation for the element type, because we are-going to use it to convert each element to a ``String``:--.. code-block:: idris--    Show a => Show (Vect n a) where-        show xs = "[" ++ show' xs ++ "]" where-            show' : Vect n a -> String-            show' Nil        = ""-            show' (x :: Nil) = show x-            show' (x :: xs)  = show x ++ ", " ++ show' xs--Default Definitions-===================--The library defines an ``Eq`` interface which provides methods for-comparing values for equality or inequality, with implementations for all of-the built-in types:--.. code-block:: idris--    interface Eq a where-        (==) : a -> a -> Bool-        (/=) : a -> a -> Bool--To declare an implementation for a type, we have to give definitions of all-of the methods. For example, for an implementation of ``Eq`` for ``Nat``:--.. code-block:: idris--    Eq Nat where-        Z     == Z     = True-        (S x) == (S y) = x == y-        Z     == (S y) = False-        (S x) == Z     = False--        x /= y = not (x == y)--It is hard to imagine many cases where the ``/=`` method will be-anything other than the negation of the result of applying the ``==``-method. It is therefore convenient to give a default definition for-each method in the interface declaration, in terms of the other method:--.. code-block:: idris--    interface Eq a where-        (==) : a -> a -> Bool-        (/=) : a -> a -> Bool--        x /= y = not (x == y)-        x == y = not (x /= y)--A minimal complete implementation of ``Eq`` requires either-``==`` or ``/=`` to be defined, but does not require both. If a method-definition is missing, and there is a default definition for it, then-the default is used instead.--Extending Interfaces-====================--Interfaces can also be extended. A logical next step from an equality-relation ``Eq`` is to define an ordering relation ``Ord``. We can-define an ``Ord`` interface which inherits methods from ``Eq`` as well as-defining some of its own:--.. code-block:: idris--    data Ordering = LT | EQ | GT--.. code-block:: idris--    interface Eq a => Ord a where-        compare : a -> a -> Ordering--        (<) : a -> a -> Bool-        (>) : a -> a -> Bool-        (<=) : a -> a -> Bool-        (>=) : a -> a -> Bool-        max : a -> a -> a-        min : a -> a -> a--The ``Ord`` interface allows us to compare two values and determine their-ordering. Only the ``compare`` method is required; every other method-has a default definition. Using this we can write functions such as-``sort``, a function which sorts a list into increasing order,-provided that the element type of the list is in the ``Ord`` interface. We-give the constraints on the type variables left of the fat arrow-``=>``, and the function type to the right of the fat arrow:--.. code-block:: idris--    sort : Ord a => List a -> List a--Functions, interfaces and implementations can have multiple-constraints. Multiple constraints are written in brackets in a comma-separated list, for example:--.. code-block:: idris--    sortAndShow : (Ord a, Show a) => List a -> String-    sortAndShow xs = show (sort xs)--Note: Interfaces and ``mutual`` blocks-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~--Idris is strictly "define before use", except in ``mutual`` blocks.-In a ``mutual`` block, Idris elaborates in two passes: types on the first-pass and definitions on the second. When the mutual block contains an-interface declaration, it elaborates the interface header but none of the-method types on the first pass, and elaborates the method types and any-default definitions on the second pass.--Functors and Applicatives-=========================--So far, we have seen single parameter interfaces, where the parameter-is of type ``Type``. In general, there can be any number of parameters-(even zero), and the parameters can have *any* type. If the type-of the parameter is not ``Type``, we need to give an explicit type-declaration. For example, the ``Functor`` interface is defined in the-prelude:--.. code-block:: idris--    interface Functor (f : Type -> Type) where-        map : (m : a -> b) -> f a -> f b--A functor allows a function to be applied across a structure, for-example to apply a function to every element in a ``List``:--.. code-block:: idris--    Functor List where-      map f []      = []-      map f (x::xs) = f x :: map f xs--::--    Idris> map (*2) [1..10]-    [2, 4, 6, 8, 10, 12, 14, 16, 18, 20] : List Integer--Having defined ``Functor``, we can define ``Applicative`` which-abstracts the notion of function application:--.. code-block:: idris--    infixl 2 <*>--    interface Functor f => Applicative (f : Type -> Type) where-        pure  : a -> f a-        (<*>) : f (a -> b) -> f a -> f b--.. _monadsdo:--Monads and ``do``-notation-==========================--The ``Monad`` interface allows us to encapsulate binding and computation,-and is the basis of ``do``-notation introduced in Section-:ref:`sect-do`. It extends ``Applicative`` as defined above, and is-defined as follows:--.. code-block:: idris--    interface Applicative m => Monad (m : Type -> Type) where-        (>>=)  : m a -> (a -> m b) -> m b--Inside a ``do`` block, the following syntactic transformations are-applied:--- ``x <- v; e`` becomes ``v >>= (\x => e)``--- ``v; e`` becomes ``v >>= (\_ => e)``--- ``let x = v; e`` becomes ``let x = v in e``--``IO`` has an implementation of ``Monad``, defined using primitive functions.-We can also define an implementation for ``Maybe``, as follows:--.. code-block:: idris--    Monad Maybe where-        Nothing  >>= k = Nothing-        (Just x) >>= k = k x--Using this we can, for example, define a function which adds two-``Maybe Int``, using the monad to encapsulate the error handling:--.. code-block:: idris--    m_add : Maybe Int -> Maybe Int -> Maybe Int-    m_add x y = do x' <- x -- Extract value from x-                   y' <- y -- Extract value from y-                   pure (x' + y') -- Add them--This function will extract the values from ``x`` and ``y``, if they-are both available, or return ``Nothing`` if one or both are not ("fail fast"). Managing the-``Nothing`` cases is achieved by the ``>>=`` operator, hidden by the-``do`` notation.--::--    *Interfaces> m_add (Just 20) (Just 22)-    Just 42 : Maybe Int-    *Interfaces> m_add (Just 20) Nothing-    Nothing : Maybe Int--Pattern Matching Bind-~~~~~~~~~~~~~~~~~~~~~--Sometimes we want to pattern match immediately on the result of a function-in ``do`` notation. For example, let's say we have a function ``readNumber``-which reads a number from the console, returning a value of the form-``Just x`` if the number is valid, or ``Nothing`` otherwise:--.. code-block:: idris--    readNumber : IO (Maybe Nat)-    readNumber = do-      input <- getLine-      if all isDigit (unpack input)-         then pure (Just (cast input))-         else pure Nothing--If we then use it to write a function to read two numbers, returning-``Nothing`` if neither are valid, then we would like to pattern match-on the result of ``readNumber``:--.. code-block:: idris--    readNumbers : IO (Maybe (Nat, Nat))-    readNumbers =-      do x <- readNumber-         case x of-              Nothing => pure Nothing-              Just x_ok => do y <- readNumber-                              case y of-                                   Nothing => pure Nothing-                                   Just y_ok => pure (Just (x_ok, y_ok))--If there's a lot of error handling, this could get deeply nested very quickly!-So instead, we can combine the bind and the pattern match in one line. For example,-we could try pattern matching on values of the form ``Just x_ok``:--.. code-block:: idris--    readNumbers : IO (Maybe (Nat, Nat))-    readNumbers =-      do Just x_ok <- readNumber-         Just y_ok <- readNumber-         pure (Just (x_ok, y_ok))--There is still a problem, however, because we've now omitted the case for-``Nothing`` so ``readNumbers`` is no longer total! We can add the ``Nothing``-case back as follows:--.. code-block:: idris--    readNumbers : IO (Maybe (Nat, Nat))-    readNumbers =-      do Just x_ok <- readNumber | Nothing => pure Nothing-         Just y_ok <- readNumber | Nothing => pure Nothing-         pure (Just (x_ok, y_ok))--The effect of this version of ``readNumbers`` is identical to the first (in-fact, it is syntactic sugar for it and directly translated back into that form).-The first part of each statement (``Just x_ok <-`` and ``Just y_ok <-``) gives-the preferred binding - if this matches, execution will continue with the rest-of the ``do`` block. The second part gives the alternative bindings, of which-there may be more than one.--``!``-notation-~~~~~~~~~~~~~~--In many cases, using ``do``-notation can make programs unnecessarily-verbose, particularly in cases such as ``m_add`` above where the value-bound is used once, immediately. In these cases, we can use a-shorthand version, as follows:--.. code-block:: idris--    m_add : Maybe Int -> Maybe Int -> Maybe Int-    m_add x y = pure (!x + !y)--The notation ``!expr`` means that the expression ``expr`` should be-evaluated and then implicitly bound. Conceptually, we can think of-``!`` as being a prefix function with the following type:--.. code-block:: idris--    (!) : m a -> a--Note, however, that it is not really a function, merely syntax! In-practice, a subexpression ``!expr`` will lift ``expr`` as high as-possible within its current scope, bind it to a fresh name ``x``, and-replace ``!expr`` with ``x``. Expressions are lifted depth first, left-to right. In practice, ``!``-notation allows us to program in a more-direct style, while still giving a notational clue as to which-expressions are monadic.--For example, the expression:--.. code-block:: idris--    let y = 42 in f !(g !(print y) !x)--is lifted to:--.. code-block:: idris--    let y = 42 in do y' <- print y-                     x' <- x-                     g' <- g y' x'-                     f g'--Monad comprehensions-~~~~~~~~~~~~~~~~~~~~--The list comprehension notation we saw in Section-:ref:`sect-more-expr` is more general, and applies to anything which-has an implementation of both ``Monad`` and ``Alternative``:--.. code-block:: idris--    interface Applicative f => Alternative (f : Type -> Type) where-        empty : f a-        (<|>) : f a -> f a -> f a--In general, a comprehension takes the form ``[ exp | qual1, qual2, …,-qualn ]`` where ``quali`` can be one of:--- A generator ``x <- e``--- A *guard*, which is an expression of type ``Bool``--- A let binding ``let x = e``--To translate a comprehension ``[exp | qual1, qual2, …, qualn]``, first-any qualifier ``qual`` which is a *guard* is translated to ``guard-qual``, using the following function:--.. code-block:: idris--    guard : Alternative f => Bool -> f ()--Then the comprehension is converted to ``do`` notation:--.. code-block:: idris--    do { qual1; qual2; ...; qualn; pure exp; }--Using monad comprehensions, an alternative definition for ``m_add``-would be:--.. code-block:: idris--    m_add : Maybe Int -> Maybe Int -> Maybe Int-    m_add x y = [ x' + y' | x' <- x, y' <- y ]--Idiom brackets-==============--While ``do`` notation gives an alternative meaning to sequencing,-idioms give an alternative meaning to *application*. The notation and-larger example in this section is inspired by Conor McBride and Ross-Paterson’s paper “Applicative Programming with Effects” [1]_.--First, let us revisit ``m_add`` above. All it is really doing is-applying an operator to two values extracted from ``Maybe Int``. We-could abstract out the application:--.. code-block:: idris--    m_app : Maybe (a -> b) -> Maybe a -> Maybe b-    m_app (Just f) (Just a) = Just (f a)-    m_app _        _        = Nothing--Using this, we can write an alternative ``m_add`` which uses this-alternative notion of function application, with explicit calls to-``m_app``:--.. code-block:: idris--    m_add' : Maybe Int -> Maybe Int -> Maybe Int-    m_add' x y = m_app (m_app (Just (+)) x) y--Rather than having to insert ``m_app`` everywhere there is an-application, we can use idiom brackets to do the job for us.-To do this, we can give ``Maybe`` an implementation of ``Applicative``-as follows, where ``<*>`` is defined in the same way as ``m_app``-above (this is defined in the Idris library):--.. code-block:: idris--    Applicative Maybe where-        pure = Just--        (Just f) <*> (Just a) = Just (f a)-        _        <*> _        = Nothing--Using ``<*>`` we can use this implementation as follows, where a function-application ``[| f a1 …an |]`` is translated into ``pure f <*> a1 <*>-… <*> an``:--.. code-block:: idris--    m_add' : Maybe Int -> Maybe Int -> Maybe Int-    m_add' x y = [| x + y |]--An error-handling interpreter-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~--Idiom notation is commonly useful when defining evaluators. McBride-and Paterson describe such an evaluator [1]_, for a language similar-to the following:--.. code-block:: idris--    data Expr = Var String      -- variables-              | Val Int         -- values-              | Add Expr Expr   -- addition--Evaluation will take place relative to a context mapping variables-(represented as ``String``\s) to ``Int`` values, and can possibly fail.-We define a data type ``Eval`` to wrap an evaluator:--.. code-block:: idris--    data Eval : Type -> Type where-         MkEval : (List (String, Int) -> Maybe a) -> Eval a--Wrapping the evaluator in a data type means we will be able to provide-implementations of interfaces for it later. We begin by defining a function to-retrieve values from the context during evaluation:--.. code-block:: idris--    fetch : String -> Eval Int-    fetch x = MkEval (\e => fetchVal e) where-        fetchVal : List (String, Int) -> Maybe Int-        fetchVal [] = Nothing-        fetchVal ((v, val) :: xs) = if (x == v)-                                      then (Just val)-                                      else (fetchVal xs)--When defining an evaluator for the language, we will be applying functions in-the context of an ``Eval``, so it is natural to give ``Eval`` an implementation-of ``Applicative``. Before ``Eval`` can have an implementation of-``Applicative`` it is necessary for ``Eval`` to have an implementation of-``Functor``:--.. code-block:: idris--    Functor Eval where-        map f (MkEval g) = MkEval (\e => map f (g e))--    Applicative Eval where-        pure x = MkEval (\e => Just x)--        (<*>) (MkEval f) (MkEval g) = MkEval (\x => app (f x) (g x)) where-            app : Maybe (a -> b) -> Maybe a -> Maybe b-            app (Just fx) (Just gx) = Just (fx gx)-            app _         _         = Nothing--Evaluating an expression can now make use of the idiomatic application-to handle errors:--.. code-block:: idris--    eval : Expr -> Eval Int-    eval (Var x)   = fetch x-    eval (Val x)   = [| x |]-    eval (Add x y) = [| eval x + eval y |]--    runEval : List (String, Int) -> Expr -> Maybe Int-    runEval env e = case eval e of-        MkEval envFn => envFn env--Named Implementations-=====================--It can be desirable to have multiple implementations of an interface for the-same type, for example to provide alternative methods for sorting or printing-values. To achieve this, implementations can be *named* as follows:--.. code-block:: idris--    [myord] Ord Nat where-       compare Z (S n)     = GT-       compare (S n) Z     = LT-       compare Z Z         = EQ-       compare (S x) (S y) = compare @{myord} x y--This declares an implementation as normal, but with an explicit name,-``myord``. The syntax ``compare @{myord}`` gives an explicit implementation to-``compare``, otherwise it would use the default implementation for ``Nat``. We-can use this, for example, to sort a list of ``Nat`` in reverse.-Given the following list:--.. code-block:: idris--    testList : List Nat-    testList = [3,4,1]--We can sort it using the default ``Ord`` implementation, then the named-implementation ``myord`` as follows, at the Idris prompt:--::--    *named_impl> show (sort testList)-    "[sO, sssO, ssssO]" : String-    *named_impl> show (sort @{myord} testList)-    "[ssssO, sssO, sO]" : String---Sometimes, we also need access to a named parent implementation. For example,-the prelude defines the following ``Semigroup`` interface:--.. code-block:: idris--    interface Semigroup ty where-      (<+>) : ty -> ty -> ty--Then it defines ``Monoid``, which extends ``Semigroup`` with a “neutral”-value:--.. code-block:: idris--    interface Semigroup ty => Monoid ty where-      neutral : ty--We can define two different implementations of ``Semigroup`` and-``Monoid`` for ``Nat``, one based on addition and one on multiplication:--.. code-block:: idris--    [PlusNatSemi] Semigroup Nat where-      (<+>) x y = x + y--    [MultNatSemi] Semigroup Nat where-      (<+>) x y = x * y--The neutral value for addition is ``0``, but the neutral value for multiplication-is ``1``. It's important, therefore, that when we define implementations-of ``Monoid`` they extend the correct ``Semigroup`` implementation. We can-do this with a ``using`` clause in the implementation as follows:--.. code-block:: idris--    [PlusNatMonoid] Monoid Nat using PlusNatSemi where-      neutral = 0--    [MultNatMonoid] Monoid Nat using MultNatSemi where-      neutral = 1--The ``using PlusNatSemi`` clause indicates that ``PlusNatMonoid`` should-extend ``PlusNatSemi`` specifically.--Determining Parameters-======================--When an interface has more than one parameter, it can help resolution if the-parameters used to find an implementation are restricted. For example:--.. code-block:: idris--    interface Monad m => MonadState s (m : Type -> Type) | m where-      get : m s-      put : s -> m ()--In this interface, only ``m`` needs to be known to find an implementation of-this interface, and ``s`` can then be determined from the implementation. This-is declared with the ``| m`` after the interface declaration. We call ``m`` a-*determining parameter* of the ``MonadState`` interface, because it is the-parameter used to find an implementation.---.. [1] Conor McBride and Ross Paterson. 2008. Applicative programming-       with effects. J. Funct. Program. 18, 1 (January 2008),-       1-13. DOI=10.1017/S0956796807006326-       http://dx.doi.org/10.1017/S0956796807006326
− docs/tutorial/interp.rst 
@@ -1,300 +0,0 @@-.. _sect-interp:--***********************************-Example: The Well-Typed Interpreter-***********************************--In this section, we’ll use the features we’ve seen so far to write a-larger example, an interpreter for a simple functional programming-language, with variables, function application, binary operators and-an ``if...then...else`` construct. We will use the dependent type-system to ensure that any programs which can be represented are-well-typed.--Representing Languages-======================--First, let us define the types in the language. We have integers,-booleans, and functions, represented by ``Ty``:--.. code-block:: idris--    data Ty = TyInt | TyBool | TyFun Ty Ty--We can write a function to translate these representations to a concrete-Idris type — remember that types are first class, so can be-calculated just like any other value:--.. code-block:: idris--    interpTy : Ty -> Type-    interpTy TyInt       = Integer-    interpTy TyBool      = Bool-    interpTy (TyFun a t) = interpTy a -> interpTy t--We're going to define a representation of our language in such a way-that only well-typed programs can be represented. We'll index the-representations of expressions by their type, **and** the types of-local variables (the context). The context can be represented using-the ``Vect`` data type, and as it will be used regularly it will be-represented as an implicit argument. To do so we define everything in-a ``using`` block (keep in mind that everything after this point needs-to be indented so as to be inside the ``using`` block):--.. code-block:: idris--    using (G:Vect n Ty)--Expressions are indexed by the types of the local variables, and the type of-the expression itself:--.. code-block:: idris--    data Expr : Vect n Ty -> Ty -> Type--The full representation of expressions is:--.. code-block:: idris--    data HasType : (i : Fin n) -> Vect n Ty -> Ty -> Type where-        Stop : HasType FZ (t :: G) t-        Pop  : HasType k G t -> HasType (FS k) (u :: G) t--    data Expr : Vect n Ty -> Ty -> Type where-        Var : HasType i G t -> Expr G t-        Val : (x : Integer) -> Expr G TyInt-        Lam : Expr (a :: G) t -> Expr G (TyFun a t)-        App : Expr G (TyFun a t) -> Expr G a -> Expr G t-        Op  : (interpTy a -> interpTy b -> interpTy c) ->-              Expr G a -> Expr G b -> Expr G c-        If  : Expr G TyBool ->-              Lazy (Expr G a) ->-              Lazy (Expr G a) -> Expr G a--The code above makes use of the ``Vect`` and ``Fin`` types from the-Idris standard library. We import them because they are not provided-in the prelude:--.. code-block:: idris--    import Data.Vect-    import Data.Fin--Since expressions are indexed by their type, we can read the typing-rules of the language from the definitions of the constructors. Let us-look at each constructor in turn.--We use a nameless representation for variables — they are *de Bruijn-indexed*. Variables are represented by a proof of their membership in-the context, ``HasType i G T``, which is a proof that variable ``i``-in context ``G`` has type ``T``. This is defined as follows:--.. code-block:: idris--    data HasType : (i : Fin n) -> Vect n Ty -> Ty -> Type where-        Stop : HasType FZ (t :: G) t-        Pop  : HasType k G t -> HasType (FS k) (u :: G) t--We can treat *Stop* as a proof that the most recently defined variable-is well-typed, and *Pop n* as a proof that, if the ``n``\ th most-recently defined variable is well-typed, so is the ``n+1``\ th. In-practice, this means we use ``Stop`` to refer to the most recently-defined variable, ``Pop Stop`` to refer to the next, and so on, via-the ``Var`` constructor:--.. code-block:: idris--    Var : HasType i G t -> Expr G t--So, in an expression ``\x. \y. x y``, the variable ``x`` would have a-de Bruijn index of 1, represented as ``Pop Stop``, and ``y 0``,-represented as ``Stop``. We find these by counting the number of-lambdas between the definition and the use.--A value carries a concrete representation of an integer:--.. code-block:: idris--    Val : (x : Integer) -> Expr G TyInt--A lambda creates a function. In the scope of a function of type ``a ->-t``, there is a new local variable of type ``a``, which is expressed-by the context index:--.. code-block:: idris--    Lam : Expr (a :: G) t -> Expr G (TyFun a t)--Function application produces a value of type ``t`` given a function-from ``a`` to ``t`` and a value of type ``a``:--.. code-block:: idris--    App : Expr G (TyFun a t) -> Expr G a -> Expr G t--We allow arbitrary binary operators, where the type of the operator-informs what the types of the arguments must be:--.. code-block:: idris--    Op : (interpTy a -> interpTy b -> interpTy c) ->-         Expr G a -> Expr G b -> Expr G c--Finally, ``If`` expressions make a choice given a boolean. Each branch-must have the same type, and we will evaluate the branches lazily so-that only the branch which is taken need be evaluated:--.. code-block:: idris--    If : Expr G TyBool ->-         Lazy (Expr G a) ->-         Lazy (Expr G a) ->-         Expr G a--Writing the Interpreter-=======================--When we evaluate an ``Expr``, we'll need to know the values in scope,-as well as their types. ``Env`` is an environment, indexed over the-types in scope. Since an environment is just another form of list,-albeit with a strongly specified connection to the vector of local-variable types, we use the usual ``::`` and ``Nil`` constructors 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:--.. code-block:: idris--    data Env : Vect n Ty -> Type where-        Nil  : Env Nil-        (::) : interpTy a -> Env G -> Env (a :: G)--    lookup : HasType i G t -> Env G -> interpTy t-    lookup Stop    (x :: xs) = x-    lookup (Pop k) (x :: xs) = lookup k xs--Given this, an interpreter is a function which-translates an ``Expr`` into a concrete Idris value with respect to a-specific environment:--.. code-block:: idris--    interp : Env G -> Expr G t -> interpTy t--The complete interpreter is defined as follows, for reference. For-each constructor, we translate it into the corresponding Idris value:--.. code-block:: idris--    interp env (Var i)     = lookup i env-    interp env (Val x)     = x-    interp env (Lam sc)    = \x => interp (x :: env) sc-    interp env (App f s)   = interp env f (interp env s)-    interp env (Op op x y) = op (interp env x) (interp env y)-    interp env (If x t e)  = if interp env x then interp env t-                                             else interp env e--Let us look at each case in turn. To translate a variable, we simply look it-up in the environment:--.. code-block:: idris--    interp env (Var i) = lookup i env--To translate a value, we just return the concrete representation of the-value:--.. code-block:: idris--    interp env (Val x) = x--Lambdas are more interesting. In this case, we construct a function-which interprets the scope of the lambda with a new value in the-environment. So, a function in the object language is translated to an-Idris function:--.. code-block:: idris--    interp env (Lam sc) = \x => interp (x :: env) sc--For an application, we interpret the function and its argument and apply-it directly. We know that interpreting ``f`` must produce a function,-because of its type:--.. code-block:: idris--    interp env (App f s) = interp env f (interp env s)--Operators and conditionals are, again, direct translations into the-equivalent Idris constructs. For operators, we apply the function to-its operands directly, and for ``If``, we apply the Idris-``if...then...else`` construct directly.--.. code-block:: idris--    interp env (Op op x y) = op (interp env x) (interp env y)-    interp env (If x t e)  = if interp env x then interp env t-                                             else interp env e--Testing-=======--We can make some simple test functions. Firstly, adding two inputs-``\x. \y. y + x`` is written as follows:--.. code-block:: idris--    add : Expr G (TyFun TyInt (TyFun TyInt TyInt))-    add = Lam (Lam (Op (+) (Var Stop) (Var (Pop Stop))))--More interestingly, a factorial function ``fact``-(e.g. ``\x. if (x == 0) then 1 else (fact (x-1) * x)``),-can be written as:--.. code-block:: idris--    fact : Expr G (TyFun TyInt TyInt)-    fact = Lam (If (Op (==) (Var Stop) (Val 0))-                   (Val 1)-                   (Op (*) (App fact (Op (-) (Var Stop) (Val 1)))-                           (Var Stop)))--Running-=======--To finish, we write a ``main`` program which interprets the factorial-function on user input:--.. code-block:: idris--    main : IO ()-    main = do putStr "Enter a number: "-              x <- getLine-              printLn (interp [] fact (cast x))--Here, ``cast`` is an overloaded function which converts a value from-one type to another if possible. Here, it converts a string to an-integer, giving 0 if the input is invalid. An example run of this-program at the Idris interactive environment is:---.. _factrun:-.. literalinclude:: ../listing/idris-prompt-interp.txt---Aside: ``cast``------------------The prelude defines an interface ``Cast`` which allows conversion-between types:--.. code-block:: idris--    interface Cast from to where-        cast : from -> to--It is a *multi-parameter* interface, defining the source type and-object type of the cast. It must be possible for the type checker to-infer *both* parameters at the point where the cast is applied. There-are casts defined between all of the primitive types, as far as they-make sense.
− docs/tutorial/introduction.rst 
@@ -1,74 +0,0 @@-.. _sect-intro:--************-Introduction-************--In conventional programming languages, there is a clear distinction-between *types* and *values*. For example, in `Haskell-<http://www.haskell.org>`_, the following are types, representing-integers, characters, lists of characters, and lists of any value-respectively:---  ``Int``, ``Char``, ``[Char]``, ``[a]``--Correspondingly, the following values are examples of inhabitants of-those types:---  ``42``, ``’a’``, ``"Hello world!"``, ``[2,3,4,5,6]``--In a language with *dependent types*, however, the distinction is less-clear. Dependent types allow types to “depend” on values — in other-words, types are a *first class* language construct and can be-manipulated like any other value. The standard example is the type of-lists of a given length [1]_, ``Vect n a``, where ``a`` is the element-type and ``n`` is the length of the list and can be an arbitrary term.--When types can contain values, and where those values describe-properties, for example the length of a list, the type of a function-can begin to describe its own properties. Take for example the-concatenation of two lists. This operation has the property that the-resulting list's length is the sum of the lengths of the two input-lists. We can therefore give the following type to the ``app``-function, which concatenates vectors:--.. code-block:: idris--    app : Vect n a -> Vect m a -> Vect (n + m) a--This tutorial introduces Idris, a general purpose functional-programming language with dependent types. The goal of the Idris-project is to build a dependently typed language suitable for-verifiable general purpose programming. To this end, Idris is a compiled-language which aims to generate efficient executable code. It also has-a lightweight foreign function interface which allows easy interaction-with external ``C`` libraries.--Intended Audience-=================--This tutorial is intended as a brief introduction to the language, and-is aimed at readers already familiar with a functional language such-as `Haskell <http://www.haskell.org>`_ or `OCaml <http://ocaml.org>`_.-In particular, a certain amount of familiarity with Haskell syntax is-assumed, although most concepts will at least be explained-briefly. The reader is also assumed to have some interest in using-dependent types for writing and verifying systems software.--For a more in-depth introduction to Idris, which proceeds at a much slower-pace, covering interactive program development, with many more examples, see-`Type-Driven Development with Idris <https://www.manning.com/books/type-driven-development-with-idris>`_-by Edwin Brady, available from `Manning <https://www.manning.com>`_.--Example Code-============--This tutorial includes some example code, which has been tested with-against Idris. These files are available with the Idris distribution,-so that you can try them out easily. They can be found under-``samples``. It is, however, strongly recommended that you type-them in yourself, rather than simply loading and reading them.--.. [1]-   Typically, and perhaps confusingly, referred to in the dependently-   typed programming literature as “vectors”
− docs/tutorial/miscellany.rst 
@@ -1,589 +0,0 @@-.. _sect-misc:--**********-Miscellany-**********--In this section we discuss a variety of additional features:--+ auto, implicit, and default arguments;-+ literate programming;-+ interfacing with external libraries through the foreign function;-+ interface;-+ type providers;-+ code generation; and-+ the universe hierarchy.--Implicit arguments-=======================--We have already seen implicit arguments, which allows arguments to be-omitted when they can be inferred by the type checker, e.g.--.. code-block:: idris--    index : {a:Type} -> {n:Nat} -> Fin n -> Vect n a -> a--Auto implicit arguments---------------------------In other situations, it may be possible to infer arguments not by type-checking but by searching the context for an appropriate value, or-constructing a proof. For example, the following definition of ``head``-which requires a proof that the list is non-empty:--.. code-block:: idris--    isCons : List a -> Bool-    isCons [] = False-    isCons (x :: xs) = True--    head : (xs : List a) -> (isCons xs = True) -> a-    head (x :: xs) _ = x--If the list is statically known to be non-empty, either because its-value is known or because a proof already exists in the context, the-proof can be constructed automatically. Auto implicit arguments allow-this to happen silently. We define ``head`` as follows:--.. code-block:: idris--    head : (xs : List a) -> {auto p : isCons xs = True} -> a-    head (x :: xs) = x--The ``auto`` annotation on the implicit argument means that Idris-will attempt to fill in the implicit argument by searching for a value-of the appropriate type. It will try the following, in order:--- Local variables, i.e. names bound in pattern matches or ``let`` bindings,-  with exactly the right type.-- The constructors of the required type. If they have arguments, it will-  search recursively up to a maximum depth of 100.-- Local variables with function types, searching recursively for the-  arguments.-- Any function with the appropriate return type which is marked with the-  ``%hint`` annotation.--In the case that a proof is not found, it can be provided explicitly as normal:--.. code-block:: idris--    head xs {p = ?headProof}--Default implicit arguments------------------------------Besides having Idris automatically find a value of a given type, sometimes we-want to have an implicit argument with a specific default value. In Idris, we can-do this using the ``default`` annotation. While this is primarily intended to assist-in automatically constructing a proof where auto fails, or finds an unhelpful value,-it might be easier to first consider a simpler case, not involving proofs.--If we want to compute the n'th fibonacci number (and defining the 0th fibonacci-number as 0), we could write:--.. code-block:: idris--	fibonacci : {default 0 lag : Nat} -> {default 1 lead : Nat} -> (n : Nat) -> Nat-	fibonacci {lag} Z = lag-	fibonacci {lag} {lead} (S n) = fibonacci {lag=lead} {lead=lag+lead} n--After this definition, ``fibonacci 5`` is equivalent to ``fibonacci {lag=0} {lead=1} 5``,-and will return the 5th fibonacci number. Note that while this works, this is not the-intended use of the ``default`` annotation. It is included here for illustrative purposes-only. Usually, ``default`` is used to provide things like a custom proof search script.---Implicit conversions-====================--Idris supports the creation of *implicit conversions*, which allow-automatic conversion of values from one type to another when required to-make a term type correct. This is intended to increase convenience and-reduce verbosity. A contrived but simple example is the following:--.. code-block:: idris--    implicit intString : Int -> String-    intString = show--    test : Int -> String-    test x = "Number " ++ x--In general, we cannot append an ``Int`` to a ``String``, but the-implicit conversion function ``intString`` can convert ``x`` to a-``String``, so the definition of ``test`` is type correct. An implicit-conversion is implemented just like any other function, but given the-``implicit`` modifier, and restricted to one explicit argument.--Only one implicit conversion will be applied at a time. That is,-implicit conversions cannot be chained. Implicit conversions of simple-types, as above, are however discouraged! More commonly, an implicit-conversion would be used to reduce verbosity in an embedded domain-specific language, or to hide details of a proof. Such examples are-beyond the scope of this tutorial.--Literate programming-====================--Like Haskell, Idris supports *literate* programming. If a file has-an extension of ``.lidr`` then it is assumed to be a literate file. In-literate programs, everything is assumed to be a comment unless the line-begins with a greater than sign ``>``, for example:--.. code-block:: idris--    > module literate--    This is a comment. The main program is below--    > main : IO ()-    > main = putStrLn "Hello literate world!\n"--An additional restriction is that there must be a blank line between a-program line (beginning with ``>``) and a comment line (beginning with-any other character).--Foreign function calls-======================--For practical programming, it is often necessary to be able to use-external libraries, particularly for interfacing with the operating-system, file system, networking, *et cetera*. Idris provides a-lightweight foreign function interface for achieving this, as part of-the prelude. For this, we assume a certain amount of knowledge of C and-the ``gcc`` compiler. First, we define a datatype which describes the-external types we can handle:--.. code-block:: idris--    data FTy = FInt | FFloat | FChar | FString | FPtr | FUnit--Each of these corresponds directly to a C type. Respectively: ``int``,-``double``, ``char``, ``char*``, ``void*`` and ``void``. There is also a-translation to a concrete Idris type, described by the following-function:--.. code-block:: idris--    interpFTy : FTy -> Type-    interpFTy FInt    = Int-    interpFTy FFloat  = Double-    interpFTy FChar   = Char-    interpFTy FString = String-    interpFTy FPtr    = Ptr-    interpFTy FUnit   = ()--A foreign function is described by a list of input types and a return-type, which can then be converted to an Idris type:--.. code-block:: idris--    ForeignTy : (xs:List FTy) -> (t:FTy) -> Type--A foreign function is assumed to be impure, so ``ForeignTy`` builds an-``IO`` type, for example:--.. code-block:: idris--    Idris> ForeignTy [FInt, FString] FString-    Int -> String -> IO String : Type--    Idris> ForeignTy [FInt, FString] FUnit-    Int -> String -> IO () : Type--We build a call to a foreign function by giving the name of the-function, a list of argument types and the return type. The built in-construct ``mkForeign`` converts this description to a function callable-by Idris:--.. code-block:: idris--    data Foreign : Type -> Type where-        FFun : String -> (xs:List FTy) -> (t:FTy) ->-               Foreign (ForeignTy xs t)--    mkForeign : Foreign x -> x--Note that the compiler expects ``mkForeign`` to be fully applied to-build a complete foreign function call. For example, the ``putStr``-function is implemented as follows, as a call to an external function-``putStr`` defined in the run-time system:--.. code-block:: idris--    putStr : String -> IO ()-    putStr x = mkForeign (FFun "putStr" [FString] FUnit) x--Include and linker directives--------------------------------Foreign function calls are translated directly to calls to C functions,-with appropriate conversion between the Idris representation of a-value and the C representation. Often this will require extra libraries-to be linked in, or extra header and object files. This is made possible-through the following directives:---  ``%lib target x`` — include the ``libx`` library. If the target is-   ``C`` this is equivalent to passing the ``-lx`` option to ``gcc``. If-   the target is Java the library will be interpreted as a-   ``groupId:artifactId:packaging:version`` dependency coordinate for-   maven.---  ``%include target x`` — use the header file or import ``x`` for the-   given back end target.---  ``%link target x.o`` — link with the object file ``x.o`` when using-   the given back end target.---  ``%dynamic x.so`` — dynamically link the interpreter with the shared-   object ``x.so``.--Testing foreign function calls---------------------------------Normally, the Idris interpreter (used for typechecking and at the REPL)-will not perform IO actions. Additionally, as it neither generates C-code nor compiles to machine code, the ``%lib``, ``%include`` and-``%link`` directives have no effect. IO actions and FFI calls can be-tested using the special REPL command ``:x EXPR``, and C libraries can-be dynamically loaded in the interpreter by using the ``:dynamic``-command or the ``%dynamic`` directive. For example:--.. code-block:: idris--    Idris> :dynamic libm.so-    Idris> :x unsafePerformIO ((mkForeign (FFun "sin" [FFloat] FFloat)) 1.6)-    0.9995736030415051 : Double--Type Providers-==============--Idris type providers, inspired by F#’s type providers, are a means of-making our types be “about” something in the world outside of Idris. For-example, given a type that represents a database schema and a query that-is checked against it, a type provider could read the schema of a real-database during type checking.--Idris type providers use the ordinary execution semantics of Idris to-run an IO action and extract the result. This result is then saved as a-constant in the compiled code. It can be a type, in which case it is-used like any other type, or it can be a value, in which case it can be-used as any other value, including as an index in types.--Type providers are still an experimental extension. To enable the-extension, use the ``%language`` directive:--.. code-block:: idris--    %language TypeProviders--A provider ``p`` for some type ``t`` is simply an expression of type-``IO (Provider t)``. The ``%provide`` directive causes the type checker-to execute the action and bind the result to a name. This is perhaps-best illustrated with a simple example. The type provider ``fromFile``-reads a text file. If the file consists of the string ``Int``, then the-type ``Int`` will be provided. Otherwise, it will provide the type-``Nat``.--.. code-block:: idris--    strToType : String -> Type-    strToType "Int" = Int-    strToType _ = Nat--    fromFile : String -> IO (Provider Type)-    fromFile fname = do Right str <- readFile fname-		          | Left err => pure (Provide Void)-		        pure (Provide (strToType (trim str)))--We then use the ``%provide`` directive:--.. code-block:: idris--    %provide (T1 : Type) with fromFile "theType"--    foo : T1-    foo = 2--If the file named ``theType`` consists of the word ``Int``, then ``foo``-will be an ``Int``. Otherwise, it will be a ``Nat``. When Idris-encounters the directive, it first checks that the provider expression-``fromFile theType`` has type ``IO (Provider Type)``. Next, it executes-the provider. If the result is ``Provide t``, then ``T1`` is defined as-``t``. Otherwise, the result is an error.--Our datatype ``Provider t`` has the following definition:--.. code-block:: idris--    data Provider a = Error String-                    | Provide a--We have already seen the ``Provide`` constructor. The ``Error``-constructor allows type providers to return useful error messages. The-example in this section was purposefully simple. More complex type-provider implementations, including a statically-checked SQLite binding,-are available in an external collection [1]_.--C Target-========--The default target of Idris is C. Compiling via:--::--    $ idris hello.idr -o hello--is equivalent to:--::--    $ idris --codegen C hello.idr -o hello--When the command above is used, a temporary C source is generated, which-is then compiled into an executable named ``hello``.--In order to view the generated C code, compile via:--::--    $ idris hello.idr -S -o hello.c--To turn optimisations on, use the ``%flag C`` pragma within the code, as-is shown below:--.. code-block:: idris--    module Main-    %flag C "-O3"--    factorial : Int -> Int-    factorial 0 = 1-    factorial n = n * (factorial (n-1))--    main : IO ()-    main = do-         putStrLn $ show $ factorial 3--To compile the generated C with debugging information e.g. to use-``gdb`` to debug segmentation faults in Idris programs, use the-``%flag C`` pragma to include debugging symbols, as is shown below:--.. code-block:: idris--    %flag C "-g"--JavaScript Target-=================--Idris is capable of producing *JavaScript* code that can be run in a-browser as well as in the *NodeJS* environment or alike. One can use the-FFI to communicate with the *JavaScript* ecosystem.--Code Generation------------------Code generation is split into two separate targets. To generate code-that is tailored for running in the browser issue the following command:--::--    $ idris --codegen javascript hello.idr -o hello.js--The resulting file can be embedded into your HTML just like any other-*JavaScript* code.--Generating code for *NodeJS* is slightly different. Idris outputs a-*JavaScript* file that can be directly executed via ``node``.--::--    $ idris --codegen node hello.idr -o hello-    $ ./hello-    Hello world--Take into consideration that the *JavaScript* code generator is using-``console.log`` to write text to ``stdout``, this means that it will-automatically add a newline to the end of each string. This behaviour-does not show up in the *NodeJS* code generator.--Using the FFI----------------To write a useful application we need to communicate with the outside-world. Maybe we want to manipulate the DOM or send an Ajax request. For-this task we can use the FFI. Since most *JavaScript* APIs demand-callbacks we need to extend the FFI so we can pass functions as-arguments.--The *JavaScript* FFI works a little bit differently than the regular-FFI. It uses positional arguments to directly insert our arguments into-a piece of *JavaScript* code.--One could use the primitive addition of *JavaScript* like so:--.. code-block:: idris--    module Main--    primPlus : Int -> Int -> IO Int-    primPlus a b = mkForeign (FFun "%0 + %1" [FInt, FInt] FInt) a b--    main : IO ()-    main = do-      a <- primPlus 1 1-      b <- primPlus 1 2-      print (a, b)--Notice that the ``%n`` notation qualifies the position of the ``n``-th-argument given to our foreign function starting from 0. When you need a-percent sign rather than a position simply use ``%%`` instead.--Passing functions to a foreign function is very similar. Let’s assume-that we want to call the following function from the *JavaScript* world:--.. code-block:: idris--    function twice(f, x) {-      return f(f(x));-    }--We obviously need to pass a function ``f`` here (we can infer it from-the way we use ``f`` in ``twice``, it would be more obvious if-*JavaScript* had types).--The *JavaScript* FFI is able to understand functions as arguments when-you give it something of type ``FFunction``. The following example code-calls ``twice`` in *JavaScript* and returns the result to our Idris-program:--.. code-block:: idris--    module Main--    twice : (Int -> Int) -> Int -> IO Int-    twice f x = mkForeign (-      FFun "twice(%0,%1)" [FFunction FInt FInt, FInt] FInt-    ) f x--    main : IO ()-    main = do-      a <- twice (+1) 1-      print a--The program outputs ``3``, just like we expected.--Including external *JavaScript* files----------------------------------------Whenever one is working with *JavaScript* one might want to include-external libraries or just some functions that she or he wants to call-via FFI which are stored in external files. The *JavaScript* and-*NodeJS* code generators understand the ``%include`` directive. Keep in-mind that *JavaScript* and *NodeJS* are handled as different code-generators, therefore you will have to state which one you want to-target. This means that you can include different files for *JavaScript*-and *NodeJS* in the same Idris source file.--So whenever you want to add an external *JavaScript* file you can do-this like so:--For *NodeJS*:--.. code-block:: idris--      %include Node "path/to/external.js"--And for use in the browser:--.. code-block:: idris--      %include JavaScript "path/to/external.js"--The given files will be added to the top of the generated code.-For library packages you can also use the ipkg objs option to include the-js file in the installation, and use:--.. code-block:: idris--      %include Node "package/external.js"--The *JavaScript* and *NodeJS* backends of Idris will also lookup for the file-on that location.--Including *NodeJS* modules-----------------------------The *NodeJS* code generator can also include modules with the ``%lib``-directive.--.. code-block:: idris--      %lib Node "fs"--This directive compiles into the following *JavaScript*--.. code-block:: javascript--      var fs = require("fs");--Shrinking down generated *JavaScript*----------------------------------------Idris can produce very big chunks of *JavaScript* code. However, the-generated code can be minified using the ``closure-compiler`` from-Google. Any other minifier is also suitable but ``closure-compiler``-offers advanced compilation that does some aggressive inlining and code-elimination. Idris can take full advantage of this compilation mode-and it’s highly recommended to use it when shipping a *JavaScript*-application written in Idris.--Cumulativity-============--Since values can appear in types and *vice versa*, it is natural that-types themselves have types. For example:--::--    *universe> :t Nat-    Nat : Type-    *universe> :t Vect-    Vect : Nat -> Type -> Type--But what about the type of ``Type``? If we ask Idris it reports:--::--    *universe> :t Type-    Type : Type 1--If ``Type`` were its own type, it would lead to an inconsistency due to-`Girard’s paradox <http://www.cs.cmu.edu/afs/cs.cmu.edu/user/kw/www/scans/girard72thesis.pdf>`_,-so internally there is a *hierarchy* of types (or *universes*):--.. code-block:: idris--    Type : Type 1 : Type 2 : Type 3 : ...--Universes are *cumulative*, that is, if ``x : Type n`` we can also have-that ``x : Type m``, as long as ``n < m``. The typechecker generates-such universe constraints and reports an error if any inconsistencies-are found. Ordinarily, a programmer does not need to worry about this,-but it does prevent (contrived) programs such as the following:--.. code-block:: idris--    myid : (a : Type) -> a -> a-    myid _ x = x--    idid :  (a : Type) -> a -> a-    idid = myid _ myid--The application of ``myid`` to itself leads to a cycle in the universe-hierarchy — ``myid``\ ’s first argument is a ``Type``, which cannot be-at a lower level than required if it is applied to itself.--.. [1]-   https://github.com/david-christiansen/idris-type-providers
− docs/tutorial/modules.rst 
@@ -1,274 +0,0 @@-.. _sect-namespaces:--**********************-Modules and Namespaces-**********************--An Idris program consists of a collection of modules. Each module-includes an optional ``module`` declaration giving the name of the-module, a list of ``import`` statements giving the other modules which-are to be imported, and a collection of declarations and definitions of-types, interfaces and functions. For example, the listing below gives a-module which defines a binary tree type ``BTree`` (in a file-``Btree.idr``):--.. code-block:: idris--    module Btree--    public export-    data BTree a = Leaf-                 | Node (BTree a) a (BTree a)--    export-    insert : Ord a => a -> BTree a -> BTree a-    insert x Leaf = Node Leaf x Leaf-    insert x (Node l v r) = if (x < v) then (Node (insert x l) v r)-                                       else (Node l v (insert x r))--    export-    toList : BTree a -> List a-    toList Leaf = []-    toList (Node l v r) = Btree.toList l ++ (v :: Btree.toList r)--    export-    toTree : Ord a => List a -> BTree a-    toTree [] = Leaf-    toTree (x :: xs) = insert x (toTree xs)--The modifiers ``export`` and ``public export`` say which names are visible-from other modules. These are explained further below.--Then, this gives a main program (in a file-``bmain.idr``) which uses the ``Btree`` module to sort a list:--.. code-block:: idris--    module Main--    import Btree--    main : IO ()-    main = do let t = toTree [1,8,2,7,9,3]-              print (Btree.toList t)--The same names can be defined in multiple modules: names are *qualified* with-the name of the module. The names defined in the ``Btree`` module are, in full:--+ ``Btree.BTree``-+ ``Btree.Leaf``-+ ``Btree.Node``-+ ``Btree.insert``-+ ``Btree.toList``-+ ``Btree.toTree``--If names are otherwise unambiguous, there is no need to give the fully-qualified name. Names can be disambiguated either by giving an explicit-qualification, or according to their type.--There is no formal link between the module name and its filename,-although it is generally advisable to use the same name for each. An-``import`` statement refers to a filename, using dots to separate-directories. For example, ``import foo.bar`` would import the file-``foo/bar.idr``, which would conventionally have the module declaration-``module foo.bar``. The only requirement for module names is that the-main module, with the ``main`` function, must be called-``Main`` — although its filename need not be ``Main.idr``.--Export Modifiers-================--Idris allows for fine-grained control over the visibility of a-module's contents. By default, all names defined in a module are kept-private.  This aides in specification of a minimal interface and for-internal details to be left hidden. Idris allows for functions,-types, and interfaces to be marked as: ``private``, ``export``, or-``public export``. Their general meaning is as follows:--- ``private`` meaning that it's not exported at all. This is the default.--- ``export`` meaning that its top level type is exported.--- ``public export`` meaning that the entire definition is exported.--A further restriction in modifying the visibility is that definitions-must not refer to anything within a lower level of visibility. For-example, ``public export`` definitions cannot use private names, and-``export`` types cannot use private names. This is to prevent private-names leaking into a module's interface.--Meaning for Functions------------------------- ``export`` the type is exported--- ``public export`` the type and definition are exported, and the-  definition can be used after it is imported. In other words, the-  definition itself is considered part of the module's interface. The-  long name ``public export`` is intended to make you think twice-  about doing this.--.. note::--   Type synonyms in Idris are created by writing a function. When-   setting the visibility for a module, it might be a good idea to-   ``public export`` all type synonyms if they are to be used outside-   the module. Otherwise, Idris won't know what the synonym is a-   synonym for.--Since ``public export`` means that a function's definition is exported,-this effectively makes the function definition part of the module's API.-Therefore, it's generally a good idea to avoid using ``public export`` for-functions unless you really mean to export the full definition.--Meaning for Data Types-------------------------For data types, the meanings are:--- ``export`` the type constructor is exported--- ``public export`` the type constructor and data constructors are exported---Meaning for Interfaces-------------------------For interfaces, the meanings are:--- ``export`` the interface name is exported--- ``public export`` the interface name, method names and default-  definitions are exported--``%access`` Directive-------------------------The default export mode can be changed with the ``%access``-directive, for example:--.. code-block:: idris--    module Btree--    %access export--    public export-    data BTree a = Leaf-                 | Node (BTree a) a (BTree a)--    insert : Ord a => a -> BTree a -> BTree a-    insert x Leaf = Node Leaf x Leaf-    insert x (Node l v r) = if (x < v) then (Node (insert x l) v r)-                                       else (Node l v (insert x r))--    toList : BTree a -> List a-    toList Leaf = []-    toList (Node l v r) = Btree.toList l ++ (v :: Btree.toList r)--    toTree : Ord a => List a -> BTree a-    toTree [] = Leaf-    toTree (x :: xs) = insert x (toTree xs)--In this case, any function with no access modifier will be exported as-``export``, rather than left ``private``.--Propagating Inner Module API's----------------------------------Additionally, a module can re-export a module it has imported, by using-the ``public`` modifier on an ``import``. For example:--.. code-block:: idris--    module A--    import B-    import public C--The module ``A`` will export the name ``a``, as well as any public or-abstract names in module ``C``, but will not re-export anything from-module ``B``.--Explicit Namespaces-===================--Defining a module also defines a namespace implicitly. However,-namespaces can also be given *explicitly*. This is most useful if you-wish to overload names within the same module:--.. code-block:: idris--    module Foo--    namespace x-      test : Int -> Int-      test x = x * 2--    namespace y-      test : String -> String-      test x = x ++ x--This (admittedly contrived) module defines two functions with fully-qualified names ``Foo.x.test`` and ``Foo.y.test``, which can be-disambiguated by their types:--::--    *Foo> test 3-    6 : Int-    *Foo> test "foo"-    "foofoo" : String--Parameterised blocks-====================--Groups of functions can be parameterised over a number of arguments-using a ``parameters`` declaration, for example:--.. code-block:: idris--    parameters (x : Nat, y : Nat)-      addAll : Nat -> Nat-      addAll z = x + y + z--The effect of a ``parameters`` block is to add the declared parameters-to every function, type and data constructor within the-block. Specifically, adding the parameters to the front of the-argument list. Outside the block, the parameters must be given-explicitly. The ``addAll`` function, when called from the REPL, will-thus have the following type signature.--::--    *params> :t addAll-    addAll : Nat -> Nat -> Nat -> Nat--and the following definition.--.. code-block:: idris--    addAll : (x : Nat) -> (y : Nat) -> (z : Nat) -> Nat-    addAll x y z = x + y + z--Parameters blocks can be nested, and can also include data declarations,-in which case the parameters are added explicitly to all type and data-constructors. They may also be dependent types with implicit arguments:--.. code-block:: idris--    parameters (y : Nat, xs : Vect x a)-      data Vects : Type -> Type where-        MkVects : Vect y a -> Vects a--      append : Vects a -> Vect (x + y) a-      append (MkVects ys) = xs ++ ys--To use ``Vects`` or ``append`` outside the block, we must also give the-``xs`` and ``y`` arguments. Here, we can use placeholders for the values-which can be inferred by the type checker:--::--    *params> show (append _ _ (MkVects _ [1,2,3] [4,5,6]))-    "[1, 2, 3, 4, 5, 6]" : String
− docs/tutorial/packages.rst 
@@ -1,185 +0,0 @@-.. _sect-packages:--********-Packages-********--Idris includes a simple build system for building packages and executables-from a named package description file. These files can be used with the-Idris compiler to manage the development process.--Package Descriptions-====================--A package description includes the following:--+ A header, consisting of the keyword ``package`` followed by a package-  name. Package names can be any valid Idris identifier. The iPKG-  format also takes a quoted version that accepts any valid filename.--+ Fields describing package contents, ``<field> = <value>``.--At least one field must be the modules field, where the value is a-comma separated list of modules. For example, given an idris package-``maths`` that has modules ``Maths.idr``, ``Maths.NumOps.idr``,-``Maths.BinOps.idr``, and ``Maths.HexOps.idr``, the corresponding-package file would be:--::--    package maths--    modules = Maths-            , Maths.NumOps-            , Maths.BinOps-            , Maths.HexOps---Other examples of package files can be found in the ``libs`` directory-of the main Idris repository, and in `third-party libraries-<https://github.com/idris-lang/Idris-dev/wiki/Libraries>`_.---Using Package files-===================--Idris itself is aware about packages, and special commands are-available to help with, for example, building packages, installing-packages, and cleaning packages.  For instance, given the ``maths``-package from earlier we can use Idris as follows:--+ ``idris --build maths.ipkg`` will build all modules in the package--+ ``idris --install maths.ipkg`` will install the package, making it-  accessible by other Idris libraries and programs.--+ ``idris --clean maths.ipkg`` will delete all intermediate code and-  executable files generated when building.--Once the maths package has been installed, the command line option-``--package maths`` makes it accessible (abbreviated to ``-p maths``).-For example:--::--    idris -p maths Main.idr---Testing Idris Packages-======================--The integrated build system includes a simple testing framework.-This framework collects functions listed in the ``ipkg`` file under ``tests``.-All test functions must return ``IO ()``.--When you enter ``idris --testpkg yourmodule.ipkg``,-the build system creates a temporary file in a fresh environment on your machine-by listing the ``tests`` functions under a single ``main`` function.-It compiles this temporary file to an executable and then executes it.--The tests themselves are responsible for reporting their success or failure.-Test functions commonly use ``putStrLn`` to report test results.-The test framework does not impose any standards for reporting and consequently-does not aggregate test results.--For example, lets take the following list of functions that are defined in a-module called ``NumOps`` for a sample package ``maths``:--.. name: Math/NumOps.idr-.. code-block:: idris--    module Maths.NumOps--    %access export -- to make functions under test visible--    double : Num a => a -> a-    double a = a + a--    triple : Num a => a -> a-    triple a = a + double a---A simple test module, with a qualified name of ``Test.NumOps`` can be declared as:--.. name: Math/TestOps.idr-.. code-block:: idris--    module Test.NumOps--    import Maths.NumOps--    %access export  -- to make the test functions visible--    assertEq : Eq a => (given : a) -> (expected : a) -> IO ()-    assertEq g e = if g == e-        then putStrLn "Test Passed"-        else putStrLn "Test Failed"--    assertNotEq : Eq a => (given : a) -> (expected : a) -> IO ()-    assertNotEq g e = if not (g == e)-        then putStrLn "Test Passed"-        else putStrLn "Test Failed"--    testDouble : IO ()-    testDouble = assertEq (double 2) 4--    testTriple : IO ()-    testTriple = assertNotEq (triple 2) 5---The functions ``assertEq`` and ``assertNotEq`` are used to run expected passing,-and failing, equality tests. The actual tests are ``testDouble`` and ``testTriple``,-and are declared in the ``maths.ipkg`` file as follows:--::--    package maths--    modules = Maths.NumOps-            , Test.NumOps--    tests = Test.NumOps.testDouble-          , Test.NumOps.testTriple---The testing framework can then be invoked using ``idris --testpkg maths.ipkg``:--::--    > idris --testpkg maths.ipkg-    Type checking ./Maths/NumOps.idr-    Type checking ./Test/NumOps.idr-    Type checking /var/folders/63/np5g0d5j54x1s0z12rf41wxm0000gp/T/idristests144128232716531729.idr-    Test Passed-    Test Passed--Note how both tests have reported success by printing ``Test Passed``-as we arranged for with the ``assertEq`` and ``assertNoEq`` functions.--Package Dependencies Using Atom-===============================--If you are using the Atom editor and have a dependency on another package,-corresponding to for instance ``import Lightyear`` or ``import Pruviloj``,-you need to let Atom know that it should be loaded. The easiest way to-accomplish that is with a .ipkg file. The general contents of an ipkg file-will be described in the next section of the tutorial, but for now here is-a simple recipe for this trivial case:--- Create a folder myProject.--- Add a file myProject.ipkg containing just a couple of lines:--.. code-block:: idris--    package myProject--    pkgs = pruviloj, lightyear--- In Atom, use the File menu to Open Folder myProject.--More information-================--More details, including a complete listing of available fields, can be-found in the reference manual in :ref:`ref-sect-packages`.
− docs/tutorial/provisional.rst 
@@ -1,277 +0,0 @@-.. _sect-provisional:--***********************-Provisional Definitions-***********************--Sometimes when programming with dependent types, the type required by-the type checker and the type of the program we have written will be-different (in that they do not have the same normal form), but-nevertheless provably equal. For example, recall the ``parity``-function:--.. code-block:: idris--    data Parity : Nat -> Type where-       Even : Parity (n + n)-       Odd  : Parity (S (n + n))--We’d like to implement this as follows:--.. code-block:: idris--    parity : (n:Nat) -> Parity n-    parity Z     = Even {n=Z}-    parity (S Z) = Odd {n=Z}-    parity (S (S k)) with (parity k)-      parity (S (S (j + j)))     | Even = Even {n=S j}-      parity (S (S (S (j + j)))) | Odd  = Odd {n=S j}--This simply states that zero is even, one is odd, and recursively, the-parity of ``k+2`` is the same as the parity of ``k``. Explicitly marking-the value of ``n`` is even and odd is necessary to help type inference.-Unfortunately, the type checker rejects this:--::--    viewsbroken.idr:12:10:When elaborating right hand side of ViewsBroken.parity:-    Type mismatch between -        Parity (plus (S j) (S j))-    and-        Parity (S (S (plus j j)))--    Specifically:-        Type mismatch between-            plus (S j) (S j)-        and-            S (S (plus j j))--The type checker is telling us that ``(j+1)+(j+1)`` and ``2+j+j`` do not-normalise to the same value. This is because ``plus`` is defined by-recursion on its first argument, and in the second value, there is a-successor symbol on the second argument, so this will not help with-reduction. These values are obviously equal — how can we rewrite the-program to fix this problem?--Provisional definitions-=======================--*Provisional definitions* help with this problem by allowing us to defer-the proof details until a later point. There are two main reasons why-they are useful.---  When *prototyping*, it is useful to be able to test programs before-   finishing all the details of proofs.---  When *reading* a program, it is often much clearer to defer the proof-   details so that they do not distract the reader from the underlying-   algorithm.--Provisional definitions are written in the same way as ordinary-definitions, except that they introduce the right hand side with a-``?=`` rather than ``=``. We define ``parity`` as follows:--.. code-block:: idris--    parity : (n:Nat) -> Parity n-    parity Z = Even {n=Z}-    parity (S Z) = Odd {n=Z}-    parity (S (S k)) with (parity k)-      parity (S (S (j + j))) | Even ?= Even {n=S j}-      parity (S (S (S (j + j)))) | Odd ?= Odd {n=S j}--When written in this form, instead of reporting a type error, Idris-will insert a hole standing for a theorem which will correct the-type error. Idris tells us we have two proof obligations, with names-generated from the module and function names:--.. code-block:: idris--    *views> :m-    Global holes:-            [views.parity_lemma_2,views.parity_lemma_1]--The first of these has the following type:--.. code-block:: idris--    *views> :p views.parity_lemma_1--    ---------------------------------- (views.parity_lemma_1) ---------    {hole0} : (j : Nat) -> (Parity (plus (S j) (S j))) -> Parity (S (S (plus j j)))--    -views.parity_lemma_1>--The two arguments are ``j``, the variable in scope from the pattern-match, and ``value``, which is the value we gave in the right hand side-of the provisional definition. Our goal is to rewrite the type so that-we can use this value. We can achieve this using the following theorem-from the prelude:--.. code-block:: idris--    plusSuccRightSucc : (left : Nat) -> (right : Nat) ->-      S (left + right) = left + (S right)--We need to use ``compute`` again to unfold the definition of ``plus``:--.. code-block:: idris--    -views.parity_lemma_1> compute---    ---------------------------------- (views.parity_lemma_1) ---------    {hole0} : (j : Nat) -> (Parity (S (plus j (S j)))) -> Parity (S (S (plus j j)))--After applying ``intros`` we have:--.. code-block:: idris--    -views.parity_lemma_1> intros--      j : Nat-      value : Parity (S (plus j (S j)))-    ---------------------------------- (views.parity_lemma_1) ---------    {hole2} : Parity (S (S (plus j j)))--Then we apply the ``plusSuccRightSucc`` rewrite rule, symmetrically, to-``j`` and ``j``, giving:--.. code-block:: idris--    -views.parity_lemma_1> rewrite sym (plusSuccRightSucc j j)--      j : Nat-      value : Parity (S (plus j (S j)))-    ---------------------------------- (views.parity_lemma_1) ---------    {hole3} : Parity (S (plus j (S j)))--``sym`` is a function, defined in the library, which reverses the order-of the rewrite:--.. code-block:: idris--    sym : l = r -> r = l-    sym Refl = Refl--We can complete this proof using the ``trivial`` tactic, which finds-``value`` in the premises. The proof of the second lemma proceeds in-exactly the same way.--We can now test the ``natToBin`` function from Section :ref:`sect-nattobin`-at the prompt. The number 42 is 101010 in binary. The binary digits are-reversed:--.. code-block:: idris--    *views> show (natToBin 42)-    "[False, True, False, True, False, True]" : String--Suspension of Disbelief-=======================--Idris requires that proofs be complete before compiling programs-(although evaluation at the prompt is possible without proof details).-Sometimes, especially when prototyping, it is easier not to have to do-this. It might even be beneficial to test programs before attempting to-prove things about them — if testing finds an error, you know you had-better not waste your time proving something!--Therefore, Idris provides a built-in coercion function, which allows-you to use a value of the incorrect types:--.. code-block:: idris--    believe_me : a -> b--Obviously, this should be used with extreme caution. It is useful when-prototyping, and can also be appropriate when asserting properties of-external code (perhaps in an external C library). The “proof” of-``views.parity_lemma_1`` using this is:--.. code-block:: idris--    views.parity_lemma_2 = proof {-        intro;-        intro;-        exact believe_me value;-    }--The ``exact`` tactic allows us to provide an exact value for the proof.-In this case, we assert that the value we gave was correct.--Example: Binary numbers-=======================--Previously, we implemented conversion to binary numbers using the-``Parity`` view. Here, we show how to use the same view to implement a-verified conversion to binary. We begin by indexing binary numbers over-their ``Nat`` equivalent. This is a common pattern, linking a-representation (in this case ``Binary``) with a meaning (in this case-``Nat``):--.. code-block:: idris--    data Binary : Nat -> Type where-       BEnd : Binary Z-       BO : Binary n -> Binary (n + n)-       BI : Binary n -> Binary (S (n + n))--``BO`` and ``BI`` take a binary number as an argument and effectively-shift it one bit left, adding either a zero or one as the new least-significant bit. The index, ``n + n`` or ``S (n + n)`` states the result-that this left shift then add will have to the meaning of the number.-This will result in a representation with the least significant bit at-the front.--Now a function which converts a Nat to binary will state, in the type,-that the resulting binary number is a faithful representation of the-original Nat:--.. code-block:: idris--    natToBin : (n:Nat) -> Binary n--The ``Parity`` view makes the definition fairly simple — halving the-number is effectively a right shift after all — although we need to use-a provisional definition in the Odd case:--.. code-block:: idris--    natToBin : (n:Nat) -> Binary n-    natToBin Z = BEnd-    natToBin (S k) with (parity k)-       natToBin (S (j + j))     | Even  = BI (natToBin j)-       natToBin (S (S (j + j))) | Odd  ?= BO (natToBin (S j))--The problem with the Odd case is the same as in the definition of-``parity``, and the proof proceeds in the same way:--.. code-block:: idris--    natToBin_lemma_1 = proof {-        intro;-        intro;-        rewrite sym (plusSuccRightSucc j j);-        trivial;-    }--To finish, we’ll implement a main program which reads an integer from-the user and outputs it in binary.--.. code-block:: idris--    main : IO ()-    main = do putStr "Enter a number: "-              x <- getLine-              print (natToBin (fromInteger (cast x)))--For this to work, of course, we need a ``Show`` implementation for-``Binary n``:--.. code-block:: idris--    Show (Binary n) where-        show (BO x) = show x ++ "0"-        show (BI x) = show x ++ "1"-        show BEnd = ""
− docs/tutorial/starting.rst 
@@ -1,93 +0,0 @@-.. _sect-starting:--***************-Getting Started-***************--Prerequisites-=============--Before installing Idris, you will need to make sure you have all-of the necessary libraries and tools. You will need:--- A fairly recent version of `GHC <https://www.haskell.org/ghc/>`_. The-  earliest version we currently test with is 7.10.3.--- The *GNU Multiple Precision Arithmetic Library* (GMP) is available  from MacPorts/Homebrew and all major Linux distributions.--Downloading and Installing-==========================--The easiest way to install Idris, if you have all of the-prerequisites, is to type:--::--    cabal update; cabal install idris--This will install the latest version released on Hackage, along with-any dependencies. If, however, you would like the most up to date-development version you can find it, as well as build instructions, on-GitHub at: https://github.com/idris-lang/Idris-dev.--If you haven't previously installed anything using Cabal, then Idris-may not be on your path. Should the Idris executable not be found-please ensure that you have added ``~/.cabal/bin`` to your ``$PATH``-environment variable. Mac OS X users may find they need to add-``~/Library/Haskell/bin`` instead, and Windows users will typically-find that Cabal installs programs in ``%HOME%\AppData\Roaming\cabal\bin``.--To check that installation has succeeded, and to write your first-Idris program, create a file called ``hello.idr`` containing the-following text:--.. code-block:: idris--    module Main--    main : IO ()-    main = putStrLn "Hello world"--If you are familiar with Haskell, it should be fairly clear what the-program is doing and how it works, but if not, we will explain the-details later. You can compile the program to an executable by-entering ``idris hello.idr -o hello`` at the shell prompt. This will-create an executable called ``hello``, which you can run:--::--    $ idris hello.idr -o hello-    $ ./hello-    Hello world--Please note that the dollar sign ``$`` indicates the shell prompt!-Some useful options to the Idris command are:--- ``-o prog`` to compile to an executable called ``prog``.--- ``--check`` type check the file and its dependencies without starting the interactive environment.--- ``--package pkg`` add package as dependency, e.g. ``--package contrib`` to make use of the contrib package.--- ``--help`` display usage summary and command line options.--The Interactive Environment-===========================--Entering ``idris`` at the shell prompt starts up the interactive-environment. You should see something like the following:--.. literalinclude:: ../listing/idris-prompt-start.txt--This gives a ``ghci`` style interface which allows evaluation of, as-well as type checking of, expressions; theorem proving, compilation;-editing; and various other operations. The command ``:?`` gives a list-of supported commands. Below, we see an example run in-which ``hello.idr`` is loaded, the type of ``main`` is checked and-then the program is compiled to the executable ``hello``. Type-checking a file, if successful, creates a bytecode version of the file-(in this case ``hello.ibc``) to speed up loading in future. The-bytecode is regenerated if the source file changes.--.. _run1:-.. literalinclude:: ../listing/idris-prompt-helloworld.txt
− docs/tutorial/syntax.rst 
@@ -1,211 +0,0 @@-.. _sect-syntax:--*****************-Syntax Extensions-*****************--Idris supports the implementation of *Embedded Domain Specific-Languages* (EDSLs) in several ways [1]_. One way, as we have already-seen, is through extending ``do`` notation. Another important way is-to allow extension of the core syntax. In this section we describe two-ways of extending the syntax: ``syntax`` rules and ``dsl`` notation.--``syntax`` rules-================--We have seen ``if...then...else`` expressions, but these are not built-in. Instead, we can define a function in the prelude as follows (we-have already seen this function in Section :ref:`sect-lazy`):--.. code-block:: idris--    ifThenElse : (x:Bool) -> Lazy a -> Lazy a -> a;-    ifThenElse True  t e = t;-    ifThenElse False t e = e;--and then extend the core syntax with a ``syntax`` declaration:--.. code-block:: idris--    syntax if [test] then [t] else [e] = ifThenElse test t e;--The left hand side of a ``syntax`` declaration describes the syntax-rule, and the right hand side describes its expansion. The syntax rule-itself consists of:---  **Keywords** — here, ``if``, ``then`` and ``else``, which must be-   valid identifiers.---  **Non-terminals** — included in square brackets, ``[test]``, ``[t]``-   and ``[e]`` here, which stand for arbitrary expressions. To avoid-   parsing ambiguities, these expressions cannot use syntax extensions-   at the top level (though they can be used in parentheses).---  **Names** — included in braces, which stand for names which may be-   bound on the right hand side.---  **Symbols** — included in quotations marks, e.g. ``":="``. This can-   also be used to include reserved words in syntax rules, such as-   ``"let"`` or ``"in"``.--The limitations on the form of a syntax rule are that it must include-at least one symbol or keyword, and there must be no repeated-variables standing for non-terminals. Any expression can be used, but-if there are two non-terminals in a row in a rule, only simple-expressions may be used (that is, variables, constants, or bracketed-expressions). Rules can use previously defined rules, but may not be-recursive. The following syntax extensions would therefore be valid:--.. code-block:: idris--    syntax [var] ":=" [val]                = Assign var val;-    syntax [test] "?" [t] ":" [e]          = if test then t else e;-    syntax select [x] from [t] "where" [w] = SelectWhere x t w;-    syntax select [x] from [t]             = Select x t;--Syntax macros can be further restricted to apply only in patterns (i.e.-only on the left hand side of a pattern match clause) or only in terms-(i.e. everywhere but the left hand side of a pattern match clause) by-being marked as ``pattern`` or ``term`` syntax rules. For example, we-might define an interval as follows, with a static check that the lower-bound is below the upper bound using ``so``:--.. code-block:: idris--    data Interval : Type where-       MkInterval : (lower : Double) -> (upper : Double) ->-                    So (lower < upper) -> Interval--We can define a syntax which, in patterns, always matches ``Oh`` for-the proof argument, and in terms requires a proof term to be provided:--.. code-block:: idris--    pattern syntax "[" [x] "..." [y] "]" = MkInterval x y Oh-    term    syntax "[" [x] "..." [y] "]" = MkInterval x y ?bounds_lemma--In terms, the syntax ``[x...y]`` will generate a proof obligation-``bounds_lemma`` (possibly renamed).--Finally, syntax rules may be used to introduce alternative binding-forms. For example, a ``for`` loop binds a variable on each iteration:--.. code-block:: idris--    syntax for {x} "in" [xs] ":" [body] = forLoop xs (\x => body)--    main : IO ()-    main = do for x in [1..10]:-                  putStrLn ("Number " ++ show x)-              putStrLn "Done!"--Note that we have used the ``{x}`` form to state that ``x`` represents-a bound variable, substituted on the right hand side. We have also put-``in`` in quotation marks since it is already a reserved word.--``dsl`` notation-================--The well-typed interpreter in Section :ref:`sect-interp` is a simple-example of a common programming pattern with dependent types. Namely:-describe an *object language* and its type system with dependent types-to guarantee that only well-typed programs can be represented, then-program using that representation. Using this approach we can, for-example, write programs for serialising binary data [2]_ or running-concurrent processes safely [3]_.--Unfortunately, the form of object language programs makes it rather-hard to program this way in practice. Recall the factorial program in-``Expr`` for example:--.. code-block:: idris--    fact : Expr G (TyFun TyInt TyInt)-    fact = Lam (If (Op (==) (Var Stop) (Val 0))-                   (Val 1) (Op (*) (App fact (Op (-) (Var Stop) (Val 1)))-                                   (Var Stop)))--Since this is a particularly useful pattern, Idris provides syntax-overloading [1]_ to make it easier to program in such object-languages:--.. code-block:: idris--    mkLam : TTName -> Expr (t::g) t' -> Expr g (TyFun t t')-    mkLam _ body = Lam body--    dsl expr-        variable    = Var-        index_first = Stop-        index_next  = Pop-        lambda      = mkLam--A ``dsl`` block describes how each syntactic construct is represented-in an object language. Here, in the ``expr`` language, any variable is-translated to the ``Var`` constructor, using ``Pop`` and ``Stop`` to-construct the de Bruijn index (i.e., to count how many bindings since-the variable itself was bound); and any lambda is translated to a-``Lam`` constructor. The ``mkLam`` function simply ignores its first-argument, which is the name that the user chose for the variable. It-is also possible to overload ``let`` and dependent function syntax-(``pi``) in this way. We can now write ``fact`` as follows:--.. code-block:: idris--    fact : Expr G (TyFun TyInt TyInt)-    fact = expr (\x => If (Op (==) x (Val 0))-                          (Val 1) (Op (*) (app fact (Op (-) x (Val 1))) x))--In this new version, ``expr`` declares that the next expression will-be overloaded. We can take this further, using idiom brackets, by-declaring:--.. code-block:: idris--    (<*>) : (f : Lazy (Expr G (TyFun a t))) -> Expr G a -> Expr G t-    (<*>) f a = App f a--    pure : Expr G a -> Expr G a-    pure = id--Note that there is no need for these to be part of an implementation of-``Applicative``, since idiom bracket notation translates directly to-the names ``<*>`` and ``pure``, and ad-hoc type-directed overloading-is allowed. We can now say:--.. code-block:: idris--    fact : Expr G (TyFun TyInt TyInt)-    fact = expr (\x => If (Op (==) x (Val 0))-                          (Val 1) (Op (*) [| fact (Op (-) x (Val 1)) |] x))--With some more ad-hoc overloading and use of interfaces, and a new-syntax rule, we can even go as far as:--.. code-block:: idris--    syntax "IF" [x] "THEN" [t] "ELSE" [e] = If x t e--    fact : Expr G (TyFun TyInt TyInt)-    fact = expr (\x => IF x == 0 THEN 1 ELSE [| fact (x - 1) |] * x)---.. [1] Edwin Brady and Kevin Hammond. 2012. Resource-Safe systems-       programming with embedded domain specific languages. In-       Proceedings of the 14th international conference on Practical-       Aspects of Declarative Languages (PADL'12), Claudio Russo and-       Neng-Fa Zhou (Eds.). Springer-Verlag, Berlin, Heidelberg,-       242-257. DOI=10.1007/978-3-642-27694-1_18-       http://dx.doi.org/10.1007/978-3-642-27694-1_18--.. [2] Edwin C. Brady. 2011. IDRIS ---: systems programming meets full-       dependent types. In Proceedings of the 5th ACM workshop on-       Programming languages meets program verification (PLPV-       '11). ACM, New York, NY, USA,-       43-54. DOI=10.1145/1929529.1929536-       http://doi.acm.org/10.1145/1929529.1929536--.. [3] Edwin Brady and Kevin Hammond. 2010. Correct-by-Construction-       Concurrency: Using Dependent Types to Verify Implementations of-       Effectful Resource Usage Protocols. Fundam. Inf. 102, 2 (April-       2010), 145-176. http://dl.acm.org/citation.cfm?id=1883636
− docs/tutorial/theorems.rst 
@@ -1,430 +0,0 @@-.. _sect-theorems:--***************-Theorem Proving-***************--Equality-========--Idris allows propositional equalities to be declared, allowing theorems about-programs to be stated and proved. Equality is built in, but conceptually-has the following definition:--.. code-block:: idris--    data (=) : a -> b -> Type where-       Refl : x = x--Equalities can be proposed between any values of any types, but the only-way to construct a proof of equality is if values actually are equal.-For example:--.. code-block:: idris--    fiveIsFive : 5 = 5-    fiveIsFive = Refl--    twoPlusTwo : 2 + 2 = 4-    twoPlusTwo = Refl--.. _sect-empty:--The Empty Type-==============--There is an empty type, :math:`\bot`, which has no constructors. It is-therefore impossible to construct an element of the empty type, at least-without using a partially defined or general recursive function (see-Section :ref:`sect-totality` for more details). We can therefore use the-empty type to prove that something is impossible, for example zero is-never equal to a successor:--.. code-block:: idris--    disjoint : (n : Nat) -> Z = S n -> Void-    disjoint n p = replace {P = disjointTy} p ()-      where-        disjointTy : Nat -> Type-        disjointTy Z = ()-        disjointTy (S k) = Void--There is no need to worry too much about how this function works —-essentially, it applies the library function ``replace``, which uses an-equality proof to transform a predicate. Here we use it to transform a-value of a type which can exist, the empty tuple, to a value of a type-which can’t, by using a proof of something which can’t exist.--Once we have an element of the empty type, we can prove anything.-``void`` is defined in the library, to assist with proofs by-contradiction.--.. code-block:: idris--    void : Void -> a--Simple Theorems-===============--When type checking dependent types, the type itself gets *normalised*.-So imagine we want to prove the following theorem about the reduction-behaviour of ``plus``:--.. code-block:: idris--    plusReduces : (n:Nat) -> plus Z n = n--We’ve written down the statement of the theorem as a type, in just the-same way as we would write the type of a program. In fact there is no-real distinction between proofs and programs. A proof, as far as we are-concerned here, is merely a program with a precise enough type to-guarantee a particular property of interest.--We won’t go into details here, but the Curry-Howard correspondence [1]_-explains this relationship. The proof itself is trivial, because-``plus Z n`` normalises to ``n`` by the definition of ``plus``:--.. code-block:: idris--    plusReduces n = Refl--It is slightly harder if we try the arguments the other way, because-plus is defined by recursion on its first argument. The proof also works-by recursion on the first argument to ``plus``, namely ``n``.--.. code-block:: idris--    plusReducesZ : (n:Nat) -> n = plus n Z-    plusReducesZ Z = Refl-    plusReducesZ (S k) = cong (plusReducesZ k)--``cong`` is a function defined in the library which states that equality-respects function application:--.. code-block:: idris--    cong : {f : t -> u} -> a = b -> f a = f b--We can do the same for the reduction behaviour of plus on successors:--.. code-block:: idris--    plusReducesS : (n:Nat) -> (m:Nat) -> S (plus n m) = plus n (S m)-    plusReducesS Z m = Refl-    plusReducesS (S k) m = cong (plusReducesS k m)--Even for trivial theorems like these, the proofs are a little tricky to-construct in one go. When things get even slightly more complicated, it-becomes too much to think about to construct proofs in this “batch-mode”.--Idris provides interactive editing capabilities, which can help with-building proofs. For more details on building proofs interactively in-an editor, see :ref:`proofs-index`.--.. _sect-parity:--Theorems in Practice-====================--The need to prove theorems can arise naturally in practice. For example,-previously (:ref:`sec-views`) we implemented ``natToBin`` using a function-``parity``:--.. code-block:: idris--    parity : (n:Nat) -> Parity n--However, we didn't provide a definition for ``parity``. We might expect it-to look something like the following:--.. code-block:: idris--    parity : (n:Nat) -> Parity n-    parity Z     = Even {n=Z}-    parity (S Z) = Odd {n=Z}-    parity (S (S k)) with (parity k)-      parity (S (S (j + j)))     | Even = Even {n=S j}-      parity (S (S (S (j + j)))) | Odd  = Odd {n=S j}--Unfortunately, this fails with a type error:--::--    When checking right hand side of with block in views.parity with expected type-            Parity (S (S (j + j)))--    Type mismatch between-            Parity (S j + S j) (Type of Even)-    and-            Parity (S (S (plus j j))) (Expected type)--The problem is that normalising ``S j + S j``, in the type of ``Even``-doesn't result in what we need for the type of the right hand side of-``Parity``. We know that ``S (S (plus j j))`` is going to be equal to-``S j + S j``, but we need to explain it to Idris with a proof. We can-begin by adding some *holes* (see :ref:`sect-holes`) to the definition:--.. code-block:: idris--    parity : (n:Nat) -> Parity n-    parity Z     = Even {n=Z}-    parity (S Z) = Odd {n=Z}-    parity (S (S k)) with (parity k)-      parity (S (S (j + j)))     | Even = let result = Even {n=S j} in-                                              ?helpEven-      parity (S (S (S (j + j)))) | Odd  = let result = Odd {n=S j} in-                                              ?helpOdd--Checking the type of ``helpEven`` shows us what we need to prove for the-``Even`` case:--::--      j : Nat-      result : Parity (S (plus j (S j)))-    ---------------------------------------    helpEven : Parity (S (S (plus j j)))--We can therefore write a helper function to *rewrite* the type to the form-we need:--.. code-block:: idris--    helpEven : (j : Nat) -> Parity (S j + S j) -> Parity (S (S (plus j j)))-    helpEven j p = rewrite plusSuccRightSucc j j in p--The ``rewrite ... in`` syntax allows you to change the required type of an-expression by rewriting it according to an equality proof. Here, we have-used ``plusSuccRightSucc``, which has the following type:--.. code-block:: idris--    plusSuccRightSucc : (left : Nat) -> (right : Nat) -> S (left + right) = left + S right--We can see the effect of ``rewrite`` by replacing the right hand side of-``helpEven`` with a hole, and working step by step. Beginning with the following:--.. code-block:: idris--    helpEven : (j : Nat) -> Parity (S j + S j) -> Parity (S (S (plus j j)))-    helpEven j p = ?helpEven_rhs--We can look at the type of ``helpEven_rhs``:--.. code-block:: idris--      j : Nat-      p : Parity (S (plus j (S j)))-    ---------------------------------------    helpEven_rhs : Parity (S (S (plus j j)))--Then we can ``rewrite`` by applying ``plusSuccRightSucc j j``, which gives-an equation ``S (j + j) = j + S j``, thus replacing ``S (j + j)`` (or,-in this case, ``S (plus j j)`` since ``S (j + j)`` reduces to that) in the-type with ``j + S j``:--.. code-block:: idris--    helpEven : (j : Nat) -> Parity (S j + S j) -> Parity (S (S (plus j j)))-    helpEven j p = rewrite plusSuccRightSucc j j in ?helpEven_rhs--Checking the type of ``helpEven_rhs`` now shows what has happened, including-the type of the equation we just used (as the type of ``_rewrite_rule``):--.. code-block:: idris--      j : Nat-      p : Parity (S (plus j (S j)))-      _rewrite_rule : S (plus j j) = plus j (S j)-    ---------------------------------------    helpEven_rhs : Parity (S (plus j (S j)))--Using ``rewrite`` and another helper for the ``Odd`` case, we can complete-``parity`` as follows:--.. code-block:: idris--    helpEven : (j : Nat) -> Parity (S j + S j) -> Parity (S (S (plus j j)))-    helpEven j p = rewrite plusSuccRightSucc j j in p--    helpOdd : (j : Nat) -> Parity (S (S (j + S j))) -> Parity (S (S (S (j + j))))-    helpOdd j p = rewrite plusSuccRightSucc j j in p--    parity : (n:Nat) -> Parity n-    parity Z     = Even {n=Z}-    parity (S Z) = Odd {n=Z}-    parity (S (S k)) with (parity k)-      parity (S (S (j + j)))     | Even = helpEven j (Even {n = S j})-      parity (S (S (S (j + j)))) | Odd  = helpOdd j (Odd {n = S j})--Full details of ``rewrite`` are beyond the scope of this introductory tutorial,-but it is covered in the theorem proving tutorial (see :ref:`proofs-index`).--.. _sect-totality:--Totality Checking-=================--If we really want to trust our proofs, it is important that they are-defined by *total* functions — that is, a function which is defined for-all possible inputs and is guaranteed to terminate. Otherwise we could-construct an element of the empty type, from which we could prove-anything:--.. code-block:: idris--    -- making use of 'hd' being partially defined-    empty1 : Void-    empty1 = hd [] where-        hd : List a -> a-        hd (x :: xs) = x--    -- not terminating-    empty2 : Void-    empty2 = empty2--Internally, Idris checks every definition for totality, and we can check at-the prompt with the ``:total`` command. We see that neither of the above-definitions is total:--::--    *Theorems> :total empty1-    possibly not total due to: empty1#hd-        not total as there are missing cases-    *Theorems> :total empty2-    possibly not total due to recursive path empty2--Note the use of the word “possibly” — a totality check can, of course,-never be certain due to the undecidability of the halting problem. The-check is, therefore, conservative. It is also possible (and indeed-advisable, in the case of proofs) to mark functions as total so that it-will be a compile time error for the totality check to fail:--.. code-block:: idris--    total empty2 : Void-    empty2 = empty2--::--    Type checking ./theorems.idr-    theorems.idr:25:empty2 is possibly not total due to recursive path empty2--Reassuringly, our proof in Section :ref:`sect-empty` that the zero and-successor constructors are disjoint is total:--.. code-block:: idris--    *theorems> :total disjoint-    Total--The totality check is, necessarily, conservative. To be recorded as-total, a function ``f`` must:---  Cover all possible inputs---  Be *well-founded* — i.e. by the time a sequence of (possibly-   mutually) recursive calls reaches ``f`` again, it must be possible to-   show that one of its arguments has decreased.---  Not use any data types which are not *strictly positive*---  Not call any non-total functions--Directives and Compiler Flags for Totality---------------------------------------------By default, Idris allows all well-typed definitions, whether total or not.-However, it is desirable for functions to be total as far as possible, as this-provides a guarantee that they provide a result for all possible inputs, in-finite time. It is possible to make total functions a requirement, either:---  By using the ``--total`` compiler flag.---  By adding a ``%default total`` directive to a source file. All-   definitions after this will be required to be total, unless-   explicitly flagged as ``partial``.--All functions *after* a ``%default total`` declaration are required to-be total. Correspondingly, after a ``%default partial`` declaration, the-requirement is relaxed.--Finally, the compiler flag ``--warnpartial`` causes to print a warning-for any undeclared partial function.--Totality checking issues---------------------------Please note that the totality checker is not perfect! Firstly, it is-necessarily conservative due to the undecidability of the halting-problem, so many programs which *are* total will not be detected as-such. Secondly, the current implementation has had limited effort put-into it so far, so there may still be cases where it believes a function-is total which is not. Do not rely on it for your proofs yet!--Hints for totality---------------------In cases where you believe a program is total, but Idris does not agree, it is-possible to give hints to the checker to give more detail for a termination-argument. The checker works by ensuring that all chains of recursive calls-eventually lead to one of the arguments decreasing towards a base case, but-sometimes this is hard to spot. For example, the following definition cannot be-checked as ``total`` because the checker cannot decide that ``filter (< x) xs``-will always be smaller than ``(x :: xs)``:--.. code-block:: idris--    qsort : Ord a => List a -> List a-    qsort [] = []-    qsort (x :: xs)-       = qsort (filter (< x) xs) ++-          (x :: qsort (filter (>= x) xs))--The function ``assert_smaller``, defined in the prelude, is intended to-address this problem:--.. code-block:: idris--    assert_smaller : a -> a -> a-    assert_smaller x y = y--It simply evaluates to its second argument, but also asserts to the-totality checker that ``y`` is structurally smaller than ``x``. This can-be used to explain the reasoning for totality if the checker cannot work-it out itself. The above example can now be written as:--.. code-block:: idris--    total-    qsort : Ord a => List a -> List a-    qsort [] = []-    qsort (x :: xs)-       = qsort (assert_smaller (x :: xs) (filter (< x) xs)) ++-          (x :: qsort (assert_smaller (x :: xs) (filter (>= x) xs)))--The expression ``assert_smaller (x :: xs) (filter (<= x) xs)`` asserts-that the result of the filter will always be smaller than the pattern-``(x :: xs)``.--In more extreme cases, the function ``assert_total`` marks a-subexpression as always being total:--.. code-block:: idris--    assert_total : a -> a-    assert_total x = x--In general, this function should be avoided, but it can be very useful-when reasoning about primitives or externally defined functions (for-example from a C library) where totality can be shown by an external-argument.---.. [1] Timothy G. Griffin. 1989. A formulae-as-type notion of-       control. In Proceedings of the 17th ACM SIGPLAN-SIGACT-       symposium on Principles of programming languages (POPL-       '90). ACM, New York, NY, USA, 47-58. DOI=10.1145/96709.96714-       http://doi.acm.org/10.1145/96709.96714
− docs/tutorial/typesfuns.rst 
@@ -1,1350 +0,0 @@-.. _sect-typefuns:--*******************-Types and Functions-*******************--Primitive Types-===============--Idris defines several primitive types: ``Int``, ``Integer`` and-``Double`` for numeric operations, ``Char`` and ``String`` for text-manipulation, and ``Ptr`` which represents foreign pointers. There are-also several data types declared in the library, including ``Bool``,-with values ``True`` and ``False``. We can declare some constants with-these types. Enter the following into a file ``Prims.idr`` and load it-into the Idris interactive environment by typing ``idris Prims.idr``:--.. code-block:: idris--    module Prims--    x : Int-    x = 42--    foo : String-    foo = "Sausage machine"--    bar : Char-    bar = 'Z'--    quux : Bool-    quux = False--An Idris file consists of an optional module declaration (here-``module Prims``) followed by an optional list of imports and a-collection of declarations and definitions. In this example no imports-have been specified. However Idris programs can consist of several-modules and the definitions in each module each have their own-namespace. This is discussed further in Section-:ref:`sect-namespaces`. When writing Idris programs both the order in which-definitions are given and indentation are significant. Functions and-data types must be defined before use, incidentally each definition must-have a type declaration, for example see ``x : Int``, ``foo :-String``, from the above listing. New declarations must begin at the-same level of indentation as the preceding declaration.-Alternatively, a semicolon ``;`` can be used to terminate declarations.--A library module ``prelude`` is automatically imported by every-Idris program, including facilities for IO, arithmetic, data-structures and various common functions. The prelude defines several-arithmetic and comparison operators, which we can use at the prompt.-Evaluating things at the prompt gives an answer, and the type of the-answer. For example:--::--    *prims> 6*6+6-    42 : Integer-    *prims> x == 6*6+6-    True : Bool--All of the usual arithmetic and comparison operators are defined for-the primitive types. They are overloaded using interfaces, as we-will discuss in Section :ref:`sect-interfaces` and can be extended to-work on user defined types. Boolean expressions can be tested with the-``if...then...else`` construct, for example:--::--    *prims> if x == 6 * 6 + 6 then "The answer!" else "Not the answer"-    "The answer!" : String--Data Types-==========--Data types are declared in a similar way and with similar syntax to-Haskell. Natural numbers and lists, for example, can be declared as-follows:--.. code-block:: idris--    data Nat    = Z   | S Nat           -- Natural numbers-                                        -- (zero and successor)-    data List a = Nil | (::) a (List a) -- Polymorphic lists--The above declarations are taken from the standard library. Unary-natural numbers can be either zero (``Z``), or the successor of-another natural number (``S k``). Lists can either be empty (``Nil``)-or a value added to the front of another list (``x :: xs``). In the-declaration for ``List``, we used an infix operator ``::``. New-operators such as this can be added using a fixity declaration, as-follows:--::--    infixr 10 ::--Functions, data constructors and type constructors may all be given-infix operators as names. They may be used in prefix form if enclosed-in brackets, e.g. ``(::)``. Infix operators can use any of the-symbols:--::--    :+-*\/=.?|&><!@$%^~#--Some operators built from these symbols can't be user defined. These are-``:``,  ``=>``,  ``->``,  ``<-``,  ``=``,  ``?=``,  ``|``,  ``**``,-``==>``,  ``\``,  ``%``,  ``~``,  ``?``,  and ``!``.--Functions-=========--Functions are implemented by pattern matching, again using a similar-syntax to Haskell. The main difference is that Idris requires type-declarations for all functions, using a single colon ``:`` (rather-than Haskell’s double colon ``::``). Some natural number arithmetic-functions can be defined as follows, again taken from the standard-library:--.. code-block:: idris--    -- Unary addition-    plus : Nat -> Nat -> Nat-    plus Z     y = y-    plus (S k) y = S (plus k y)--    -- Unary multiplication-    mult : Nat -> Nat -> Nat-    mult Z     y = Z-    mult (S k) y = plus y (mult k y)--The standard arithmetic operators ``+`` and ``*`` are also overloaded-for use by ``Nat``, and are implemented using the above functions.-Unlike Haskell, there is no restriction on whether types and function-names must begin with a capital letter or not. Function names-(``plus`` and ``mult`` above), data constructors (``Z``, ``S``,-``Nil`` and ``::``) and type constructors (``Nat`` and ``List``) are-all part of the same namespace. By convention, however,-data types and constructor names typically begin with a capital letter.-We can test these functions at the Idris prompt:--::--    Idris> plus (S (S Z)) (S (S Z))-    4 : Nat-    Idris> mult (S (S (S Z))) (plus (S (S Z)) (S (S Z)))-    12 : Nat--.. note::--   When displaying an element of ``Nat`` such as ``(S (S (S (S Z))))``,-   Idris displays it as ``4``.-   The result of ``plus (S (S Z)) (S (S Z))``-   is actually ``(S (S (S (S Z))))``-   which is the natural number ``4``.-   This can be checked at the Idris prompt:--::--    Idris> (S (S (S (S Z))))-    4 : Nat--Like arithmetic operations, integer literals are also overloaded using-interfaces, meaning that we can also test the functions as follows:--::--    Idris> plus 2 2-    4 : Nat-    Idris> mult 3 (plus 2 2)-    12 : Nat--You may wonder, by the way, why we have unary natural numbers when our-computers have perfectly good integer arithmetic built in. The reason-is primarily that unary numbers have a very convenient structure which-is easy to reason about, and easy to relate to other data structures-as we will see later. Nevertheless, we do not want this convenience to-be at the expense of efficiency. Fortunately, Idris knows about-the relationship between ``Nat`` (and similarly structured types) and-numbers. This means it can optimise the representation, and functions-such as ``plus`` and ``mult``.--``where`` clauses--------------------Functions can also be defined *locally* using ``where`` clauses. For-example, to define a function which reverses a list, we can use an-auxiliary function which accumulates the new, reversed list, and which-does not need to be visible globally:--.. code-block:: idris--    reverse : List a -> List a-    reverse xs = revAcc [] xs where-      revAcc : List a -> List a -> List a-      revAcc acc [] = acc-      revAcc acc (x :: xs) = revAcc (x :: acc) xs--Indentation is significant — functions in the ``where`` block must be-indented further than the outer function.--.. note:: Scope--    Any names which are visible in the outer scope are also visible in-    the ``where`` clause (unless they have been redefined, such as ``xs``-    here). A name which appears only in the type will be in scope in the-    ``where`` clause if it is a *parameter* to one of the types, i.e. it-    is fixed across the entire structure.--As well as functions, ``where`` blocks can include local data-declarations, such as the following where ``MyLT`` is not accessible-outside the definition of ``foo``:--.. code-block:: idris--    foo : Int -> Int-    foo x = case isLT of-                Yes => x*2-                No => x*4-        where-           data MyLT = Yes | No--           isLT : MyLT-           isLT = if x < 20 then Yes else No--In general, functions defined in a ``where`` clause need a type-declaration just like any top level function. However, the type-declaration for a function ``f`` *can* be omitted if:--- ``f`` appears in the right hand side of the top level definition--- The type of ``f`` can be completely determined from its first application---So, for example, the following definitions are legal:--.. code-block:: idris--    even : Nat -> Bool-    even Z = True-    even (S k) = odd k where-      odd Z = False-      odd (S k) = even k--    test : List Nat-    test = [c (S 1), c Z, d (S Z)]-      where c x = 42 + x-            d y = c (y + 1 + z y)-                  where z w = y + w--.. _sect-holes:--Holes--------Idris programs can contain *holes* which stand for incomplete parts of-programs. For example, we could leave a hole for the greeting in our-"Hello world" program:--.. code-block:: idris--    main : IO ()-    main = putStrLn ?greeting--The syntax ``?greeting`` introduces a hole, which stands for a part of-a program which is not yet written. This is a valid Idris program, and you-can check the type of ``greeting``:--::--    *Hello> :t greeting-    ---------------------------------------    greeting : String--Checking the type of a hole also shows the types of any variables in scope.-For example, given an incomplete definition of ``even``:--.. code-block:: idris--    even : Nat -> Bool-    even Z = True-    even (S k) = ?even_rhs--We can check the type of ``even_rhs`` and see the expected return type,-and the type of the variable ``k``:--::--    *Even> :t even_rhs-      k : Nat-    ---------------------------------------    even_rhs : Bool--Holes are useful because they help us write functions *incrementally*.-Rather than writing an entire function in one go, we can leave some parts-unwritten and use Idris to tell us what is necessary to complete the-definition.--Dependent Types-===============--.. _sect-fctypes:--First Class Types--------------------In Idris, types are first class, meaning that they can be computed and-manipulated (and passed to functions) just like any other language construct.-For example, we could write a function which computes a type:--.. code-block:: idris--    isSingleton : Bool -> Type-    isSingleton True = Nat-    isSingleton False = List Nat--This function calculates the appropriate type from a ``Bool`` which flags-whether the type should be a singleton or not. We can use this function-to calculate a type anywhere that a type can be used. For example, it-can be used to calculate a return type:--.. code-block:: idris--    mkSingle : (x : Bool) -> isSingleton x-    mkSingle True = 0-    mkSingle False = []--Or it can be used to have varying input types. The following function-calculates either the sum of a list of ``Nat``, or returns the given-``Nat``, depending on whether the singleton flag is true:--.. code-block:: idris--    sum : (single : Bool) -> isSingleton single -> Nat-    sum True x = x-    sum False [] = 0-    sum False (x :: xs) = x + sum False xs--Vectors----------A standard example of a dependent data type is the type of “lists with-length”, conventionally called vectors in the dependent type-literature. They are available as part of the Idris library, by-importing ``Data.Vect``, or we can declare them as follows:--.. code-block:: idris--    data Vect : Nat -> Type -> Type where-       Nil  : Vect Z a-       (::) : a -> Vect k a -> Vect (S k) a--Note that we have used the same constructor names as for ``List``.-Ad-hoc name overloading such as this is accepted by Idris,-provided that the names are declared in different namespaces (in-practice, normally in different modules). Ambiguous constructor names-can normally be resolved from context.--This declares a family of types, and so the form of the declaration is-rather different from the simple type declarations above. We-explicitly state the type of the type constructor ``Vect`` — it takes-a ``Nat`` and a type as an argument, where ``Type`` stands for the-type of types. We say that ``Vect`` is *indexed* over ``Nat`` and-*parameterised* by ``Type``. Each constructor targets a different part-of the family of types. ``Nil`` can only be used to construct vectors-with zero length, and ``::`` to construct vectors with non-zero-length. In the type of ``::``, we state explicitly that an element of-type ``a`` and a tail of type ``Vect k a`` (i.e., a vector of length-``k``) combine to make a vector of length ``S k``.--We can define functions on dependent types such as ``Vect`` in the same-way as on simple types such as ``List`` and ``Nat`` above, by pattern-matching. The type of a function over ``Vect`` will describe what-happens to the lengths of the vectors involved. For example, ``++``,-defined as follows, appends two ``Vect``:--.. code-block:: idris--    (++) : Vect n a -> Vect m a -> Vect (n + m) a-    (++) Nil       ys = ys-    (++) (x :: xs) ys = x :: xs ++ ys--The type of ``(++)`` states that the resulting vector’s length will be-the sum of the input lengths. If we get the definition wrong in such a-way that this does not hold, Idris will not accept the definition.-For example:--.. code-block:: idris--    (++) : Vect n a -> Vect m a -> Vect (n + m) a-    (++) Nil       ys = ys-    (++) (x :: xs) ys = x :: xs ++ xs -- BROKEN--When run through the Idris type checker, this results in the-following:--::--    $ idris VBroken.idr --check-    VBroken.idr:9:23-25:-    When checking right hand side of Vect.++ with expected type-            Vect (S k + m) a--    When checking an application of constructor Vect.:::-            Type mismatch between-                    Vect (k + k) a (Type of xs ++ xs)-            and-                    Vect (plus k m) a (Expected type)--            Specifically:-                    Type mismatch between-                            plus k k-                    and-                            plus k m---This error message suggests that there is a length mismatch between-two vectors — we needed a vector of length ``k + m``, but provided a-vector of length ``k + k``.--The Finite Sets------------------Finite sets, as the name suggests, are sets with a finite number of-elements. They are available as part of the Idris library, by-importing ``Data.Fin``, or can be declared as follows:--.. code-block:: idris--    data Fin : Nat -> Type where-       FZ : Fin (S k)-       FS : Fin k -> Fin (S k)--From the signature,  we can see that this is a type constructor that takes a ``Nat``, and produces a type.-So this is not a set in the sense of a collection that is a container of objects,-rather it is the canonical set of unnamed elements, as in "the set of 5 elements," for example.-Effectively, it is a type that captures integers that fall into the range of zero to ``(n - 1)`` where-``n`` is the argument used to instantiate the ``Fin`` type.-For example, ``Fin 5`` can be thought of as the type of integers between 0 and 4.--Let us look at the constructors in greater detail.--``FZ`` is the zeroth element of a finite set with ``S k`` elements;-``FS n`` is the ``n+1``\ th element of a finite set with ``S k``-elements. ``Fin`` is indexed by a ``Nat``, which represents the number-of elements in the set. Since we can’t construct an element of an-empty set, neither constructor targets ``Fin Z``.--As mentioned above, a useful application of the ``Fin`` family is to-represent bounded natural numbers. Since the first ``n`` natural-numbers form a finite set of ``n`` elements, we can treat ``Fin n`` as-the set of integers greater than or equal to zero and less than ``n``.--For example, the following function which looks up an element in a-``Vect``, by a bounded index given as a ``Fin n``, is defined in the-prelude:--.. code-block:: idris--    index : Fin n -> Vect n a -> a-    index FZ     (x :: xs) = x-    index (FS k) (x :: xs) = index k xs--This function looks up a value at a given location in a vector. The-location is bounded by the length of the vector (``n`` in each case),-so there is no need for a run-time bounds check. The type checker-guarantees that the location is no larger than the length of the-vector, and of course no less than zero.--Note also that there is no case for ``Nil`` here. This is because it-is impossible. Since there is no element of ``Fin Z``, and the-location is a ``Fin n``, then ``n`` can not be ``Z``. As a result,-attempting to look up an element in an empty vector would give a-compile time type error, since it would force ``n`` to be ``Z``.--Implicit Arguments---------------------Let us take a closer look at the type of ``index``:--.. code-block:: idris--    index : Fin n -> Vect n a -> a--It takes two arguments, an element of the finite set of ``n`` elements,-and a vector with ``n`` elements of type ``a``. But there are also two-names, ``n`` and ``a``, which are not declared explicitly. These are-*implicit* arguments to ``index``. We could also write the type of-``index`` as:--.. code-block:: idris--    index : {a:Type} -> {n:Nat} -> Fin n -> Vect n a -> a--Implicit arguments, given in braces ``{}`` in the type declaration,-are not given in applications of ``index``; their values can be-inferred from the types of the ``Fin n`` and ``Vect n a``-arguments. Any name beginning with a lower case letter which appears-as a parameter or index in a-type declaration, which is not applied to any arguments, will-*always* be automatically-bound as an implicit argument. Implicit arguments can still be given-explicitly in applications, using ``{a=value}`` and ``{n=value}``, for-example:--.. code-block:: idris--    index {a=Int} {n=2} FZ (2 :: 3 :: Nil)--In fact, any argument, implicit or explicit, may be given a name. We-could have declared the type of ``index`` as:--.. code-block:: idris--    index : (i:Fin n) -> (xs:Vect n a) -> a--It is a matter of taste whether you want to do this — sometimes it can-help document a function by making the purpose of an argument more-clear.--Furthermore, ``{}`` can be used to pattern match on the left hand side, i.e.-``{var = pat}`` gets an implicit variable and attempts to pattern match on “pat”;-For example:--.. code-block:: idris--    isEmpty : Vect n a -> Bool-    isEmpty {n = Z} _   = True-    isEmpty {n = S k} _ = False--“``using``” notation-----------------------Sometimes it is useful to provide types of implicit arguments,-particularly where there is a dependency ordering, or where the-implicit arguments themselves have dependencies. For example, we may-wish to state the types of the implicit arguments in the following-definition, which defines a predicate on vectors (this is also defined-in ``Data.Vect``, under the name ``Elem``):--.. code-block:: idris--    data IsElem : a -> Vect n a -> Type where-       Here :  {x:a} ->   {xs:Vect n a} -> IsElem x (x :: xs)-       There : {x,y:a} -> {xs:Vect n a} -> IsElem x xs -> IsElem x (y :: xs)--An instance of ``IsElem x xs`` states that ``x`` is an element of-``xs``.  We can construct such a predicate if the required element is-``Here``, at the head of the vector, or ``There``, in the tail of the-vector. For example:--.. code-block:: idris--    testVec : Vect 4 Int-    testVec = 3 :: 4 :: 5 :: 6 :: Nil--    inVect : IsElem 5 Main.testVec-    inVect = There (There Here)--.. important:: Implicit Arguments and Scope--    Within the type signature the typechecker will treat all variables-    that start with an lowercase letter **and** are not applied to-    something else as an implicit variable. To get the above code-    example to compile you will need to provide a qualified name for-    ``testVec``. In the example above, we have assumed that the code-    lives within the ``Main`` module.--If the same implicit arguments are being used a lot, it can make a-definition difficult to read. To avoid this problem, a ``using`` block-gives the types and ordering of any implicit arguments which can-appear within the block:--.. code-block:: idris--    using (x:a, y:a, xs:Vect n a)-      data IsElem : a -> Vect n a -> Type where-         Here  : IsElem x (x :: xs)-         There : IsElem x xs -> IsElem x (y :: xs)--Note: Declaration Order and ``mutual`` blocks-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~--In general, functions and data types must be defined before use, since-dependent types allow functions to appear as part of types, and type-checking can rely on how particular functions are defined (though this-is only true of total functions; see Section :ref:`sect-totality`).-However, this restriction can be relaxed by using a ``mutual`` block,-which allows data types and functions to be defined simultaneously:--.. code-block:: idris--    mutual-      even : Nat -> Bool-      even Z = True-      even (S k) = odd k--      odd : Nat -> Bool-      odd Z = False-      odd (S k) = even k--In a ``mutual`` block, first all of the type declarations are added,-then the function bodies. As a result, none of the function types can-depend on the reduction behaviour of any of the functions in the-block.--I/O-===--Computer programs are of little use if they do not interact with the-user or the system in some way. The difficulty in a pure language such-as Idris — that is, a language where expressions do not have-side-effects — is that I/O is inherently side-effecting. Therefore in-Idris, such interactions are encapsulated in the type ``IO``:--.. code-block:: idris--    data IO a -- IO operation returning a value of type a--We’ll leave the definition of ``IO`` abstract, but effectively it-describes what the I/O operations to be executed are, rather than how-to execute them. The resulting operations are executed externally, by-the run-time system. We’ve already seen one IO program:--.. code-block:: idris--    main : IO ()-    main = putStrLn "Hello world"--The type of ``putStrLn`` explains that it takes a string, and returns-an element of the unit type ``()`` via an I/O action. There is a-variant ``putStr`` which outputs a string without a newline:--.. code-block:: idris--    putStrLn : String -> IO ()-    putStr   : String -> IO ()--We can also read strings from user input:--.. code-block:: idris--    getLine : IO String--A number of other I/O operations are defined in the prelude, for-example for reading and writing files, including:--.. code-block:: idris--    data File -- abstract-    data Mode = Read | Write | ReadWrite--    openFile : (f : String) -> (m : Mode) -> IO (Either FileError File)-    closeFile : File -> IO ()--    fGetLine : (h : File) -> IO (Either FileError String)-    fPutStr : (h : File) -> (str : String) -> IO (Either FileError ())-    fEOF : File -> IO Bool--Note that several of these return ``Either``, since they may fail.--.. _sect-do:--“``do``” notation-=================--I/O programs will typically need to sequence actions, feeding the-output of one computation into the input of the next. ``IO`` is an-abstract type, however, so we can’t access the result of a computation-directly. Instead, we sequence operations with ``do`` notation:--.. code-block:: idris--    greet : IO ()-    greet = do putStr "What is your name? "-               name <- getLine-               putStrLn ("Hello " ++ name)--The syntax ``x <- iovalue`` executes the I/O operation ``iovalue``, of-type ``IO a``, and puts the result, of type ``a`` into the variable-``x``. In this case, ``getLine`` returns an ``IO String``, so ``name``-has type ``String``. Indentation is significant — each statement in-the do block must begin in the same column. The ``pure`` operation-allows us to inject a value directly into an IO operation:--.. code-block:: idris--    pure : a -> IO a--As we will see later, ``do`` notation is more general than this, and-can be overloaded.--.. _sect-lazy:--Laziness-========--Normally, arguments to functions are evaluated before the function-itself (that is, Idris uses *eager* evaluation). However, this is-not always the best approach. Consider the following function:--.. code-block:: idris--    ifThenElse : Bool -> a -> a -> a-    ifThenElse True  t e = t-    ifThenElse False t e = e--This function uses one of the ``t`` or ``e`` arguments, but not both-(in fact, this is used to implement the ``if...then...else`` construct-as we will see later). We would prefer if *only* the argument which was-used was evaluated. To achieve this, Idris provides a ``Lazy``-data type, which allows evaluation to be suspended:--.. code-block:: idris--    data Lazy : Type -> Type where-         Delay : (val : a) -> Lazy a--    Force : Lazy a -> a--A value of type ``Lazy a`` is unevaluated until it is forced by-``Force``. The Idris type checker knows about the ``Lazy`` type,-and inserts conversions where necessary between ``Lazy a`` and ``a``,-and vice versa. We can therefore write ``ifThenElse`` as follows,-without any explicit use of ``Force`` or ``Delay``:--.. code-block:: idris--    ifThenElse : Bool -> Lazy a -> Lazy a -> a-    ifThenElse True  t e = t-    ifThenElse False t e = e--Codata Types-============--Codata types allow us to define infinite data structures by marking recursive-arguments as potentially infinite. For-a codata type ``T``, each of its constructor arguments of type ``T`` are transformed-into an argument of type ``Inf T``. This makes each of the ``T`` arguments-lazy, and allows infinite data structures of type ``T`` to be built. One-example of a codata type is Stream, which is defined as follows.--.. code-block:: idris--    codata Stream : Type -> Type where-      (::) : (e : a) -> Stream a -> Stream a--This gets translated into the following by the compiler.--.. code-block:: idris--    data Stream : Type -> Type where-      (::) : (e : a) -> Inf (Stream a) -> Stream a--The following is an example of how the codata type ``Stream`` can be used to-form an infinite data structure. In this case we are creating an infinite stream-of ones.--.. code-block:: idris--    ones : Stream Nat-    ones = 1 :: ones--It is important to note that codata does not allow the creation of infinite-mutually recursive data structures. For example the following will create an-infinite loop and cause a stack overflow.--.. code-block:: idris--    mutual-      codata Blue a = B a (Red a)-      codata Red a = R a (Blue a)--    mutual-      blue : Blue Nat-      blue = B 1 red--      red : Red Nat-      red = R 1 blue--    mutual-      findB : (a -> Bool) -> Blue a -> a-      findB f (B x r) = if f x then x else findR f r--      findR : (a -> Bool) -> Red a -> a-      findR f (R x b) = if f x then x else findB f b--    main : IO ()-    main = do printLn $ findB (== 1) blue--To fix this we must add explicit ``Inf`` declarations to the constructor-parameter types, since codata will not add it to constructor parameters of a-**different** type from the one being defined. For example, the following-outputs ``1``.--.. code-block:: idris--    mutual-      data Blue : Type -> Type where-       B : a -> Inf (Red a) -> Blue a--      data Red : Type -> Type where-       R : a -> Inf (Blue a) -> Red a--    mutual-      blue : Blue Nat-      blue = B 1 red--      red : Red Nat-      red = R 1 blue--    mutual-      findB : (a -> Bool) -> Blue a -> a-      findB f (B x r) = if f x then x else findR f r--      findR : (a -> Bool) -> Red a -> a-      findR f (R x b) = if f x then x else findB f b--    main : IO ()-    main = do printLn $ findB (== 1) blue--Useful Data Types-=================--Idris includes a number of useful data types and library functions-(see the ``libs/`` directory in the distribution, and the-`documentation <https://www.idris-lang.org/documentation/>`_). This section-describes a few of these. The functions described here are imported-automatically by every Idris program, as part of ``Prelude.idr``.--``List`` and ``Vect``------------------------We have already seen the ``List`` and ``Vect`` data types:--.. code-block:: idris--    data List a = Nil | (::) a (List a)--    data Vect : Nat -> Type -> Type where-       Nil  : Vect Z a-       (::) : a -> Vect k a -> Vect (S k) a--Note that the constructor names are the same for each — constructor-names (in fact, names in general) can be overloaded, provided that-they are declared in different namespaces (see Section-:ref:`sect-namespaces`), and will typically be resolved according to-their type. As syntactic sugar, any type with the constructor names-``Nil`` and ``::`` can be written in list form. For example:---  ``[]`` means ``Nil``---  ``[1,2,3]`` means ``1 :: 2 :: 3 :: Nil``--The library also defines a number of functions for manipulating these-types. ``map`` is overloaded both for ``List`` and ``Vect`` and-applies a function to every element of the list or vector.--.. code-block:: idris--    map : (a -> b) -> List a -> List b-    map f []        = []-    map f (x :: xs) = f x :: map f xs--    map : (a -> b) -> Vect n a -> Vect n b-    map f []        = []-    map f (x :: xs) = f x :: map f xs--For example, given the following vector of integers, and a function to-double an integer:--.. code-block:: idris--    intVec : Vect 5 Int-    intVec = [1, 2, 3, 4, 5]--    double : Int -> Int-    double x = x * 2--the function ``map`` can be used as follows to double every element in-the vector:--::--    *UsefulTypes> show (map double intVec)-    "[2, 4, 6, 8, 10]" : String--For more details of the functions available on ``List`` and-``Vect``, look in the library files:---  ``libs/prelude/Prelude/List.idr``---  ``libs/base/Data/List.idr``---  ``libs/base/Data/Vect.idr``---  ``libs/base/Data/VectType.idr``--Functions include filtering, appending, reversing, and so on.--Aside: Anonymous functions and operator sections-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~--There are actually neater ways to write the above expression. One way-would be to use an anonymous function:--::--    *UsefulTypes> show (map (\x => x * 2) intVec)-    "[2, 4, 6, 8, 10]" : String--The notation ``\x => val`` constructs an anonymous function which takes-one argument, ``x`` and returns the expression ``val``. Anonymous-functions may take several arguments, separated by commas,-e.g. ``\x, y, z => val``. Arguments may also be given explicit types,-e.g. ``\x : Int => x * 2``, and can pattern match,-e.g. ``\(x, y) => x + y``. We could also use an operator section:--::--    *UsefulTypes> show (map (* 2) intVec)-    "[2, 4, 6, 8, 10]" : String--``(*2)`` is shorthand for a function which multiplies a number-by 2. It expands to ``\x => x * 2``. Similarly, ``(2*)`` would expand-to ``\x => 2 * x``.--Maybe--------``Maybe`` describes an optional value. Either there is a value of the-given type, or there isn’t:--.. code-block:: idris--    data Maybe a = Just a | Nothing--``Maybe`` is one way of giving a type to an operation that may-fail. For example, looking something up in a ``List`` (rather than a-vector) may result in an out of bounds error:--.. code-block:: idris--    list_lookup : Nat -> List a -> Maybe a-    list_lookup _     Nil         = Nothing-    list_lookup Z     (x :: xs) = Just x-    list_lookup (S k) (x :: xs) = list_lookup k xs--The ``maybe`` function is used to process values of type ``Maybe``,-either by applying a function to the value, if there is one, or by-providing a default value:--.. code-block:: idris--    maybe : Lazy b -> Lazy (a -> b) -> Maybe a -> b--Note that the types of the first two arguments are wrapped in-``Lazy``. Since only one of the two arguments will actually be used,-we mark them as ``Lazy`` in case they are large expressions where it-would be wasteful to compute and then discard them.--Tuples---------Values can be paired with the following built-in data type:--.. code-block:: idris--    data Pair a b = MkPair a b--As syntactic sugar, we can write ``(a, b)`` which, according to-context, means either ``Pair a b`` or ``MkPair a b``. Tuples can-contain an arbitrary number of values, represented as nested pairs:--.. code-block:: idris--    fred : (String, Int)-    fred = ("Fred", 42)--    jim : (String, Int, String)-    jim = ("Jim", 25, "Cambridge")--::--    *UsefulTypes> fst jim-    "Jim" : String-    *UsefulTypes> snd jim-    (25, "Cambridge") : (Int, String)-    *UsefulTypes> jim == ("Jim", (25, "Cambridge"))-    True : Bool--Dependent Pairs------------------Dependent pairs allow the type of the second element of a pair to depend-on the value of the first element:--.. code-block:: idris--    data DPair : (a : Type) -> (P : a -> Type) -> Type where-       MkDPair : {P : a -> Type} -> (x : a) -> P x -> DPair a P--Again, there is syntactic sugar for this. ``(a : A ** P)`` is the type-of a pair of A and P, where the name ``a`` can occur inside ``P``.-``( a ** p )`` constructs a value of this type. For example, we can-pair a number with a ``Vect`` of a particular length:--.. code-block:: idris--    vec : (n : Nat ** Vect n Int)-    vec = (2 ** [3, 4])--If you like, you can write it out the long way, the two are precisely-equivalent:--.. code-block:: idris--    vec : DPair Nat (\n => Vect n Int)-    vec = MkDPair 2 [3, 4]--The type checker could of course infer the value of the first element-from the length of the vector. We can write an underscore ``_`` in-place of values which we expect the type checker to fill in, so the-above definition could also be written as:--.. code-block:: idris--    vec : (n : Nat ** Vect n Int)-    vec = (_ ** [3, 4])--We might also prefer to omit the type of the first element of the-pair, since, again, it can be inferred:--.. code-block:: idris--    vec : (n ** Vect n Int)-    vec = (_ ** [3, 4])--One use for dependent pairs is to return values of dependent types-where the index is not necessarily known in advance. For example, if-we filter elements out of a ``Vect`` according to some predicate, we-will not know in advance what the length of the resulting vector will-be:--.. code-block:: idris--    filter : (a -> Bool) -> Vect n a -> (p ** Vect p a)--If the ``Vect`` is empty, the result is easy:--.. code-block:: idris--    filter p Nil = (_ ** [])--In the ``::`` case, we need to inspect the result of a recursive call-to ``filter`` to extract the length and the vector from the result. To-do this, we use ``with`` notation, which allows pattern matching on-intermediate values:--.. code-block:: idris--    filter p (x :: xs) with (filter p xs)-      | ( _ ** xs' ) = if (p x) then ( _ ** x :: xs' ) else ( _ ** xs' )--We will see more on ``with`` notation later.--Dependent pairs are sometimes referred to as “Sigma types”.--Records----------*Records* are data types which collect several values (the record's-*fields*) together. Idris provides syntax for defining records and-automatically generating field access and update functions. Unlike-the syntax used for data structures, records in Idris follow a-different syntax to that seen with Haskell. For example, we can-represent a person’s name and age in a record:--.. code-block:: idris--    record Person where-        constructor MkPerson-        firstName, middleName, lastName : String-        age : Int--    fred : Person-    fred = MkPerson "Fred" "Joe" "Bloggs" 30--The constructor name is provided using the ``constructor`` keyword,-and the *fields* are then given which are in an indented block-following the `where` keyword (here, ``firstName``, ``middleName``,-``lastName``, and ``age``). You can declare multiple fields on a-single line, provided that they have the same type. The field names-can be used to access the field values:--::--    *Record> firstName fred-    "Fred" : String-    *Record> age fred-    30 : Int-    *Record> :t firstName-    firstName : Person -> String--We can also use the field names to update a record (or, more-precisely, produce a copy of the record with the given fields-updated):--.. code-block:: bash--    *Record> record { firstName = "Jim" } fred-    MkPerson "Jim" "Joe" "Bloggs" 30 : Person-    *Record> record { firstName = "Jim", age $= (+ 1) } fred-    MkPerson "Jim" "Joe" "Bloggs" 31 : Person--The syntax ``record { field = val, ... }`` generates a function which-updates the given fields in a record. ``=`` assigns a new value to a field,-and ``$=`` applies a function to update its value.--Each record is defined in its own namespace, which means that field names-can be reused in multiple records.--Records, and fields within records, can have dependent types. Updates-are allowed to change the type of a field, provided that the result is-well-typed.--.. code-block:: idris--    record Class where-        constructor ClassInfo-        students : Vect n Person-        className : String--It is safe to update the ``students`` field to a vector of a different-length because it will not affect the type of the record:--.. code-block:: idris--    addStudent : Person -> Class -> Class-    addStudent p c = record { students = p :: students c } c--::--    *Record> addStudent fred (ClassInfo [] "CS")-    ClassInfo [MkPerson "Fred" "Joe" "Bloggs" 30] "CS" : Class--We could also use ``$=`` to define ``addStudent`` more concisely:--.. code-block:: idris--    addStudent' : Person -> Class -> Class-    addStudent' p c = record { students $= (p ::) } c--Nested record update-~~~~~~~~~~~~~~~~~~~~--Idris also provides a convenient syntax for accessing and updating-nested records. For example, if a field is accessible with the-expression ``c (b (a x))``, it can be updated using the following-syntax:--.. code-block:: idris--    record { a->b->c = val } x--This returns a new record, with the field accessed by the path-``a->b->c`` set to ``val``. The syntax is first class, i.e. ``record {-a->b->c = val }`` itself has a function type. Symmetrically, the field-can also be accessed with the following syntax:--.. code-block:: idris--    record { a->b->c } x--The ``$=`` notation is also valid for nested record updates.--Dependent Records--------------------Records can also be dependent on values. Records have *parameters*, which-cannot be updated like the other fields. The parameters appear as arguments-to the resulting type, and are written following the record type-name. For example, a pair type could be defined as follows:--.. code-block:: idris--    record Prod a b where-        constructor Times-        fst : a-        snd : b--Using the ``class`` record from earlier, the size of the class can be-restricted using a ``Vect`` and the size included in the type by parameterising-the record with the size.  For example:--.. code-block:: idris--    record SizedClass (size : Nat) where-        constructor SizedClassInfo-        students : Vect size Person-        className : String--**Note** that it is no longer possible to use the ``addStudent``-function from earlier, since that would change the size of the class. A-function to add a student must now specify in the type that the-size of the class has been increased by one. As the size is specified-using natural numbers, the new value can be incremented using the-``S`` constructor:--.. code-block:: idris--    addStudent : Person -> SizedClass n -> SizedClass (S n)-    addStudent p c =  SizedClassInfo (p :: students c) (className c)--.. _sect-more-expr:--More Expressions-================--``let`` bindings-------------------Intermediate values can be calculated using ``let`` bindings:--.. code-block:: idris--   mirror : List a -> List a-   mirror xs = let xs' = reverse xs in-                   xs ++ xs'--We can do simple pattern matching in ``let`` bindings too. For-example, we can extract fields from a record as follows, as well as by-pattern matching at the top level:--.. code-block:: idris--    data Person = MkPerson String Int--    showPerson : Person -> String-    showPerson p = let MkPerson name age = p in-                       name ++ " is " ++ show age ++ " years old"--List comprehensions----------------------Idris provides *comprehension* notation as a convenient shorthand-for building lists. The general form is:--::--    [ expression | qualifiers ]--This generates the list of values produced by evaluating the-``expression``, according to the conditions given by the comma-separated ``qualifiers``. For example, we can build a list of-Pythagorean triples as follows:--.. code-block:: idris--    pythag : Int -> List (Int, Int, Int)-    pythag n = [ (x, y, z) | z <- [1..n], y <- [1..z], x <- [1..y],-                             x*x + y*y == z*z ]--The ``[a..b]`` notation is another shorthand which builds a list of-numbers between ``a`` and ``b``. Alternatively ``[a,b..c]`` builds a-list of numbers between ``a`` and ``c`` with the increment specified-by the difference between ``a`` and ``b``. This works for type ``Nat``,-``Int`` and ``Integer``, using the ``enumFromTo`` and ``enumFromThenTo``-function from the prelude.--``case`` expressions-----------------------Another way of inspecting intermediate values of *simple* types is to-use a ``case`` expression. The following function, for example, splits-a string into two at a given character:--.. code-block:: idris--    splitAt : Char -> String -> (String, String)-    splitAt c x = case break (== c) x of-                      (x, y) => (x, strTail y)--``break`` is a library function which breaks a string into a pair of-strings at the point where the given function returns true. We then-deconstruct the pair it returns, and remove the first character of the-second string.--A ``case`` expression can match several cases, for example, to inspect-an intermediate value of type ``Maybe a``. Recall ``list_lookup``-which looks up an index in a list, returning ``Nothing`` if the index-is out of bounds. We can use this to write ``lookup_default``, which-looks up an index and returns a default value if the index is out of-bounds:--.. code-block:: idris--    lookup_default : Nat -> List a -> a -> a-    lookup_default i xs def = case list_lookup i xs of-                                  Nothing => def-                                  Just x => x--If the index is in bounds, we get the value at that index, otherwise-we get a default value:--::--    *UsefulTypes> lookup_default 2 [3,4,5,6] (-1)-    5 : Integer-    *UsefulTypes> lookup_default 4 [3,4,5,6] (-1)-    -1 : Integer--**Restrictions:** The ``case`` construct is intended for simple-analysis of intermediate expressions to avoid the need to write-auxiliary functions, and is also used internally to implement pattern-matching ``let`` and lambda bindings. It will *only* work if:--- Each branch *matches* a value of the same type, and *returns* a-  value of the same type.--- The type of the result is “known”. i.e. the type of the expression-  can be determined *without* type checking the ``case``-expression-  itself.--Totality-========--Idris distinguishes between *total* and *partial* functions.-A total function is a function that either:--+ Terminates for all possible inputs, or-+ Produces a non-empty, finite, prefix of a possibly infinite result--If a function is total, we can consider its type a precise description of what-that function will do. For example, if we have a function with a return-type of ``String`` we know something different, depending on whether or not-it's total:--+ If it's total, it will return a value of type ``String`` in finite time;-+ If it's partial, then as long as it doesn't crash or enter an infinite loop,-  it will return a ``String``.--Idris makes this distinction so that it knows which functions are safe to-evaluate while type checking (as we've seen with :ref:`sect-fctypes`). After all,-if it tries to evaluate a function during type checking which doesn't-terminate, then type checking won't terminate!-Therefore, only total functions will be evaluated during type checking.-Partial functions can still be used in types, but will not be evaluated-further.
− docs/tutorial/views.rst 
@@ -1,156 +0,0 @@-.. _sec-views:--*****************************-Views and the “``with``” rule-*****************************--Dependent pattern matching-==========================--Since types can depend on values, the form of some arguments can be-determined by the value of others. For example, if we were to write-down the implicit length arguments to ``(++)``, we’d see that the form-of the length argument was determined by whether the vector was empty-or not:--.. code-block:: idris--    (++) : Vect n a -> Vect m a -> Vect (n + m) a-    (++) {n=Z}   []        ys = ys-    (++) {n=S k} (x :: xs) ys = x :: xs ++ ys--If ``n`` was a successor in the ``[]`` case, or zero in the ``::``-case, the definition would not be well typed.--.. _sect-nattobin:--The ``with`` rule — matching intermediate values-================================================--Very often, we need to match on the result of an intermediate-computation. Idris provides a construct for this, the ``with``-rule, inspired by views in ``Epigram`` [1]_, which takes account of-the fact that matching on a value in a dependently typed language can-affect what we know about the forms of other values. In its simplest-form, the ``with`` rule adds another argument to the function being-defined.--We have already seen a vector filter function. This time, we define it-using ``with`` as follows:--.. code-block:: idris--    filter : (a -> Bool) -> Vect n a -> (p ** Vect p a)-    filter p [] = ( _ ** [] )-    filter p (x :: xs) with (filter p xs)-      filter p (x :: xs) | ( _ ** xs' ) = if (p x) then ( _ ** x :: xs' ) else ( _ ** xs' )--Here, the ``with`` clause allows us to deconstruct the result of-``filter p xs``. The view refined argument pattern ``filter p (x ::-xs)`` goes beneath the ``with`` clause, followed by a vertical bar-``|``, followed by the deconstructed intermediate result ``( _ ** xs'-)``. If the view refined argument pattern is unchanged from the-original function argument pattern, then the left side of ``|`` is-extraneous and may be omitted:--.. code-block:: idris--    filter p (x :: xs) with (filter p xs)-      | ( _ ** xs' ) = if (p x) then ( _ ** x :: xs' ) else ( _ ** xs' )--``with`` clauses can also be nested:--.. code-block:: idris--    foo : Int -> Int -> Bool-    foo n m with (succ n)-      foo _ m | 2 with (succ m)-        foo _ _ | 2 | 3 = True-        foo _ _ | 2 | _ = False-      foo _ _ | _ = False--If the intermediate computation itself has a dependent type, then the-result can affect the forms of other arguments — we can learn the form-of one value by testing another. In these cases, view refined argument-patterns must be explicit. For example, a ``Nat`` is either even or-odd. If it is even it will be the sum of two equal ``Nat``.-Otherwise, it is the sum of two equal ``Nat`` plus one:--.. code-block:: idris--    data Parity : Nat -> Type where-       Even : Parity (n + n)-       Odd  : Parity (S (n + n))--We say ``Parity`` is a *view* of ``Nat``. It has a *covering function*-which tests whether it is even or odd and constructs the predicate-accordingly.--.. code-block:: idris--    parity : (n:Nat) -> Parity n--We’ll come back to the definition of ``parity`` shortly. We can use it-to write a function which converts a natural number to a list of-binary digits (least significant first) as follows, using the ``with``-rule:--.. code-block:: idris--    natToBin : Nat -> List Bool-    natToBin Z = Nil-    natToBin k with (parity k)-       natToBin (j + j)     | Even = False :: natToBin j-       natToBin (S (j + j)) | Odd  = True  :: natToBin j--The value of ``parity k`` affects the form of ``k``, because the-result of ``parity k`` depends on ``k``. So, as well as the patterns-for the result of the intermediate computation (``Even`` and ``Odd``)-right of the ``|``, we also write how the results affect the other-patterns left of the ``|``. That is:--- When ``parity k`` evaluates to ``Even``, we can refine the original-  argument ``k`` to a refined pattern ``(j + j)`` according to-  ``Parity (n + n)`` from the ``Even`` constructor definition. So-  ``(j + j)`` replaces ``k`` on the left side of ``|``, and the-  ``Even`` constructor appears on the right side. The natural number-  ``j`` in the refined pattern can be used on the right side of the-  ``=`` sign.--- Otherwise, when ``parity k`` evaluates to ``Odd``, the original-  argument ``k`` is refined to ``S (j + j)`` according to ``Parity (S-  (n + n))`` from the ``Odd`` constructor definition, and ``Odd`` now-  appears on the right side of ``|``, again with the natural number-  ``j`` used on the right side of the ``=`` sign.--Note that there is a function in the patterns (``+``) and repeated-occurrences of ``j`` - this is allowed because another argument has-determined the form of these patterns.--We will return to this function in the next section :ref:`sect-parity` to-complete the definition of ``parity``.--With and proofs-===============-To use a dependent pattern match for theorem proving, it is sometimes necessary-to explicitly construct the proof resulting from the pattern match.-To do this, you can postfix the with clause with ``proof p`` and the proof-generated by the pattern match will be in scope and named ``p``. For example:--.. code-block:: idris--    data Foo = FInt Int | FBool Bool--    optional : Foo -> Maybe Int-    optional (FInt x) = Just x-    optional (FBool b) = Nothing--    isFInt : (foo:Foo) -> Maybe (x : Int ** (optional foo = Just x))-    isFInt foo with (optional foo) proof p-      isFInt foo | Nothing = Nothing           -- here, p : Nothing = optional foo-      isFInt foo | (Just x) = Just (x ** Refl) -- here, p : Just x = optional foo---.. [1] Conor McBride and James McKinna. 2004. The view from the-       left. J. Funct. Program. 14, 1 (January 2004),-       69-111. https://doi.org/10.1017/S0956796803004829
idris-tutorial.pdf view

binary file changed (661109 → 643333 bytes)

idris.cabal view
@@ -1,10 +1,11 @@+Cabal-Version:  2.4 Name:           idris-Version:        1.3.2-License:        BSD3+Version:        1.3.3+License:        BSD-3-Clause License-file:   LICENSE Author:         Edwin Brady-Maintainer:     Edwin Brady <eb@cs.st-andrews.ac.uk>-Homepage:       http://www.idris-lang.org/+Maintainer:     Niklas Larsson <niklas@mm.st>+Homepage:       https://www.idris-lang.org/ Bug-reports:    https://github.com/idris-lang/Idris-dev/issues  Stability:      Beta@@ -16,7 +17,7 @@                 meaning that some aspects of a program's behaviour can be                 specified precisely in the type. The language is closely                 related to Epigram and Agda. There is a tutorial at-                <http://www.idris-lang.org/documentation>.+                <https://www.idris-lang.org/documentation>.                 Features include:                 .                 * Full, first class, dependent types with dependent pattern matching@@ -41,42 +42,25 @@                 .                 * Hugs style interactive environment -Cabal-Version:  >= 1.22- Build-type:     Custom -Tested-With:    GHC == 7.10.3, GHC == 8.0.1+Tested-With:    GHC == 8.6.5, GHC == 8.8.4 +-- NOTE: due to https://github.com/haskell/cabal/issues/6125 the use of ** is+--   heavily discouraged. Data-files:            idrisdoc/styles.css-                       jsrts/jsbn/jsbn-browser.js-                       jsrts/jsbn/jsbn-node.js-                       jsrts/Runtime-common.js-                       jsrts/Runtime-javascript.js-                       jsrts/Runtime-node.js+                       jsrts/jsbn/*.js+                       jsrts/*.js                        jsrts/jsbn/LICENSE-                       rts/arduino/idris_main.c-                       rts/idris_bitstring.c-                       rts/idris_bitstring.h-                       rts/idris_gc.c-                       rts/idris_gc.h-                       rts/idris_gmp.c-                       rts/idris_gmp.h-                       rts/idris_heap.c-                       rts/idris_heap.h-                       rts/idris_main.c-                       rts/idris_net.c-                       rts/idris_net.h-                       rts/idris_opts.c-                       rts/idris_opts.h-                       rts/idris_rts.c-                       rts/idris_rts.h-                       rts/idris_stats.c-                       rts/idris_stats.h-                       rts/idris_stdfgn.c-                       rts/idris_stdfgn.h-                       rts/mini-gmp.c-                       rts/mini-gmp.h-                       rts/libtest.c+                       rts/Makefile+                       rts/*.c+                       rts/seL4/*.c+                       rts/arduino/*.c+                       rts/windows/*.c+                       rts/windows/*.h+                       rts/*.h+                       rts/seL4/CMakeLists.txt+                       rts/seL4/README.md  Extra-doc-files:                        CHANGELOG.md@@ -86,21 +70,83 @@                        README.md                        RELEASE-CHECKS.md                        idris-tutorial.pdf+                       man/idris.1                        samples/effects/*.idr                        samples/misc/*.idr-                       samples/misc/*.lidr                        samples/tutorial/*.idr+                       samples/ST/*.idr+                       samples/ST/Graphics/*.idr+                       samples/ST/Net/*.idr+                       samples/misc/*.lidr  -- extra-source-files is generated by Setup.hs using `git --ls-files`. Extra-source-files:+                      Makefile+                      config.mk+                      custom.mk-alldeps+                      mkpkg.sh+                      stack-shell.nix+                      stack.yaml+                      stylize.sh+                      win-release.sh +                      benchmarks/*.pl+                      benchmarks/fasta/*.idr+                      benchmarks/fasta/*.ipkg+                      benchmarks/pidigits/*.idr+                      benchmarks/pidigits/*.ipkg+                      benchmarks/quasigroups/*.idr+                      benchmarks/quasigroups/*.ipkg+                      benchmarks/trivial/*.idr+                      benchmarks/trivial/*.ipkg+                      benchmarks/quasigroups/board++                      icons/*.png+                      icons/*.ico+                      icons/*.rc+                      icons/*.svg+                      icons/*.xml++                      libs/**/*.idr+                      libs/**/*.ipkg+                      libs/**/*.txt+                      libs/Makefile+                      libs/base/Makefile+                      libs/contrib/Makefile+                      libs/effects/Makefile+                      libs/prelude/Makefile+                      libs/pruviloj/Makefile++                      scripts/generate-multi-ghc-travis-template+                      scripts/runidris+                      scripts/runidris-node++                      src/.ghci++                      test/*.md+                      test/*.hs+                      test/**/*.idr+                      test/**/*.lidr+                      test/**/*.ipkg+                      test/**/*.out+                      test/**/*.sh+                      test/**/*.c+                      test/**/*.h+                      test/**/*.in+                      test/**/*.txt+                      test/**/*.js+                      test/base001/Makefile+                      test/ffi004/theOtherType+                      test/ffi004/theType+                      test/scripts/timeout+ source-repository head   type:     git   location: git://github.com/idris-lang/Idris-dev.git  custom-setup   setup-depends:-    Cabal >= 1.10 && <2.5,+    Cabal >= 2.4 && < 3.1,     base  >= 4 && <5,     directory,     filepath,@@ -261,26 +307,29 @@                   Util.Pretty                 , Util.Net ---                -- Auto Generated                 , Paths_idris                 , Version_idris                 , Tools_idris                 , BuildFlags_idris +                -- Auto Generated+  Autogen-modules:  Paths_idris+                  , Version_idris+                  , Tools_idris+                  , BuildFlags_idris+   Build-depends:  base >=4 && <5                 , aeson >= 0.6 && < 1.5                 , annotated-wl-pprint >= 0.7 && < 0.8-                , ansi-terminal < 0.9+                , ansi-terminal < 0.11                 , ansi-wl-pprint < 0.7                 , array >= 0.4.0.1 && < 0.6-                , base64-bytestring < 1.1+                , base64-bytestring < 1.2                 , binary >= 0.8.4.1 && < 0.9                 , blaze-html >= 0.6.1.3 && < 0.10-                , blaze-markup >= 0.5.2.1 && < 0.9+                , blaze-markup >= 0.5.2.1 && < 0.10                 , bytestring < 0.11-                , cheapskate >= 0.1.1 && < 0.2+                , cheapskate >= 0.1.1.2 && < 0.2                 , code-page >= 0.1 && < 0.3                 , containers >= 0.5 && < 0.7                 , deepseq < 1.5@@ -289,10 +338,10 @@                 , fingertree >= 0.1.4.1 && < 0.2                 , haskeline >= 0.7 && < 0.8                 , ieee754 >= 0.7 && < 0.9-                , megaparsec >= 7.0.4 && < 8+                , megaparsec >= 7.0.4 && < 9                 , mtl >= 2.1 && < 2.3-                , network >= 2.7 && < 2.9-                , optparse-applicative >= 0.13 && < 0.15+                , network >= 2.7 && < 3.1.2+                , optparse-applicative >= 0.13 && < 0.16                 , parser-combinators >= 1.0.0                 , pretty < 1.2                 , process < 1.7@@ -300,8 +349,8 @@                 , safe >= 0.3.9                 , split < 0.3                 , terminal-size < 0.4-                , text >=1.2.1.0 && < 1.3-                , time >= 1.4 && < 1.9+                , text >=1.2.1.0 && < 1.4+                , time >= 1.4 && < 2.0                 , transformers >= 0.5 && < 0.6                 , uniplate >=1.6 && < 1.7                 , unordered-containers < 0.3@@ -309,11 +358,12 @@                 , vector < 0.13                 , vector-binary-instances < 0.3                 , zip-archive > 0.2.3.5 && < 0.5-                , fsnotify >= 0.2 && < 2.2+                , fsnotify >= 0.2 && < 0.4                 , async < 2.3    if !impl(ghc >= 8.0)-    Build-Depends: semigroups == 0.18.*+    Build-Depends:  semigroups == 0.18.*+                  , fail == 4.9.0.*    Default-Language: Haskell2010   ghc-prof-options: -auto-all -caf-all@@ -332,6 +382,7 @@      cpp-options:   -DIDRIS_GMP   if flag(freestanding)      other-modules: Target_idris+     autogen-modules: Target_idris      cpp-options:   -DFREESTANDING   if flag(CI)      ghc-options:   -Werror@@ -365,7 +416,7 @@                , filepath                , directory                , haskeline >= 0.7-               , optparse-applicative >= 0.13 && < 0.15+               , optparse-applicative >= 0.13 && < 0.16                , tagged                , tasty >= 0.8                , tasty-golden >= 2.0@@ -380,6 +431,7 @@  Executable idris-codegen-c   Main-is:        Main.hs+  autogen-modules:  Paths_idris   other-modules:  Paths_idris   hs-source-dirs: codegen/idris-codegen-c @@ -395,6 +447,7 @@  Executable idris-codegen-javascript   Main-is:        Main.hs+  autogen-modules:  Paths_idris   other-modules:  Paths_idris   hs-source-dirs: codegen/idris-codegen-javascript @@ -410,6 +463,7 @@  Executable idris-codegen-node   Main-is:        Main.hs+  autogen-modules:  Paths_idris   other-modules:  Paths_idris   hs-source-dirs: codegen/idris-codegen-node
libs/base/Control/Isomorphism.idr view
@@ -17,21 +17,22 @@  -- Isomorphism properties -||| Isomorphism is Reflexive+||| Isomorphism is reflexive isoRefl : Iso a a-isoRefl = MkIso id id (\x => Refl) (\x => Refl)+isoRefl = MkIso id id (\_ => Refl) (\_ => Refl)  ||| Isomorphism is transitive isoTrans : Iso a b -> Iso b c -> Iso a c isoTrans (MkIso to from toFrom fromTo) (MkIso to' from' toFrom' fromTo') =-  MkIso (\x => to' (to x))-        (\y => from (from' y))-        (\y => (to' (to (from (from' y))))  ={ cong (toFrom (from' y)) }=-               (to' (from' y))              ={ toFrom' y               }=-               y                            QED)-        (\x => (from (from' (to' (to x))))  ={ cong (fromTo' (to x)) }=-               (from (to x))                ={ fromTo x              }=-               x                            QED)+  MkIso xto xfrom xtoFrom xfromTo where+    xto : a -> c+    xto = to' . to+    xfrom : c -> a+    xfrom = from . from'+    xtoFrom : (z : c) -> xto (xfrom z) = z+    xtoFrom z = rewrite toFrom $ from' z in toFrom' z+    xfromTo : (x : a) -> xfrom (xto x) = x+    xfromTo x = rewrite fromTo' (to x) in fromTo x  Category Iso where   id = isoRefl@@ -99,8 +100,7 @@  ||| Isomorphism is a congruence with regards to disjunction eitherCong : Iso a a' -> Iso b b' -> Iso (Either a b) (Either a' b')-eitherCong {a = a} {a' = a'} {b = b} {b' = b'}-           (MkIso to from toFrom fromTo)+eitherCong (MkIso to from toFrom fromTo)            (MkIso to' from' toFrom' fromTo') =   MkIso (eitherMap to to') (eitherMap from from') ok1 ok2     where eitherMap : (c -> c') -> (d -> d') -> Either c d -> Either c' d'@@ -143,9 +143,7 @@  ||| Conjunction with truth is a no-op pairUnitRight : Iso (a, ()) a-pairUnitRight = MkIso fst (\x => (x, ())) (\x => Refl) ok-  where ok : (x : (a, ())) -> (fst x, ()) = x-        ok (x, ()) = Refl+pairUnitRight = MkIso fst (\x => (x, ())) (\_ => Refl) (\(_, ()) => Refl)  ||| Conjunction with truth is a no-op pairUnitLeft : Iso ((), a) a@@ -161,8 +159,7 @@  ||| Isomorphism is a congruence with regards to conjunction pairCong : Iso a a' -> Iso b b' -> Iso (a, b) (a', b')-pairCong {a = a} {a' = a'} {b = b} {b' = b'}-         (MkIso to from toFrom fromTo)+pairCong (MkIso to from toFrom fromTo)          (MkIso to' from' toFrom' fromTo') =   MkIso to'' from'' iso1 iso2     where to'' : (a, b) -> (a', b')@@ -205,7 +202,7 @@  ||| Products distribute over sums distribRight : Iso (a, Either b c) (Either (a, b) (a, c))-distribRight {a} {b} {c} = (pairComm `isoTrans` distribLeft) `isoTrans` eitherCong pairComm pairComm+distribRight = (pairComm `isoTrans` distribLeft) `isoTrans` eitherCong pairComm pairComm   -- Enable preorder reasoning syntax over isomorphisms@@ -222,7 +219,7 @@ -- Isomorphisms over Maybe ||| Isomorphism is a congruence with respect to Maybe maybeCong : Iso a b -> Iso (Maybe a) (Maybe b)-maybeCong {a} {b} (MkIso to from toFrom fromTo) = MkIso (map to) (map from) ok1 ok2+maybeCong (MkIso to from toFrom fromTo) = MkIso (map to) (map from) ok1 ok2   where ok1 : (y : Maybe b) -> map to (map from y) = y         ok1 Nothing = Refl         ok1 (Just x) = (Just (to (from x))) ={ cong (toFrom x) }= (Just x) QED@@ -253,7 +250,7 @@                 ()              QED  eitherMaybeLeftMaybe : Iso (Either (Maybe a) b) (Maybe (Either a b))-eitherMaybeLeftMaybe {a} {b} =+eitherMaybeLeftMaybe =   (Either (Maybe a) b)     ={ eitherCongLeft maybeEither }=   (Either (Either a ()) b) ={ eitherAssoc                }=   (Either a (Either () b)) ={ eitherCongRight eitherComm }=@@ -263,7 +260,7 @@   eitherMaybeRightMaybe : Iso (Either a (Maybe b)) (Maybe (Either a b))-eitherMaybeRightMaybe {a} {b} =+eitherMaybeRightMaybe =   (Either a (Maybe b)) ={ eitherComm           }=   (Either (Maybe b) a) ={ eitherMaybeLeftMaybe }=   (Maybe (Either b a)) ={ maybeCong eitherComm }=@@ -288,8 +285,8 @@         fb (FS x) = Refl  finZeroBot : Iso (Fin 0) Void-finZeroBot = MkIso (\x => void (uninhabited x))-                   (\x => void x)+finZeroBot = MkIso (void . uninhabited)+                   void                    (\x => void x)                    (\x => void (uninhabited x))
libs/base/Data/Fin.idr view
@@ -65,6 +65,11 @@ weakenN n FZ = FZ weakenN n (FS f) = FS (weakenN n f) +||| Weaken the bound on a Fin using an inequality proof+weakenLTE : LTE n m -> Fin n -> Fin m+weakenLTE (LTESucc p)  FZ    = FZ+weakenLTE (LTESucc p) (FS f) = FS $ weakenLTE p f+ ||| Attempt to tighten the bound on a Fin. ||| Return `Left` if the bound could not be tightened, or `Right` if it could. strengthen : Fin (S n) -> Either (Fin (S n)) (Fin n)@@ -101,6 +106,10 @@ implementation MaxBound (Fin (S n)) where   maxBound = last +||| Add two Fins+addFin : (x : Fin n) -> (y : Fin m) -> Fin (finToNat x + m)+addFin  FZ    y = y+addFin (FS x) y = FS $ addFin x y  -- Construct a Fin from an integer literal which must fit in the given Fin
libs/base/Data/List/Quantifiers.idr view
@@ -75,3 +75,8 @@     case all d xs of       Yes prf' => Yes (prf :: prf')       No prf' => No (notAllThere prf')++||| Given a proof of membership for some element, extract the property proof for it+indexAll : Elem x xs -> All p xs -> p x+indexAll  Here     (p::_  ) = p+indexAll (There e) ( _::ps) = indexAll e ps
libs/base/Data/So.idr view
@@ -12,7 +12,7 @@ ||| If you find yourself using `So` for something other than primitive types, ||| it may be appropriate to define a type of evidence for the property that you ||| care about instead.-data So : Bool -> Type where +data So : Bool -> Type where   Oh : So True  implementation Uninhabited (So False) where@@ -23,4 +23,14 @@ choose True  = Left Oh choose False = Right Oh +||| Absurd when you have proof that both `b` and `not b` is true.+export+soAbsurd : So b -> So (not b) -> Void+soAbsurd sb snb with (sb)+  | Oh = uninhabited snb++||| Transmission between usage of value-level `not` and type-level `Not`.+export+soNotToNotSo : So (not b) -> Not (So b)+soNotToNotSo = flip soAbsurd
libs/base/Data/Vect.idr view
@@ -278,7 +278,7 @@ (++) []      ys = ys (++) (x::xs) ys = x :: xs ++ ys -||| Repeate some value some number of times.+||| Repeat some value some number of times. ||| ||| @ len the number of times to repeat it ||| @ x the value to repeat
libs/contrib/Control/Algebra/Laws.idr view
@@ -1,105 +1,277 @@ module Control.Algebra.Laws  import Prelude.Algebra as A-import Control.Algebra+import Control.Algebra as Alg import Interfaces.Verified  %access export -||| A prof that -0 = 0 in any verified group.-inverseNeutralIsNeutral : VerifiedGroup t => inverse (the t A.neutral) = A.neutral+-- Monoids++||| Inverses are unique.+uniqueInverse : VerifiedMonoid t => (x, y, z : t) ->+  y <+> x = A.neutral -> x <+> z = A.neutral -> y = z+uniqueInverse x y z p q =+  rewrite sym $ monoidNeutralIsNeutralL y in+    rewrite sym q in+      rewrite semigroupOpIsAssociative y x z in+  rewrite p in+    rewrite monoidNeutralIsNeutralR z in+      Refl++-- Groups++||| Only identity is self-squaring.+selfSquareId : VerifiedGroup t => (x : t) ->+  x <+> x = x -> x = A.neutral+selfSquareId x p =+  rewrite sym $ monoidNeutralIsNeutralR x in+    rewrite sym $ groupInverseIsInverseR x in+  rewrite sym $ semigroupOpIsAssociative (inverse x) x x in+    rewrite p in+      Refl++||| Inverse elements commute.+inverseCommute : VerifiedGroup t => (x, y : t) ->+  y <+> x = A.neutral -> x <+> y = A.neutral+inverseCommute x y p = selfSquareId (x <+> y) prop where+  prop : (x <+> y) <+> (x <+> y) = x <+> y+  prop =+    rewrite sym $ semigroupOpIsAssociative x y (x <+> y) in+      rewrite semigroupOpIsAssociative y x y in+    rewrite p in+      rewrite monoidNeutralIsNeutralR y in+        Refl++||| Every element has a right inverse.+groupInverseIsInverseL : VerifiedGroup t => (x : t) ->+  x <+> inverse x = Algebra.neutral+groupInverseIsInverseL x =+  inverseCommute x (inverse x) (groupInverseIsInverseR x)++||| -(-x) = x in any verified group.+inverseSquaredIsIdentity : VerifiedGroup t => (x : t) ->+  inverse (inverse x) = x+inverseSquaredIsIdentity x =+  let x' = inverse x in+    uniqueInverse+      x'+      (inverse x')+      x+      (groupInverseIsInverseR x')+      (groupInverseIsInverseR x)++||| If every square in a group is identity, the group is commutative.+squareIdCommutative : VerifiedGroup t => (x, y : t) ->+  ((a : t) -> a <+> a = A.neutral) ->+  x <+> y = y <+> x+squareIdCommutative x y p =+  let+    xy = x <+> y+    yx = y <+> x+      in+  uniqueInverse xy xy yx (p xy) prop where+    prop : (x <+> y) <+> (y <+> x) = A.neutral+    prop =+      rewrite sym $ semigroupOpIsAssociative x y (y <+> x) in+        rewrite semigroupOpIsAssociative y y x in+      rewrite p y in+        rewrite monoidNeutralIsNeutralR x in+          p x++||| -0 = 0 in any verified group.+inverseNeutralIsNeutral : VerifiedGroup t =>+  inverse (the t A.neutral) = A.neutral inverseNeutralIsNeutral {t} =-    let zero = the t neutral-        step1 = cong {f = (<+> inverse zero)} (the (zero = zero) Refl)-        step2 = replace {P = \x => zero <+> inverse zero = x} (groupInverseIsInverseL zero) step1-    in-    replace {P = \x => x = neutral} (monoidNeutralIsNeutralR $ inverse zero) step2+  let e = the t neutral in+    rewrite sym $ cong {f = inverse} (groupInverseIsInverseL e) in+      rewrite monoidNeutralIsNeutralR $ inverse e in+        inverseSquaredIsIdentity e -||| A proof that -(-x) = x in any verified group.-inverseSquaredIsIdentity : VerifiedGroup t => (x : t) -> inverse (inverse x) = x-inverseSquaredIsIdentity {t} x =-    let zero = the t neutral-        step1 = cong {f = (x <+>)} (groupInverseIsInverseL (inverse x))-        step2 = replace {P = \r => r = x <+> neutral} (semigroupOpIsAssociative x (inverse x) (inverse $ inverse x)) step1-        step3 = replace {P = \r => r <+> inverse (inverse x) = x <+> neutral} (groupInverseIsInverseL x) step2-        step4 = replace {P = \r => r = x <+> neutral} (monoidNeutralIsNeutralR (inverse $ inverse x)) step3-    in-    replace {P = \r => inverse (inverse x) = r} (monoidNeutralIsNeutralL x) step4+||| -(x + y) = -y + -x in any verified group.+inverseOfSum : VerifiedGroup t => (l, r : t) ->+  inverse (l <+> r) = inverse r <+> inverse l+inverseOfSum {t} l r =+  let+    e = the t neutral+    il = inverse l+    ir = inverse r+    lr = l <+> r+    ilr = inverse lr+    iril = ir <+> il+    ile = il <+> e+      in+  -- expand+  rewrite sym $ monoidNeutralIsNeutralR ilr in+    rewrite sym $ groupInverseIsInverseR r in+      rewrite sym $ monoidNeutralIsNeutralL ir in+        rewrite sym $ groupInverseIsInverseR l in+  -- shuffle+  rewrite semigroupOpIsAssociative ir il l in+    rewrite sym $ semigroupOpIsAssociative iril l r in+      rewrite sym $ semigroupOpIsAssociative iril lr ilr in+  -- contract+  rewrite sym $ monoidNeutralIsNeutralL il in+    rewrite groupInverseIsInverseL lr in+      rewrite sym $ semigroupOpIsAssociative (ir <+> ile) l ile in+        rewrite semigroupOpIsAssociative l il e in+          rewrite groupInverseIsInverseL l in+            rewrite monoidNeutralIsNeutralL e in+              Refl -||| A proof that -(x + y) = -x - y in any verified abelian group.-inverseDistributesOverGroupOp : VerifiedAbelianGroup t => (l, r : t) -> inverse (l <+> r) = inverse l <+> inverse r-inverseDistributesOverGroupOp {t} l r =-    let step1 = replace {P = \x => x = neutral} (sym $ groupInverseIsInverseL (l <+> r)) $ the (the t neutral = neutral) Refl-        step2 = cong {f = ((inverse r) <+>) . ((inverse l) <+>)} step1-        step3 = replace {P = \x => inverse r <+> (inverse l <+> (l <+> r <+> inverse (l <+> r))) = inverse r <+> x} (monoidNeutralIsNeutralL (inverse l)) step2-        step4 = replace {P = \x => x = inverse r <+> inverse l} (semigroupOpIsAssociative (inverse r) (inverse l) (l <+> r <+> inverse (l <+> r))) step3-        step5 = replace {P = \x => x = inverse r <+> inverse l} (semigroupOpIsAssociative (inverse r <+> inverse l) (l <+> r) (inverse (l <+> r))) step4-        step6 = replace {P = \x => x <+> inverse (l <+> r) = inverse r <+> inverse l} (semigroupOpIsAssociative (inverse r <+> inverse l) l r) step5-        step7 = replace {P = \x => x <+> r <+> inverse (l <+> r) = inverse r <+> inverse l} (sym $ semigroupOpIsAssociative (inverse r) (inverse l) l) step6-        step8 = replace {P = \x => inverse r <+> x <+> r <+> inverse (l <+> r) = inverse r <+> inverse l} (groupInverseIsInverseR l) step7-        step9 = replace {P = \x => x <+> r <+> inverse (l <+> r) = inverse r <+> inverse l} (monoidNeutralIsNeutralL (inverse r)) step8-        step10 = replace {P = \x => x <+> inverse (l <+> r) = inverse r <+> inverse l} (groupInverseIsInverseR r) step9-        step11 = replace {P = \x => x = inverse r <+> inverse l} (monoidNeutralIsNeutralR (inverse (l <+> r))) step10-    in-    replace {P = \x => inverse (l <+> r) = x} (abelianGroupOpIsCommutative (inverse r) (inverse l)) step11+||| y = z if x + y = x + z.+cancelLeft : VerifiedGroup t => (x, y, z : t) ->+  x <+> y = x <+> z -> y = z+cancelLeft x y z p =+  rewrite sym $ monoidNeutralIsNeutralR y in+    rewrite sym $ groupInverseIsInverseR x in+      rewrite sym $ semigroupOpIsAssociative (inverse x) x y in+        rewrite p in+      rewrite semigroupOpIsAssociative (inverse x) x z in+    rewrite groupInverseIsInverseR x in+  monoidNeutralIsNeutralR z -||| A proof that anything multiplied by zero yields zero back.-multNeutralAbsorbingL : VerifiedRingWithUnity t => (r : t) -> A.neutral <.> r = A.neutral-multNeutralAbsorbingL r =-    let step1 = the (unity <.> r = r) (ringWithUnityIsUnityR r)-        step2 = replace {P = \x => x <.> r = r} (sym $ monoidNeutralIsNeutralR unity) step1-        step3 = replace {P = \x => x = r} (ringOpIsDistributiveR neutral unity r) step2-        step4 = replace {P = \x => neutral <.> r <+> x = r} (ringWithUnityIsUnityR r) step3-        step5 = cong {f = \x => x <+> inverse r} step4-        step6 = replace {P = \x => x = r <+> inverse r} (sym $ semigroupOpIsAssociative (neutral <.> r) r (inverse r)) step5-        step7 = replace {P = \x => neutral <.> r <+> x = x} (groupInverseIsInverseL r) step6-    in-    replace {P = \x => x = neutral} (monoidNeutralIsNeutralL (neutral <.> r)) step7+||| y = z if y + x = z + x.+cancelRight : VerifiedGroup t => (x, y, z : t) ->+  y <+> x = z <+> x -> y = z+cancelRight x y z p =+  rewrite sym $ monoidNeutralIsNeutralL y in+    rewrite sym $ groupInverseIsInverseL x in+      rewrite semigroupOpIsAssociative y x (inverse x) in+        rewrite p in+      rewrite sym $ semigroupOpIsAssociative z x (inverse x) in+    rewrite groupInverseIsInverseL x in+  monoidNeutralIsNeutralL z -||| A proof that anything multiplied by zero yields zero back.-multNeutralAbsorbingR : VerifiedRingWithUnity t => (l : t) -> l <.> A.neutral = A.neutral-multNeutralAbsorbingR l =-    let step1 = the (l <.> unity = l) (ringWithUnityIsUnityL l)-        step2 = replace {P = \x => l <.> x = l} (sym $ monoidNeutralIsNeutralR unity) step1-        step3 = replace {P = \x => x = l} (ringOpIsDistributiveL l neutral unity) step2-        step4 = replace {P = \x => l <.> neutral <+> x = l} (ringWithUnityIsUnityL l) step3-        step5 = cong {f = \x => x <+> inverse l} step4-        step6 = replace {P = \x => x = l <+> inverse l} (sym $ semigroupOpIsAssociative (l <.> neutral) l (inverse l)) step5-        step7 = replace {P = \x => l <.> neutral <+> x = x} (groupInverseIsInverseL l) step6-    in-    replace {P = \x => x = neutral} (monoidNeutralIsNeutralL (l <.> neutral)) step7+||| For any a and b, ax = b and ya = b have solutions.+latinSquareProperty : VerifiedGroup t => (a, b : t) ->+  ((x : t ** a <+> x = b),+    (y : t ** y <+> a = b))+latinSquareProperty a b =+  let a' = inverse a in+    (((a' <+> b) **+      rewrite semigroupOpIsAssociative a a' b in+        rewrite groupInverseIsInverseL a in+          monoidNeutralIsNeutralR b),+    (b <+> a' **+      rewrite sym $ semigroupOpIsAssociative b a' a in+        rewrite groupInverseIsInverseR a in+          monoidNeutralIsNeutralL b)) -||| A proof that inverse operator can be extracted before multiplication+||| For any a, b, x, the solution to ax = b is unique.+uniqueSolutionR : VerifiedGroup t => (a, b, x, y : t) ->+  a <+> x = b -> a <+> y = b -> x = y+uniqueSolutionR a b x y p q = cancelLeft a x y $ trans p (sym q)++||| For any a, b, y, the solution to ya = b is unique.+uniqueSolutionL : VerifiedGroup t => (a, b, x, y : t) ->+  x <+> a = b -> y <+> a = b -> x = y+uniqueSolutionL a b x y p q = cancelRight a x y $ trans p (sym q)++||| -(x + y) = -x + -y in any verified abelian group.+inverseDistributesOverGroupOp : VerifiedAbelianGroup t => (l, r : t) ->+  inverse (l <+> r) = inverse l <+> inverse r+inverseDistributesOverGroupOp l r =+  rewrite abelianGroupOpIsCommutative (inverse l) (inverse r) in+    inverseOfSum l r++-- Rings++||| Anything multiplied by zero yields zero back in a verified ring.+multNeutralAbsorbingL : VerifiedRing t => (r : t) ->+  A.neutral <.> r = A.neutral+multNeutralAbsorbingL {t} r =+  let+    e = the t neutral+    ir = inverse r+    exr = e <.> r+    iexr = inverse exr+      in+  rewrite sym $ monoidNeutralIsNeutralR exr in+    rewrite sym $ groupInverseIsInverseR exr in+  rewrite sym $ semigroupOpIsAssociative iexr exr ((iexr <+> exr) <.> r) in+    rewrite groupInverseIsInverseR exr in+  rewrite sym $ ringOpIsDistributiveR e e r in+    rewrite monoidNeutralIsNeutralR e in+  groupInverseIsInverseR exr++||| Anything multiplied by zero yields zero back in a verified ring.+multNeutralAbsorbingR : VerifiedRing t => (l : t) ->+  l <.> A.neutral = A.neutral+multNeutralAbsorbingR {t} l =+  let+    e = the t neutral+    il = inverse l+    lxe = l <.> e+    ilxe = inverse lxe+      in+  rewrite sym $ monoidNeutralIsNeutralL lxe in+    rewrite sym $ groupInverseIsInverseL lxe in+  rewrite semigroupOpIsAssociative (l <.> (lxe <+> ilxe)) lxe ilxe in+    rewrite groupInverseIsInverseL lxe in+  rewrite sym $ ringOpIsDistributiveL l e e in+    rewrite monoidNeutralIsNeutralL e in+  groupInverseIsInverseL lxe++||| Inverse operator can be extracted before multiplication. ||| (-x)y = -(xy)-multInverseInversesL : VerifiedRingWithUnity t => (l, r : t) -> inverse l <.> r = inverse (l <.> r)+multInverseInversesL : VerifiedRing t => (l, r : t) ->+  inverse l <.> r = inverse (l <.> r) multInverseInversesL l r =-    let step1 = replace {P = \x => x <.> r = neutral} (sym $ groupInverseIsInverseL l) (multNeutralAbsorbingL r)-        step2 = replace {P = \x => x = neutral} (ringOpIsDistributiveR l (inverse l) r) step1-        step3 = cong {f = ((inverse (l <.> r)) <+>)} step2-        step4 = replace {P = \x => inverse (l <.> r) <+> (l <.> r <+> inverse l <.> r) = x} (monoidNeutralIsNeutralL (inverse (l <.> r))) step3-        step5 = replace {P = \x => x = inverse (l <.> r)} (semigroupOpIsAssociative (inverse (l <.> r)) (l <.> r) (inverse l <.> r)) step4-        step6 = replace {P = \x => x <+> inverse l <.> r = inverse (l <.> r)} (groupInverseIsInverseR (l <.> r)) step5-    in-    replace {P = \x => x = inverse (l <.> r)} (monoidNeutralIsNeutralR (inverse l <.> r)) step6+  let+    il = inverse l+    lxr = l <.> r+    ilxr = il <.> r+    i_lxr = inverse lxr+      in+  rewrite sym $ monoidNeutralIsNeutralR ilxr in+    rewrite sym $ groupInverseIsInverseR lxr in+      rewrite sym $ semigroupOpIsAssociative i_lxr lxr ilxr in+  rewrite sym $ ringOpIsDistributiveR l il r in+    rewrite groupInverseIsInverseL l in+  rewrite multNeutralAbsorbingL r in+    monoidNeutralIsNeutralL i_lxr -||| A proof that inverse operator can be extracted before multiplication+||| Inverse operator can be extracted before multiplication. ||| x(-y) = -(xy)-multInverseInversesR : VerifiedRingWithUnity t => (l, r : t) -> l <.> inverse r = inverse (l <.> r)+multInverseInversesR : VerifiedRing t => (l, r : t) ->+  l <.> inverse r = inverse (l <.> r) multInverseInversesR l r =-    let step1 = replace {P = \x => l <.> x = neutral} (sym $ groupInverseIsInverseL r) (multNeutralAbsorbingR l)-        step2 = replace {P = \x => x = neutral} (ringOpIsDistributiveL l r (inverse r)) step1-        step3 = cong {f = ((inverse (l <.> r)) <+>)} step2-        step4 = replace {P = \x => inverse (l <.> r) <+> (l <.> r <+> l <.> inverse r) = x} (monoidNeutralIsNeutralL (inverse (l <.> r))) step3-        step5 = replace {P = \x => x = inverse (l <.> r)} (semigroupOpIsAssociative (inverse (l <.> r)) (l <.> r) (l <.> inverse r)) step4-        step6 = replace {P = \x => x <+> l <.> inverse r = inverse (l <.> r)} (groupInverseIsInverseR (l <.> r)) step5-    in-    replace {P = \x => x = inverse (l <.> r)} (monoidNeutralIsNeutralR (l <.> inverse r)) step6+  let+    ir = inverse r+    lxr = l <.> r+    lxir = l <.> ir+    ilxr = inverse lxr+      in+  rewrite sym $ monoidNeutralIsNeutralL lxir in+    rewrite sym $ groupInverseIsInverseL lxr in+      rewrite semigroupOpIsAssociative lxir lxr ilxr in+  rewrite sym $ ringOpIsDistributiveL l ir r in+    rewrite groupInverseIsInverseR r in+  rewrite multNeutralAbsorbingR l in+    monoidNeutralIsNeutralR ilxr -||| A proof that multiplication of inverses is the same as multiplication of original-||| elements. (-x)(-y) = xy-multNegativeByNegativeIsPositive : VerifiedRingWithUnity t => (l, r : t) -> inverse l <.> inverse r = l <.> r+||| Multiplication of inverses is the same as multiplication of+||| original elements.+||| (-x)(-y) = xy+multNegativeByNegativeIsPositive : VerifiedRing t => (l, r : t) ->+  inverse l <.> inverse r = l <.> r multNegativeByNegativeIsPositive l r =     rewrite multInverseInversesR (inverse l) r in     rewrite sym $ multInverseInversesL (inverse l) r in     rewrite inverseSquaredIsIdentity l in     Refl++inverseOfUnityR : VerifiedRingWithUnity t => (x : t) ->+  inverse Alg.unity <.> x = inverse x+inverseOfUnityR x =+  rewrite multInverseInversesL Alg.unity x in+    rewrite ringWithUnityIsUnityR x in+      Refl++inverseOfUnityL : VerifiedRingWithUnity t => (x : t) ->+  x <.> inverse Alg.unity = inverse x+inverseOfUnityL x =+  rewrite multInverseInversesR x Alg.unity in+    rewrite ringWithUnityIsUnityL x in+      Refl
+ libs/contrib/Data/Bool/Algebra.idr view
@@ -0,0 +1,98 @@+module Data.Bool.Algebra++import Control.Algebra+import Interfaces.Verified++%access public export+%default total++-- && is Bool -> Lazy Bool -> Bool,+-- but Bool -> Bool -> Bool is required+and : Bool -> Bool -> Bool+and True True = True+and _ _ = False++xor : Bool -> Bool -> Bool+xor True True = False+xor False False = False+xor _ _ = True++[PlusBoolSemi] Semigroup Bool where+  (<+>) = xor++[PlusBoolSemiV] VerifiedSemigroup Bool using PlusBoolSemi where+  semigroupOpIsAssociative True True True = Refl+  semigroupOpIsAssociative True True False = Refl+  semigroupOpIsAssociative True False True = Refl+  semigroupOpIsAssociative True False False = Refl+  semigroupOpIsAssociative False True True = Refl+  semigroupOpIsAssociative False False True = Refl+  semigroupOpIsAssociative False True False = Refl+  semigroupOpIsAssociative False False False = Refl++[PlusBoolMonoid] Monoid Bool using PlusBoolSemi where+  neutral = False++[PlusBoolMonoidV] VerifiedMonoid Bool using PlusBoolSemiV, PlusBoolMonoid where+  monoidNeutralIsNeutralL True = Refl+  monoidNeutralIsNeutralL False = Refl++  monoidNeutralIsNeutralR True = Refl+  monoidNeutralIsNeutralR False = Refl++[PlusBoolGroup] Group Bool using PlusBoolMonoid where+  -- Each Bool is its own additive inverse.+  inverse = id++[PlusBoolGroupV] VerifiedGroup Bool using PlusBoolMonoidV, PlusBoolGroup where+  groupInverseIsInverseR True = Refl+  groupInverseIsInverseR False = Refl++[PlusBoolAbel] AbelianGroup Bool using PlusBoolGroup where++[PlusBoolAbelV] VerifiedAbelianGroup Bool using PlusBoolGroupV, PlusBoolAbel where+  abelianGroupOpIsCommutative True True = Refl+  abelianGroupOpIsCommutative True False = Refl+  abelianGroupOpIsCommutative False True = Refl+  abelianGroupOpIsCommutative False False = Refl++[RingBool] Ring Bool using PlusBoolAbel where+  (<.>) = and++[RingBoolV] VerifiedRing Bool using RingBool, PlusBoolAbelV where+  ringOpIsAssociative True True True = Refl+  ringOpIsAssociative True True False = Refl+  ringOpIsAssociative True False True = Refl+  ringOpIsAssociative True False False = Refl+  ringOpIsAssociative False True True = Refl+  ringOpIsAssociative False False True = Refl+  ringOpIsAssociative False True False = Refl+  ringOpIsAssociative False False False = Refl++  ringOpIsDistributiveL True True True = Refl+  ringOpIsDistributiveL True True False = Refl+  ringOpIsDistributiveL True False True = Refl+  ringOpIsDistributiveL True False False = Refl+  ringOpIsDistributiveL False True True = Refl+  ringOpIsDistributiveL False False True = Refl+  ringOpIsDistributiveL False True False = Refl+  ringOpIsDistributiveL False False False = Refl++  ringOpIsDistributiveR True True True = Refl+  ringOpIsDistributiveR True True False = Refl+  ringOpIsDistributiveR True False True = Refl+  ringOpIsDistributiveR True False False = Refl+  ringOpIsDistributiveR False True True = Refl+  ringOpIsDistributiveR False False True = Refl+  ringOpIsDistributiveR False True False = Refl+  ringOpIsDistributiveR False False False = Refl++[RingUnBool] RingWithUnity Bool using RingBool where+  unity = True++VerifiedRingWithUnity Bool using RingUnBool, RingBoolV where+  ringWithUnityIsUnityL True = Refl+  ringWithUnityIsUnityL False = Refl++  ringWithUnityIsUnityR True = Refl+  ringWithUnityIsUnityR False = Refl
libs/contrib/Data/Combinators.idr view
@@ -26,13 +26,13 @@ (...) = (.) . (.)  ||| Warbler, as named in "To Mock a Mockingbird".-||| See http://code.jsoftware.com/wiki/Vocabulary/tilde+||| See https://code.jsoftware.com/wiki/Vocabulary/tilde ||| Equivalent to `join` on the Reader monad (`(->) e` in Haskell) reflex : (a -> a -> b) -> (a -> b) reflex f x = f x x  ||| Phoenix, according to Data.Aviary.-||| See http://code.jsoftware.com/wiki/Vocabulary/fork.+||| See https://code.jsoftware.com/wiki/Vocabulary/fork. ||| Equivalent to `liftA2` on the Reader monad (`(->) e` in Haskell) fork2 : (b -> c -> d) -> (a -> b) -> (a -> c) -> (a -> d) fork2 f g h x = f (g x) (h x)
− libs/contrib/Data/List/Extra.idr 
@@ -1,46 +0,0 @@-module Data.List.Extra--%default total-%access export--||| The final segment of the accumulator is the final segment of the result.-reverseOntoAcc : (xs, ys, zs : List a) ->-  reverseOnto (ys ++ zs) xs = (reverseOnto ys xs) ++ zs-reverseOntoAcc [] _ _ = Refl-reverseOntoAcc (x :: xs) (ys) (zs) = reverseOntoAcc xs (x :: ys) zs--||| Serves as a specification for reverseOnto.-reverseOntoSpec : (xs, ys : List a) -> reverseOnto xs ys = reverse ys ++ xs-reverseOntoSpec xs ys = reverseOntoAcc ys [] xs--||| The reverse of an empty list is an empty list.  Together with reverseCons,-||| serves as a specification for reverse.-reverseNil : reverse [] = []-reverseNil = Refl--||| The reverse of a cons is the reverse of the tail followed by the head.-||| Together with reverseNil serves as a specification for reverse.-reverseCons : (x : a) -> (xs : List a) -> reverse (x::xs) = reverse xs ++ [x]-reverseCons x xs = reverseOntoSpec [x] xs--||| Reversing an append is appending reversals backwards.-reverseAppend : (xs, ys : List a) ->-  reverse (xs ++ ys) = reverse ys ++ reverse xs-reverseAppend [] ys = sym (appendNilRightNeutral (reverse ys))-reverseAppend (x :: xs) ys =-  rewrite reverseCons x (xs ++ ys) in-    rewrite reverseAppend xs ys in-      rewrite reverseCons x xs in-        sym $ appendAssociative (reverse ys) (reverse xs) [x]--||| Reversing a singleton list is a no-op.-reverseSingletonId : (x : a) -> reverse [x] = [x]-reverseSingletonId _ = Refl--||| Reversing a reverse gives the original.-reverseReverseId : (xs : List a) -> reverse (reverse xs) = xs-reverseReverseId [] = Refl-reverseReverseId (x :: xs) =-  rewrite reverseCons x xs in-    rewrite reverseAppend (reverse xs) [x] in-      cong $ reverseReverseId xs
+ libs/contrib/Data/List/Reverse.idr view
@@ -0,0 +1,99 @@+||| Properties of the reverse function.+module Data.List.Reverse++%default total+%access export++||| The final segment of the accumulator is the final segment of the result.+reverseOntoAcc : (xs, ys, zs : List a) ->+  reverseOnto (ys ++ zs) xs = (reverseOnto ys xs) ++ zs+reverseOntoAcc [] _ _ = Refl+reverseOntoAcc (x :: xs) (ys) (zs) = reverseOntoAcc xs (x :: ys) zs++||| Serves as a specification for reverseOnto.+reverseOntoSpec : (xs, ys : List a) -> reverseOnto xs ys = reverse ys ++ xs+reverseOntoSpec xs ys = reverseOntoAcc ys [] xs++||| The reverse of an empty list is an empty list.  Together with reverseCons,+||| serves as a specification for reverse.+reverseNil : reverse [] = []+reverseNil = Refl++||| The reverse of a cons is the reverse of the tail followed by the head.+||| Together with reverseNil serves as a specification for reverse.+reverseCons : (x : a) -> (xs : List a) -> reverse (x::xs) = reverse xs ++ [x]+reverseCons x xs = reverseOntoSpec [x] xs++||| Reversing an append is appending reversals backwards.+reverseAppend : (xs, ys : List a) ->+  reverse (xs ++ ys) = reverse ys ++ reverse xs+reverseAppend [] ys = sym (appendNilRightNeutral (reverse ys))+reverseAppend (x :: xs) ys =+  rewrite reverseCons x (xs ++ ys) in+    rewrite reverseAppend xs ys in+      rewrite reverseCons x xs in+        sym $ appendAssociative (reverse ys) (reverse xs) [x]++||| A recursive definition of reverse.+reverseRec : List a -> List a+reverseRec [] = []+reverseRec (x :: xs) = reverseRec xs ++ [x]++||| The iterative and recursive defintions of reverse are the same.+reverseEquiv : (xs : List a) -> reverseRec xs = reverse xs+reverseEquiv [] = Refl+reverseEquiv (x :: xs) =+  rewrite reverseEquiv xs in+    rewrite reverseAppend [x] xs in+      Refl++||| Reversing a singleton list is a no-op.+reverseSingletonId : (x : a) -> reverse [x] = [x]+reverseSingletonId _ = Refl++||| Reversing a reverse gives the original.+reverseReverseId : (xs : List a) -> reverse (reverse xs) = xs+reverseReverseId [] = Refl+reverseReverseId (x :: xs) =+  rewrite reverseCons x xs in+    rewrite reverseAppend (reverse xs) [x] in+      cong $ reverseReverseId xs++||| Reversing onto preserves list length.+reverseOntoLength : (xs, acc : List a) ->+  length $ reverseOnto acc xs = length acc + length xs+reverseOntoLength [] acc = rewrite plusZeroRightNeutral (length acc) in Refl+reverseOntoLength (x :: xs) acc =+  rewrite reverseOntoLength xs (x :: acc) in+    plusSuccRightSucc (length acc) (length xs)++||| Reversing preserves list length.+reverseLength : (xs : List a) -> length $ reverse xs = length xs+reverseLength xs = reverseOntoLength xs []++||| Equal reversed lists are equal.+reverseEqual : (xs, ys : List a) -> reverse xs = reverse ys -> xs = ys+reverseEqual xs ys prf =+  rewrite sym $ reverseReverseId xs in+    rewrite prf in+      reverseReverseId ys++||| Do geese see God?+data Palindrome : (xs : List a) -> Type where+  Empty : Palindrome []+  Single : Palindrome [_]+  Multi : Palindrome xs -> Palindrome $ [x] ++ xs ++ [x]++||| A Palindrome reversed is itself.+palindromeReverse : (xs : List a) -> Palindrome xs -> reverse xs = xs+palindromeReverse [] Empty = Refl+palindromeReverse [_] Single = Refl+palindromeReverse ([x] ++ ys ++ [x]) (Multi pf) =+  rewrite reverseAppend ([x] ++ ys) [x] in+    rewrite reverseAppend [x] ys in+      rewrite palindromeReverse ys pf in+        Refl++||| Only Palindromes are equal to their own reverse.+postulate  -- This is a tough one. Any takers?+reversePalindrome : (xs : List a) -> reverse xs = xs -> Palindrome xs
libs/contrib/Data/Monoid.idr view
@@ -8,18 +8,6 @@ -- TODO: These instances exist, but can't be named the same. -- Decide on names for these --- [all] Semigroup Bool where---   a <+> b = a && b------ [all] Monoid Bool where---   neutral = True------ [any] Semigroup Bool where---   a <+> b = a || b------ [any] Monoid Bool where---   neutral = False- Semigroup () where   (<+>) _ _ = ()
+ libs/contrib/Data/Nat/Ack.idr view
@@ -0,0 +1,60 @@+||| Properties of the Ackermann function.+module Data.Nat.Ackermann++%access public export++%default total++-- Primitive recursive functions are functions that can be calculated+-- by programs that don't use unbounded loops. Almost all common+-- mathematical functions are primitive recursive.++-- Uncomputable functions are functions that can't be calculated by+-- any programs at all. One example is the Busy Beaver function:+--   BB(k) = the maximum number of steps that can be executed by a+--           halting Turing machine with k states.+-- The values of the Busy Beaver function are unimaginably large for+-- any but the smallest inputs.++-- The Ackermann function is the most well-known example of a total+-- computable function that is not primitive recursive, i.e. a general+-- recursive function. It grows strictly faster than any primitive+-- recursive function, but also strictly slower than a function like+-- the Busy Beaver.++-- There are many variations of the Ackermann function. Here is one+-- common definition+-- (see https://sites.google.com/site/pointlesslargenumberstuff/home/2/ackermann)+-- that uses nested recursion:++ackRec : Nat -> Nat -> Nat+-- Base rule+ackRec Z m = S m+-- Prime rule+ackRec (S k) Z = ackRec k 1+-- Catastrophic rule+ackRec (S k) (S j) = ackRec k $ ackRec (S k) j++-- The so-called "base rule" and "prime rule" work together to ensure+-- termination. Happily, the Idris totality checker has no issues.++-- An unusual "repeating" defintion of the function is given in the+-- book The Little Typer:++ackRep : Nat -> Nat -> Nat+ackRep Z = (+) 1+ackRep (S k) = repeat (ackRep k)+  where+    repeat : (Nat -> Nat) -> Nat -> Nat+    repeat f Z = f 1+    repeat f (S k) = f (repeat f k)++-- These two definitions don't look like they define the same+-- function, but they do:++ackRepRec : (n, m : Nat) -> ackRep n m = ackRec n m+ackRepRec Z _ = Refl+ackRepRec (S k) Z = ackRepRec k 1+ackRepRec (S k) (S j) =+  rewrite sym $ ackRepRec (S k) j in+    ackRepRec k $ ackRep (S k) j
+ libs/contrib/Data/Nat/Fact.idr view
@@ -0,0 +1,56 @@+||| Properties of factorial functions.+module Data.Nat.Fact++%access public export++%default total++||| Recursive definition of factorial.+factRec : Nat -> Nat+factRec Z = 1+factRec (S k) = (S k) * factRec k++||| Tail-recursive accumulator for factItr.+factAcc : Nat -> Nat -> Nat+factAcc Z acc = acc+factAcc (S k) acc = factAcc k $ (S k) * acc++||| Iterative definition of factorial.+factItr : Nat -> Nat+factItr n = factAcc n 1++----------------------------------------++||| Multiplicand-shuffling lemma.+multShuffle : (a, b, c : Nat) -> a * (b * c) = b * (a * c)+multShuffle a b c =+  rewrite multAssociative a b c in+    rewrite multCommutative a b in+      sym $ multAssociative b a c++||| Multiplication of the accumulator.+factAccMult : (a, b, c : Nat) ->+  a * factAcc b c = factAcc b (a * c)+factAccMult _ Z _ = Refl+factAccMult a (S k) c =+  rewrite factAccMult a k (S k * c) in+    rewrite multShuffle a (S k) c in+      Refl++||| Addition of accumulators.+factAccPlus : (a, b, c : Nat) ->+  factAcc a b + factAcc a c = factAcc a (b + c)+factAccPlus Z _ _ = Refl+factAccPlus (S k) b c =+  rewrite factAccPlus k (S k * b) (S k * c) in+    rewrite sym $ multDistributesOverPlusRight (S k) b c in+      Refl++||| The recursive and iterative definitions are the equivalent.+factRecItr : (n : Nat) -> factRec n = factItr n+factRecItr Z = Refl+factRecItr (S k) =+  rewrite factRecItr k in+    rewrite factAccMult k k 1 in+      rewrite multOneRightNeutral k in+        factAccPlus k 1 k
libs/contrib/Data/Nat/Parity.idr view
@@ -2,18 +2,9 @@  %access public export ------------------------------------------------------------------------------------ Parity-----------------------------------------------------------------------------------mutual-  even : Nat -> Bool-  even Z = True-  even (S k) = odd k+---------------------------------------- -  odd : Nat -> Bool-  odd Z = False-  odd (S k) = even k+-- Type-level, constructive definitions of parity.  ||| A nat is Even when it is twice some other nat. Even : Nat -> Type@@ -23,6 +14,8 @@ Odd : Nat -> Type Odd n = (haf : Nat ** n = S $ haf * 2) +----------------------------------------+ ||| Two more than an Even is Even. add2Even : Even n -> Even (2 + n) add2Even (half ** pf) = (S half ** cong {f = (+) 2} pf)@@ -52,20 +45,73 @@ predEvenOdd : Even (S n) -> Odd n predEvenOdd (half ** pf) = (pred half ** succDoublePredPred pf) +----------------------------------------++-- Boolean definitions of parity.++mutual+  even : Nat -> Bool+  even Z = True+  even (S k) = odd k++  odd : Nat -> Bool+  odd Z = False+  odd (S k) = even k++----------------------------------------++-- The boolean and type-level definitions are equivalent in the sense+-- that a proof of one can be gotten from a proof of the other.++mutual+  ||| Evens are even.+  evenEven : Even n -> even n = True+  evenEven {n = Z} _ = Refl+  evenEven {n = S _} pf = oddOdd $ predEvenOdd pf++  ||| Odds are odd.+  oddOdd : Odd n -> odd n = True+  oddOdd {n = Z} (_ ** pf) = absurd pf+  oddOdd {n = S _} pf = evenEven $ predOddEven pf++mutual+  ||| If it's even, it's Even.+  evenEvenConverse : even n = True -> Even n+  evenEvenConverse {n = Z} prf = (0 ** Refl)+  evenEvenConverse {n = S k} prf =+    let (haf ** pf) = oddOddConverse prf in+      (S haf ** cong pf)++  ||| If it's odd, it's Odd+  oddOddConverse : odd n = True -> Odd n+  oddOddConverse {n = Z} prf = absurd prf+  oddOddConverse {n = S k} prf =+    let (half ** pf) = evenEvenConverse prf in+      (half ** cong pf)++----------------------------------------++||| Every nat is either even or odd.+evenorodd : (n : Nat) -> Either (even n = True) (odd n = True)+evenorodd Z = Left Refl+evenorodd (S k) = case evenorodd k of+  Left l => Right l+  Right r => Left r+ ||| Every nat is either Even or Odd. evenOrOdd : (n : Nat) -> Either (Even n) (Odd n)-evenOrOdd Z = Left (0 ** Refl)-evenOrOdd (S k) = case evenOrOdd k of-  Left (half ** pf) => Right (half ** cong {f = S} pf)-  Right (haf ** pf) => Left (S haf ** cong {f = S} pf)+evenOrOdd n = case evenorodd n of+  Left e => Left $ evenEvenConverse e+  Right o => Right $ oddOddConverse o +||| No nat is both even and odd.+notevenandodd : even n = True -> odd n = True -> Void+notevenandodd {n = Z} en on = absurd on+notevenandodd {n = S _} en on = notevenandodd on en+ ||| No nat is both Even and Odd. notEvenAndOdd : Even n -> Odd n -> Void-notEvenAndOdd {n = Z} _ (_ ** odd) = absurd odd-notEvenAndOdd {n = (S k)} (half ** even) (haf ** odd) =-  notEvenAndOdd {n = k}-   (haf ** cong {f = Nat.pred} odd)-   (pred half ** succDoublePredPred even)+notEvenAndOdd en on = notevenandodd (evenEven en) (oddOdd on)  ||| Evenness is decidable. evenDec : (n : Nat) -> Dec $ Even n@@ -79,13 +125,93 @@   Left even => No $ notEvenAndOdd even   Right odd => Yes odd -mutual-  ||| Evens are even.-  evenEven : Even n -> even n = True-  evenEven {n = Z} _ = Refl-  evenEven {n = S _} pf = oddOdd $ predEvenOdd pf+---------------------------------------- -  ||| Odds are odd.-  oddOdd : Odd n -> odd n = True-  oddOdd {n = Z} (_ ** pf) = absurd pf-  oddOdd {n = S _} pf = evenEven $ predOddEven pf+||| An Odd is the successor of an Even.+oddSuccEven : Odd n -> (m : Nat ** (n = S m, Even m))+oddSuccEven (haf ** pf) = (haf * 2 ** (pf, (haf ** Refl)))++||| Even plus Even is Even.+evenPlusEven : Even j -> Even k -> Even (j + k)+evenPlusEven (half_j ** pf_j) (half_k ** pf_k) =+  (half_j + half_k **+    rewrite pf_j in+      rewrite pf_k in+        sym $ multDistributesOverPlusLeft half_j half_k 2)++||| Odd plus Even is Odd.+oddPlusEven : Odd j -> Even k -> Odd (j + k)+oddPlusEven oj ek =+  let+    (i ** (ipj, ei)) = oddSuccEven oj+    (half_ik ** eik) = evenPlusEven ei ek+      in+  (half_ik **+    rewrite ipj in+      cong {f = S} eik)++||| Even plus Odd is Odd.+evenPlusOdd : Even j -> Odd k -> Odd (j + k)+evenPlusOdd {j} {k} ej ok = rewrite plusCommutative j k in oddPlusEven ok ej++||| Odd plus Odd is Even.+oddPlusOdd : Odd j -> Odd k -> Even (j + k)+oddPlusOdd oj ok =+  let+    (i ** (ipj, ei)) = oddSuccEven oj+    (haf_ik ** oik) = evenPlusOdd ei ok+      in+  (S haf_ik **+    rewrite ipj in+      rewrite oik in+        Refl)++||| A helper fact.+multShuffle : (a, b, c : Nat) ->+  (a * c) * (b * c) = ((a * b) * c) * c+multShuffle a b c =+  rewrite multAssociative (a * c) b c in+    rewrite multCommutative (a * c) b in+      rewrite multAssociative b a c in+        rewrite multCommutative b a in+          Refl++||| Even times Even is Even.+evenMultEven : Even j -> Even k -> Even (j * k)+evenMultEven (half_j ** pf_j) (half_k ** pf_k) =+  (half_j * half_k * 2 **+    rewrite pf_j in+      rewrite pf_k in+        multShuffle half_j half_k 2)++||| Odd times Even is Even.+oddMultEven : Odd j -> Even k -> Even (j * k)+oddMultEven oj (half_k ** pf_k) =+  let+    (i ** (ipj, ei)) = oddSuccEven oj+    (half_ik ** oik) = evenMultEven ei (half_k ** pf_k)+      in+  (half_k + half_ik **+    rewrite multDistributesOverPlusLeft half_k half_ik 2 in+      rewrite ipj in+        rewrite oik in+          rewrite pf_k in+            Refl)++||| Even times Odd is Even.+evenMultOdd : Even j -> Odd k -> Even (j * k)+evenMultOdd {j} {k} ej ok = rewrite multCommutative j k in oddMultEven ok ej++||| Odd times Odd is Odd.+oddMultOdd : Odd j -> Odd k -> Odd (j * k)+oddMultOdd oj (haf_k ** pf_k) =+  let+    (i ** (ipj, ei)) = oddSuccEven oj+    (half_ik ** eik) = evenMultOdd ei (haf_k ** pf_k)+      in+  (haf_k + half_ik **+    rewrite multDistributesOverPlusLeft haf_k half_ik 2 in+      rewrite ipj in+        rewrite eik in+          rewrite pf_k in+            Refl)
libs/contrib/Data/SortedMap.idr view
@@ -202,6 +202,10 @@ empty = Empty  export+singleton : Ord k => k -> v -> SortedMap k v+singleton k v = M Z (Leaf k v)++export lookup : k -> SortedMap k v -> Maybe v lookup _ Empty = Nothing lookup k (M _ t) = treeLookup k t
libs/contrib/Decidable/Order.idr view
@@ -7,33 +7,27 @@ import Data.Rel  %access public export------------------------------------------------------------------------------------- Utility Lemmas---------------------------------------------------------------------------------+%default total  -------------------------------------------------------------------------------- -- Preorders, Posets, total Orders, Equivalencies, Congruencies --------------------------------------------------------------------------------  interface Preorder t (po : t -> t -> Type) where-  total transitive : (a : t) -> (b : t) -> (c : t) -> po a b -> po b c -> po a c-  total reflexive : (a : t) -> po a a+  transitive : (a, b, c : t) -> po a b -> po b c -> po a c+  reflexive : (a : t) -> po a a  interface (Preorder t po) => Poset t (po : t -> t -> Type) where-  total antisymmetric : (a : t) -> (b : t) -> po a b -> po b a -> a = b+  antisymmetric : (a, b : t) -> po a b -> po b a -> a = b  interface (Poset t to) => Ordered t (to : t -> t -> Type) where-  total order : (a : t) -> (b : t) -> Either (to a b) (to b a)+  order : (a, b : t) -> Either (to a b) (to b a)  interface (Preorder t eq) => Equivalence t (eq : t -> t -> Type) where-  total symmetric : (a : t) -> (b : t) -> eq a b -> eq b a+  symmetric : (a, b : t) -> eq a b -> eq b a  interface (Equivalence t eq) => Congruence t (f : t -> t) (eq : t -> t -> Type) where-  total congruent : (a : t) -> -                    (b : t) -> -                    eq a b -> -                    eq (f a) (f b)+  congruent : (a, b : t) -> eq a b -> eq (f a) (f b)  minimum : (Ordered t to) => t -> t -> t minimum {to} x y with (order {to} x y)@@ -49,79 +43,62 @@ -- Syntactic equivalence (=) -------------------------------------------------------------------------------- -implementation Preorder t ((=) {A = t} {B = t}) where-  transitive a b c = trans {a = a} {b = b} {c = c}-  reflexive a = Refl+Preorder t (=) where+  transitive _ _ _ = trans+  reflexive _ = Refl -implementation Equivalence t ((=) {A = t} {B = t}) where-  symmetric a b prf = sym prf+Equivalence t (=) where+  symmetric _ _ = sym -implementation Congruence t f ((=) {A = t} {B = t}) where-  congruent a b = cong {a = a} {b = b} {f = f}+Congruence t f (=) where+  congruent _ _ = cong  -------------------------------------------------------------------------------- -- Natural numbers -------------------------------------------------------------------------------- -total LTEIsTransitive : (m : Nat) -> (n : Nat) -> (o : Nat) ->-                           LTE m n -> LTE n o ->-                           LTE m o-LTEIsTransitive Z n o                 LTEZero                  nlteo   = LTEZero-LTEIsTransitive (S m) (S n) (S o) (LTESucc mlten)    (LTESucc nlteo)   = LTESucc (LTEIsTransitive m n o mlten nlteo)--total LTEIsReflexive : (n : Nat) -> LTE n n-LTEIsReflexive Z      = LTEZero-LTEIsReflexive (S n)  = LTESucc (LTEIsReflexive n)--implementation Preorder Nat LTE where-  transitive = LTEIsTransitive-  reflexive  = LTEIsReflexive--total LTEIsAntisymmetric : (m : Nat) -> (n : Nat) ->-                              LTE m n -> LTE n m -> m = n-LTEIsAntisymmetric Z Z         LTEZero LTEZero = Refl-LTEIsAntisymmetric (S n) (S m) (LTESucc mLTEn) (LTESucc nLTEm) with (LTEIsAntisymmetric n m mLTEn nLTEm)-   LTEIsAntisymmetric (S n) (S n) (LTESucc mLTEn) (LTESucc nLTEm)    | Refl = Refl           ---implementation Poset Nat LTE where-  antisymmetric = LTEIsAntisymmetric--total zeroNeverGreater : {n : Nat} -> LTE (S n) Z -> Void-zeroNeverGreater {n} LTEZero     impossible-zeroNeverGreater {n} (LTESucc _) impossible--total zeroAlwaysSmaller : {n : Nat} -> LTE Z n-zeroAlwaysSmaller = LTEZero+Preorder Nat LTE where+  transitive Z _ _ _ _ = LTEZero+  transitive (S m) (S n) (S o) (LTESucc mlten) (LTESucc nlteo) =+    LTESucc (transitive m n o mlten nlteo) -total ltesuccinjective : {n : Nat} -> {m : Nat} -> (LTE n m -> Void) -> LTE (S n) (S m) -> Void-ltesuccinjective {n} {m} disprf (LTESucc nLTEm) = void (disprf nLTEm)-ltesuccinjective {n} {m} disprf LTEZero         impossible+  reflexive Z      = LTEZero+  reflexive (S n)  = LTESucc (reflexive n) +Poset Nat LTE where+  antisymmetric Z Z LTEZero LTEZero = Refl+  antisymmetric (S n) (S m) (LTESucc mLTEn) (LTESucc nLTEm)+                with (antisymmetric n m mLTEn nLTEm)+    antisymmetric _ _ _ _ | Refl = Refl -total decideLTE : (n : Nat) -> (m : Nat) -> Dec (LTE n m)-decideLTE    Z      y  = Yes LTEZero-decideLTE (S x)     Z  = No  zeroNeverGreater+decideLTE : (n, m : Nat) -> Dec (LTE n m)+decideLTE    Z      _  = Yes LTEZero+decideLTE (S _)     Z  = No  zeroNeverGreater where+  zeroNeverGreater : LTE (S _) Z -> Void+  zeroNeverGreater LTEZero     impossible+  zeroNeverGreater (LTESucc _) impossible decideLTE (S x)   (S y) with (decEq (S x) (S y))   | Yes eq      = rewrite eq in Yes (reflexive (S y))   | No _ with (decideLTE x y)     | Yes nLTEm = Yes (LTESucc nLTEm)     | No  nGTm  = No (ltesuccinjective nGTm)+    where+      ltesuccinjective : (LTE n m -> Void) -> LTE (S n) (S m) -> Void+      ltesuccinjective disprf (LTESucc nLTEm) = void (disprf nLTEm)+      ltesuccinjective _ LTEZero impossible -implementation Decidable [Nat,Nat] LTE where+Decidable [Nat, Nat] LTE where   decide = decideLTE -total-lte : (m : Nat) -> (n : Nat) -> Dec (LTE m n)-lte m n = decide {ts = [Nat,Nat]} {p = LTE} m n+lte : (m, n : Nat) -> Dec (LTE m n)+lte m n = decide {ts = [Nat, Nat]} {p = LTE} m n -total-shift : (m : Nat) -> (n : Nat) -> LTE m n -> LTE (S m) (S n)-shift m n mLTEn = LTESucc mLTEn-      -implementation Ordered Nat LTE where-  order Z      n = Left LTEZero-  order m      Z = Right LTEZero+shift : (m, n : Nat) -> LTE m n -> LTE (S m) (S n)+shift _ _ mLTEn = LTESucc mLTEn++Ordered Nat LTE where+  order Z      _ = Left LTEZero+  order _      Z = Right LTEZero   order (S k) (S j) with (order {to=LTE} k j)     order (S k) (S j) | Left  prf = Left  (shift k j prf)     order (S k) (S j) | Right prf = Right (shift j k prf)@@ -132,25 +109,24 @@  using (k : Nat)   data FinLTE : Fin k -> Fin k -> Type where-    FromNatPrf : {m : Fin k} -> {n : Fin k} -> LTE (finToNat m) (finToNat n) -> FinLTE m n+    FromNatPrf : LTE (finToNat m) (finToNat n) -> FinLTE m n -  implementation Preorder (Fin k) FinLTE where-    transitive m n o (FromNatPrf p1) (FromNatPrf p2) = -      FromNatPrf (LTEIsTransitive (finToNat m) (finToNat n) (finToNat o) p1 p2)-    reflexive n = FromNatPrf (LTEIsReflexive (finToNat n))+  Preorder (Fin k) FinLTE where+    transitive m n o (FromNatPrf p1) (FromNatPrf p2) =+      FromNatPrf (transitive (finToNat m) (finToNat n) (finToNat o) p1 p2)+    reflexive n = FromNatPrf (reflexive (finToNat n)) -  implementation Poset (Fin k) FinLTE where+  Poset (Fin k) FinLTE where     antisymmetric m n (FromNatPrf p1) (FromNatPrf p2) =-      finToNatInjective m n (LTEIsAntisymmetric (finToNat m) (finToNat n) p1 p2)-  -  implementation Decidable [Fin k, Fin k] FinLTE where+      finToNatInjective m n (antisymmetric (finToNat m) (finToNat n) p1 p2)++  Decidable [Fin k, Fin k] FinLTE where     decide m n with (decideLTE (finToNat m) (finToNat n))       | Yes prf    = Yes (FromNatPrf prf)-      | No  disprf = No (\ (FromNatPrf prf) => disprf prf)+      | No  disprf = No (\(FromNatPrf prf) => disprf prf) -  implementation Ordered (Fin k) FinLTE where+  Ordered (Fin k) FinLTE where     order m n =-      either (Left . FromNatPrf) +      either (Left . FromNatPrf)              (Right . FromNatPrf)              (order (finToNat m) (finToNat n))-
libs/contrib/Interfaces/Verified.idr view
@@ -82,7 +82,7 @@   applicativeHomomorphism x g = Refl   applicativeInterchange x (Left y) = Refl   applicativeInterchange x (Right y) = Refl-  + private foldrConcatEq : (g1 : List (a -> b)) -> (g2 : List (a -> b)) ->                 (xs : List a) ->@@ -276,14 +276,9 @@   monoidNeutralIsNeutralR xs = Refl  interface (VerifiedMonoid a, Group a) => VerifiedGroup a where-  groupInverseIsInverseL : (l : a) -> l <+> inverse l = Algebra.neutral   groupInverseIsInverseR : (r : a) -> inverse r <+> r = Algebra.neutral  VerifiedGroup ZZ using PlusZZMonoidV where-  groupInverseIsInverseL k = rewrite sym $ multCommutativeZ (NegS 0) k in-                             rewrite multNegLeftZ 0 k in-                             rewrite multOneLeftNeutralZ k in-                             plusNegateInverseLZ k   groupInverseIsInverseR k = rewrite sym $ multCommutativeZ (NegS 0) k in                              rewrite multNegLeftZ 0 k in                              rewrite multOneLeftNeutralZ k in@@ -351,7 +346,7 @@  VerifiedBoundedJoinSemilattice Bool where   joinBottomIsIdentity = orFalseNeutral-  + interface (VerifiedMeetSemilattice a, BoundedMeetSemilattice a) => VerifiedBoundedMeetSemilattice a where   meetTopIsIdentity : (x : a) -> meet x Lattice.top = x
libs/contrib/Language/JSON.idr view
@@ -1,4 +1,4 @@-||| The JSON language, as described at http://json.org/+||| The JSON language, as described at https://json.org/ module Language.JSON  import Language.JSON.Lexer
libs/contrib/Language/JSON/Data.idr view
@@ -64,6 +64,16 @@ Show JSON where   show = stringify +export+Eq JSON where+  JNull == JNull = True+  (JBoolean a) == (JBoolean b) =  a == b+  (JNumber a) == (JNumber b) = a == b+  (JString a) == (JString b) = a == b+  (JArray a) == (JArray b) = assert_total $ a == b+  (JObject a) == (JObject b) = assert_total $ a == b+  _ == _ = False+ ||| Format a JSON value, indenting by `n` spaces per nesting level. ||| ||| @curr The current indentation amount, measured in spaces.
libs/contrib/Text/Literate.idr view
@@ -30,13 +30,13 @@ %default total  untilEOL : Recognise False-untilEOL = manyUntil (is '\n') any+untilEOL = manyUntil newline any  line : String -> Lexer line s = exact s <+> space <+> untilEOL  block : String -> String -> Lexer-block s e = exact s <+> manyUntil (exact e) any +block s e = surround (exact s <+> untilEOL) (exact e <+> untilEOL) any  data Token = CodeBlock String String String            | Any String@@ -76,7 +76,7 @@   reduce (MkToken _ _ (CodeBlock l r src) :: rest) acc | (s :: ys) with (snocList ys)     reduce (MkToken _ _ (CodeBlock l r src) :: rest) acc | (s :: []) | Empty = reduce rest acc -- 2     reduce (MkToken _ _ (CodeBlock l r src) :: rest) acc | (s :: (srcs ++ [f])) | (Snoc rec) =-        reduce rest (acc ++ "\n" ++ unlines srcs ++ "\n")+        reduce rest (acc ++ unlines srcs)  -- [ NOTE ] 1 & 2 shouldn't happen as code blocks are well formed i.e. have two deliminators. @@ -101,7 +101,7 @@ ||| + Bird Style ||| |||```-|||MkLitStyle Nil [">", "<"] Nil+|||MkLitStyle Nil [">", "<"] [".lidr"] |||``` ||| ||| + Literate Haskell (for LaTeX)@@ -120,6 +120,14 @@ |||           ["org"] |||``` |||+||| + Common Mark+|||+|||```+|||MkLitStyle [("```idris","```"), ("<!-- idris","--!>")]+|||           Nil+|||           [".md", ".idris.md"]+|||```+||| public export record LiterateStyle where   constructor MkLitStyle@@ -151,5 +159,12 @@       case lex (rawTokens delims markers) str of         (toks, (_,_,"")) => Right $ reduce toks ""         (_, (l,c,i))     => Left (MkLitErr l c i)++||| Synonym for `extractCode`.+export+unlit : (specification : LiterateStyle)+     -> (litStr        : String)+     -> Either LiterateError String+unlit = extractCode  -- --------------------------------------------------------------------- [ EOF ]
libs/contrib/contrib.ipkg view
@@ -30,6 +30,7 @@         , Control.ST.File          , Data.Bool.Extra+        , Data.Bool.Algebra         , Data.BoundedList         , Data.Chain         , Data.CoList@@ -43,13 +44,16 @@         , Data.Heap         , Data.IOArray         , Data.List.Zipper-        , Data.List.Extra+        , Data.List.Reverse          , Data.Matrix         , Data.Matrix.Algebraic         , Data.Matrix.Numeric          , Data.Nat+        , Data.Nat.Ack+        , Data.Nat.Fact+        , Data.Nat.Fib         , Data.Nat.Parity         , Data.Nat.DivMod         , Data.Nat.DivMod.IteratedSubtraction
libs/effects/Effect/File.idr view
@@ -73,8 +73,8 @@ -- ---------------------------------------------- [ Resource Type Construction ]  ||| Calculates the type for the resource being computed over.  `Unit`-||| to describe pre-and-post file handle acquisistion, and `FileHandle-||| m` when a file handle has been aqcuired.+||| to describe pre-and-post file handle acquisition, and `FileHandle+||| m` when a file handle has been acquired. ||| ||| @m The mode the file handle was generated under. ||| @ty The functions return type.@@ -315,7 +315,7 @@ W : Type W = FileHandle WriteTruncate -||| A file can only be appeneded to.+||| A file can only be appended to. A : Type A = FileHandle Append @@ -324,7 +324,7 @@ RW = FileHandle ReadWrite  ||| A file opened for reading and writing and has been truncated to-||| zero if it previsiouly existed.+||| zero if it previously existed. RWPlus : Type RWPlus = FileHandle ReadWriteTruncate
libs/effects/Effect/Logging/Category.idr view
@@ -130,7 +130,7 @@ ||| ||| @l The logging level. ||| @cs The logging categories.-||| @m THe message to be logged.+||| @m The message to be logged. log : (Show a, Eq a) => (l : LogLevel n)                      -> (cs : List a)                      -> (m : String)@@ -141,7 +141,7 @@ ||| ||| @l The logging level. ||| @cs The logging categories.-||| @m THe message to be logged.+||| @m The message to be logged. logN : (Show a, Eq a) => (l : Nat)                       -> {auto prf : LTE l 70}                       -> (cs : List a)
libs/effects/Effect/Perf.idr view
@@ -193,7 +193,7 @@ collectPMetricsAndShow : Eff () [PERF] collectPMetricsAndShow = call $ TurnOn True -||| Return gatheres metrics+||| Return gathered metrics getPerfMetrics : Eff PMetrics [PERF] getPerfMetrics = call $ GetMetrics
libs/prelude/IO.idr view
@@ -80,7 +80,7 @@ ||| Idris compiler backend in use. For the default C backend, see the ||| documentation for `FFI_C`. |||-||| For more details, please consult [the Idris documentation](http://docs.idris-lang.org/en/latest/reference/ffi.html).+||| For more details, please consult [the Idris documentation](https://idris.readthedocs.io/en/latest/reference/ffi.html). ||| ||| @ f     an FFI descriptor, which is specific to the compiler backend. ||| @ fname the name of the foreign function
libs/prelude/Prelude/File.idr view
@@ -3,6 +3,7 @@ import Builtins import Prelude.List import Prelude.Maybe+import Prelude.Functor import Prelude.Monad import Prelude.Chars import Prelude.Strings@@ -80,7 +81,7 @@ export ferror : File -> IO Bool ferror (FHandle h) = do err <- do_ferror h-                        pure (not (err == 0))+                        pure (err /= 0)  ||| Call the RTS's file opening function private@@ -95,15 +96,13 @@ fopen : (f : String) -> (m : String) -> IO (Either FileError File) fopen f m = do h <- do_fopen f m                if !(nullPtr h)-                  then do err <- getFileError-                          pure (Left err)+                  then Left <$> getFileError                   else pure (Right (FHandle h))  ||| Check whether a file handle is actually a null pointer export validFile : File -> IO Bool-validFile (FHandle h) = do x <- nullPtr h-                           pure (not x)+validFile (FHandle h) = not <$> nullPtr h  ||| Modes for opening files data Mode = Read | WriteTruncate | Append | ReadWrite | ReadWriteTruncate | ReadAppend@@ -151,7 +150,8 @@ private do_getFileModifiedTime : Ptr -> IO Integer do_getFileModifiedTime h = -   do MkRaw i <- foreign FFI_C "fileModifiedTime" (Ptr -> IO (Raw Integer)) h+   do vm <- getMyVM+      MkRaw i <- foreign FFI_C "fileModifiedTime" (Ptr -> Ptr -> IO (Raw Integer)) vm h       pure i  private@@ -169,17 +169,15 @@ fileSize (FHandle h)      = do s <- do_getFileSize h          if (s < 0)-            then do err <- getFileError-                    pure (Left err)+            then Left <$> getFileError             else pure (Right s)  export fileModifiedTime : File -> IO (Either FileError Integer) fileModifiedTime (FHandle h)     = do s <- do_getFileModifiedTime h-         if (s < 0)-            then do err <- getFileError-                    pure (Left err)+         if (s == -1)+            then Left <$> getFileError             else pure (Right s)  export@@ -187,8 +185,7 @@ fileAccessTime (FHandle h)     = do s <- do_getFileAccessTime h          if (s < 0)-            then do err <- getFileError-                    pure (Left err)+            then Left <$> getFileError             else pure (Right s)  export@@ -196,11 +193,9 @@ fileStatusTime (FHandle h)     = do s <- do_getFileStatusTime h          if (s < 0)-            then do err <- getFileError-                    pure (Left err)+            then Left <$> getFileError             else pure (Right s) - private do_fread : Ptr -> IO' l String do_fread h = prim_fread h@@ -264,8 +259,7 @@                       then do errno <- getErrno                               if errno == 0                                  then pure (Left FileWriteError)-                                 else do err <- getFileError-                                         pure (Left err)+                                 else Left <$> getFileError                       else pure (Right ())  ||| Write a line to a file@@ -287,7 +281,7 @@ export fEOF : File -> IO Bool fEOF (FHandle h) = do eof <- do_feof h-                      pure (not (eof == 0))+                      pure (eof /= 0)  private do_fremove : String -> IO Int@@ -317,7 +311,8 @@ readFile fn = do Right h <- openFile fn Read                     | Left err => pure (Left err)                  Right max <- fileSize h-                    | Left err => pure (Left err)+                    | Left err => do closeFile h+                                     pure (Left err)                  sb <- newStringBuffer (max + 1)                  c <- readFile' h max sb                  closeFile h@@ -340,8 +335,11 @@ writeFile : (filepath : String) -> (contents : String) ->             IO (Either FileError ()) writeFile fn contents = do-     Right h  <- openFile fn WriteTruncate | Left err => pure (Left err)-     Right () <- fPutStr h contents        | Left err => pure (Left err)+     Right h  <- openFile fn WriteTruncate +        | Left err => pure (Left err)+     Right () <- fPutStr h contents        +        | Left err => do closeFile h+                         pure (Left err)      closeFile h      pure (Right ()) @@ -351,8 +349,7 @@ dirOpen d     = do dptr <- foreign FFI_C "idris_dirOpen" (String -> IO Ptr) d          if !(nullPtr dptr)-            then do err <- getFileError-                    pure (Left err)+            then Left <$> getFileError             else pure (Right (DHandle dptr))  export@@ -363,7 +360,7 @@ dirError : Directory -> IO Bool dirError (DHandle d)     = do err <- foreign FFI_C "idris_dirError" (Ptr -> IO Int) d-         pure (not (err == 0))+         pure (err /= 0)  export dirEntry : Directory -> IO (Either FileError String)@@ -379,8 +376,7 @@     = do ok <- foreign FFI_C "idris_mkdir" (String -> IO Int) d          if (ok == 0)             then pure (Right ())-            else do err <- getFileError-                    pure (Left err)+            else Left <$> getFileError  export changeDir : String -> IO Bool
libs/prelude/Prelude/Interfaces.idr view
@@ -113,19 +113,13 @@     compare x y = if (x == y) then EQ else                   if (boolOp prim__sltInt x y) then LT else                   GT-    (<) x y = boolOp prim__sltInt x y-    (>) x y = boolOp prim__sgtInt x y -    (<=) x y = boolOp prim__slteInt x y-    (>=) x y = boolOp prim__sgteInt x y  + Ord Integer where     compare x y = if (x == y) then EQ else                   if (boolOp prim__sltBigInt x y) then LT else                   GT-    (<) x y = boolOp prim__sltBigInt x y-    (>) x y = boolOp prim__sgtBigInt x y -    (<=) x y = boolOp prim__slteBigInt x y-    (>=) x y = boolOp prim__sgteBigInt x y +  Ord Double where     compare x y = if (x == y) then EQ else
libs/prelude/Prelude/Nat.idr view
@@ -33,11 +33,11 @@ -- Syntactic tests -------------------------------------------------------------------------------- -total isZero : Nat -> Bool+isZero : Nat -> Bool isZero Z     = True isZero (S n) = False -total isSucc : Nat -> Bool+isSucc : Nat -> Bool isSucc Z     = False isSucc (S n) = True @@ -61,12 +61,12 @@ ||| Add two natural numbers. ||| @ n the number to case-split on ||| @ m the other number-total plus : (n, m : Nat) -> Nat+plus : (n, m : Nat) -> Nat plus Z right        = right plus (S left) right = S (plus left right)  ||| Multiply natural numbers-total mult : Nat -> Nat -> Nat+mult : Nat -> Nat -> Nat mult Z right        = Z mult (S left) right = plus right $ mult left right @@ -85,13 +85,13 @@ toIntegerNat (S k) = 1 + toIntegerNat k  ||| Subtract natural numbers. If the second number is larger than the first, return 0.-total minus : Nat -> Nat -> Nat+minus : Nat -> Nat -> Nat minus Z        right     = Z minus left     Z         = left minus (S left) (S right) = minus left right  ||| Exponentiation of natural numbers-total power : Nat -> Nat -> Nat+power : Nat -> Nat -> Nat power base Z       = S Z power base (S exp) = mult base $ power base exp @@ -126,15 +126,15 @@   uninhabited LTEZero impossible  ||| Greater than or equal to-total GTE : Nat -> Nat -> Type+GTE : Nat -> Nat -> Type GTE left right = LTE right left  ||| Strict less than-total LT : Nat -> Nat -> Type+LT : Nat -> Nat -> Type LT left right = LTE (S left) right  ||| Strict greater than-total GT : Nat -> Nat -> Type+GT : Nat -> Nat -> Type GT left right = LT right left  ||| A successor is never less than or equal zero@@ -183,31 +183,31 @@ notLTImpliesGTE {a = S k} {b = S j} notLt = LTESucc (notLTImpliesGTE (notLt . LTESucc))  ||| Boolean test than one Nat is less than or equal to another-total lte : Nat -> Nat -> Bool+lte : Nat -> Nat -> Bool lte Z        right     = True lte left     Z         = False lte (S left) (S right) = lte left right  ||| Boolean test than one Nat is greater than or equal to another-total gte : Nat -> Nat -> Bool+gte : Nat -> Nat -> Bool gte left right = lte right left  ||| Boolean test than one Nat is strictly less than another-total lt : Nat -> Nat -> Bool+lt : Nat -> Nat -> Bool lt left right = lte (S left) right  ||| Boolean test than one Nat is strictly greater than another-total gt : Nat -> Nat -> Bool+gt : Nat -> Nat -> Bool gt left right = lt right left  ||| Find the least of two natural numbers-total minimum : Nat -> Nat -> Nat+minimum : Nat -> Nat -> Nat minimum Z m = Z minimum (S n) Z = Z minimum (S n) (S m) = S (minimum n m)  ||| Find the greatest of two natural numbers-total maximum : Nat -> Nat -> Nat+maximum : Nat -> Nat -> Nat maximum Z m = m maximum (S n) Z = S n maximum (S n) (S m) = S (maximum n m)@@ -217,7 +217,7 @@ toIntNat : Nat -> Int toIntNat n = prim__truncBigInt_Int (toIntegerNat n) -(-) : (m : Nat) -> (n : Nat) -> {auto smaller : LTE n m} -> Nat+(-) : (m, n : Nat) -> {auto smaller : LTE n m} -> Nat (-) m n {smaller} = minus m n  --------------------------------------------------------------------------------@@ -317,7 +317,7 @@ --------------------------------------------------------------------------------  ||| The predecessor of a natural number. `pred Z` is `Z`.-total pred : Nat -> Nat+pred : Nat -> Nat pred Z     = Z pred (S n) = n @@ -326,13 +326,13 @@ --------------------------------------------------------------------------------  ||| Fibonacci numbers-total fib : Nat -> Nat+fib : Nat -> Nat fib Z         = Z fib (S Z)     = S Z fib (S (S n)) = fib (S n) + fib n  ||| Factorial function-total fact : Nat -> Nat+fact : Nat -> Nat fact Z     = S Z fact (S n) = (S n) * fact n @@ -416,7 +416,7 @@ -------------------------------------------------------------------------------- -- GCD and LCM ---------------------------------------------------------------------------------gcd : (a: Nat) -> (b: Nat) -> .{auto ok: NotBothZero a b} -> Nat+gcd : (a, b : Nat) -> .{auto ok: NotBothZero a b} -> Nat gcd a Z     = a gcd Z b     = b gcd a (S b) = assert_total $ gcd (S b) (modNatNZ a (S b) SIsNotZ)@@ -435,10 +435,10 @@      CmpEQ : CmpNat x x      CmpGT : (x : _) -> CmpNat (y + S x) y -total cmp : (x, y : Nat) -> CmpNat x y+cmp : (x, y : Nat) -> CmpNat x y cmp Z Z     = CmpEQ-cmp Z (S k) = CmpLT _-cmp (S k) Z = CmpGT _+cmp Z (S _) = CmpLT _+cmp (S _) Z = CmpGT _ cmp (S x) (S y) with (cmp x y)   cmp (S x) (S (x + (S k))) | CmpLT k = CmpLT k   cmp (S x) (S x)           | CmpEQ   = CmpEQ@@ -451,217 +451,184 @@ -- Succ  ||| S preserves equality-total eqSucc : (left : Nat) -> (right : Nat) -> (p : left = right) ->-  S left = S right-eqSucc left _ Refl = Refl+eqSucc : (left, right : Nat) -> left = right -> S left = S right+eqSucc _ _ Refl = Refl  ||| S is injective-total succInjective : (left : Nat) -> (right : Nat) -> (p : S left = S right) ->-  left = right-succInjective left _ Refl = Refl+succInjective : (left, right : Nat) -> S left = S right -> left = right+succInjective _ _ Refl = Refl  -- Plus-total plusZeroLeftNeutral : (right : Nat) -> 0 + right = right+plusZeroLeftNeutral : (right : Nat) -> 0 + right = right plusZeroLeftNeutral right = Refl -total plusZeroRightNeutral : (left : Nat) -> left + 0 = left+plusZeroRightNeutral : (left : Nat) -> left + 0 = left plusZeroRightNeutral Z     = Refl-plusZeroRightNeutral (S n) =-  let inductiveHypothesis = plusZeroRightNeutral n in-    rewrite inductiveHypothesis in Refl+plusZeroRightNeutral (S n) = rewrite plusZeroRightNeutral n in Refl -total plusSuccRightSucc : (left : Nat) -> (right : Nat) ->-  S (left + right) = left + (S right)-plusSuccRightSucc Z right        = Refl-plusSuccRightSucc (S left) right =-  let inductiveHypothesis = plusSuccRightSucc left right in-    rewrite inductiveHypothesis in Refl+plusSuccRightSucc : (left, right : Nat) -> S (left + right) = left + (S right)+plusSuccRightSucc Z _ = Refl+plusSuccRightSucc (S left) right = rewrite plusSuccRightSucc left right in Refl -total plusCommutative : (left : Nat) -> (right : Nat) ->-  left + right = right + left-plusCommutative Z        right = rewrite plusZeroRightNeutral right in Refl+plusCommutative : (left, right : Nat) -> left + right = right + left+plusCommutative Z right = rewrite plusZeroRightNeutral right in Refl plusCommutative (S left) right =-  let inductiveHypothesis = plusCommutative left right in-    rewrite inductiveHypothesis in-      rewrite plusSuccRightSucc right left in Refl+  rewrite plusCommutative left right in+    rewrite plusSuccRightSucc right left in+      Refl -total plusAssociative : (left : Nat) -> (centre : Nat) -> (right : Nat) ->+plusAssociative : (left, centre, right : Nat) ->   left + (centre + right) = (left + centre) + right-plusAssociative Z        centre right = Refl+plusAssociative Z _ _ = Refl plusAssociative (S left) centre right =-  let inductiveHypothesis = plusAssociative left centre right in-    rewrite inductiveHypothesis in Refl+    rewrite plusAssociative left centre right in Refl -total plusConstantRight : (left : Nat) -> (right : Nat) -> (c : Nat) ->-  (p : left = right) -> left + c = right + c-plusConstantRight left _ c Refl = Refl+plusConstantRight : (left, right, c : Nat) -> left = right ->+  left + c = right + c+plusConstantRight _ _ _ Refl = Refl -total plusConstantLeft : (left : Nat) -> (right : Nat) -> (c : Nat) ->-  (p : left = right) -> c + left = c + right-plusConstantLeft left _ c Refl = Refl+plusConstantLeft : (left, right, c : Nat) -> left = right ->+  c + left = c + right+plusConstantLeft _ _ _ Refl = Refl -total plusOneSucc : (right : Nat) -> 1 + right = S right-plusOneSucc n = Refl+plusOneSucc : (right : Nat) -> 1 + right = S right+plusOneSucc _ = Refl -total plusLeftCancel : (left : Nat) -> (right : Nat) -> (right' : Nat) ->-  (p : left + right = left + right') -> right = right'-plusLeftCancel Z        right right' p = p+plusLeftCancel : (left, right, right' : Nat) ->+  left + right = left + right' -> right = right'+plusLeftCancel Z _ _ p = p plusLeftCancel (S left) right right' p =-  let inductiveHypothesis = plusLeftCancel left right right' in-    inductiveHypothesis (succInjective _ _ p)+    plusLeftCancel left right right' (succInjective _ _ p) -total plusRightCancel : (left : Nat) -> (left' : Nat) -> (right : Nat) ->-  (p : left + right = left' + right) -> left = left'-plusRightCancel left left' Z         p = rewrite sym (plusZeroRightNeutral left) in-                                         rewrite sym (plusZeroRightNeutral left') in-                                                 p-plusRightCancel left left' (S right) p =-  plusRightCancel left left' right-    (succInjective _ _ (rewrite plusSuccRightSucc left right in-                        rewrite plusSuccRightSucc left' right in p))+plusRightCancel : (left, left', right : Nat) ->+  left + right = left' + right -> left = left'+plusRightCancel left left' right p =+  plusLeftCancel right left left' $+    rewrite plusCommutative right left in+      rewrite plusCommutative right left' in+        p -total plusLeftLeftRightZero : (left : Nat) -> (right : Nat) ->-  (p : left + right = left) -> right = Z-plusLeftLeftRightZero Z        right p = p-plusLeftLeftRightZero (S left) right p =-  plusLeftLeftRightZero left right (succInjective _ _ p)+plusLeftLeftRightZero : (left, right : Nat) ->+  left + right = left -> right = Z+plusLeftLeftRightZero left right p =+  plusLeftCancel left right Z $+    rewrite plusZeroRightNeutral left in+      p  -- Mult-total multZeroLeftZero : (right : Nat) -> Z * right = Z-multZeroLeftZero right = Refl+multZeroLeftZero : (right : Nat) -> Z * right = Z+multZeroLeftZero _ = Refl -total multZeroRightZero : (left : Nat) -> left * Z = Z+multZeroRightZero : (left : Nat) -> left * Z = Z multZeroRightZero Z        = Refl multZeroRightZero (S left) = multZeroRightZero left -total multRightSuccPlus : (left : Nat) -> (right : Nat) ->+multRightSuccPlus : (left, right : Nat) ->   left * (S right) = left + (left * right)-multRightSuccPlus Z        right = Refl+multRightSuccPlus Z _ = Refl multRightSuccPlus (S left) right =-  let inductiveHypothesis = multRightSuccPlus left right in-    rewrite inductiveHypothesis in-    rewrite plusAssociative left right (mult left right) in-    rewrite plusAssociative right left (mult left right) in-    rewrite plusCommutative right left in-            Refl+  rewrite multRightSuccPlus left right in+  rewrite plusAssociative left right (left * right) in+  rewrite plusAssociative right left (left * right) in+  rewrite plusCommutative right left in+          Refl -total multLeftSuccPlus : (left : Nat) -> (right : Nat) ->+multLeftSuccPlus : (left, right : Nat) ->   (S left) * right = right + (left * right)-multLeftSuccPlus left right = Refl+multLeftSuccPlus _ _ = Refl -total multCommutative : (left : Nat) -> (right : Nat) ->-  left * right = right * left-multCommutative Z right        = rewrite multZeroRightZero right in Refl+multCommutative : (left, right : Nat) -> left * right = right * left+multCommutative Z right = rewrite multZeroRightZero right in Refl multCommutative (S left) right =-  let inductiveHypothesis = multCommutative left right in-      rewrite inductiveHypothesis in-      rewrite multRightSuccPlus right left in-              Refl--total multDistributesOverPlusRight : (left : Nat) -> (centre : Nat) -> (right : Nat) ->-  left * (centre + right) = (left * centre) + (left * right)-multDistributesOverPlusRight Z        centre right = Refl-multDistributesOverPlusRight (S left) centre right =-  let inductiveHypothesis = multDistributesOverPlusRight left centre right in-    rewrite inductiveHypothesis in-    rewrite plusAssociative (plus centre (mult left centre)) right (mult left right) in-    rewrite sym (plusAssociative centre (mult left centre) right) in-    rewrite plusCommutative (mult left centre) right in-    rewrite plusAssociative centre right (mult left centre) in-    rewrite plusAssociative (plus centre right) (mult left centre) (mult left right) in-            Refl+  rewrite multCommutative left right in+  rewrite multRightSuccPlus right left in+          Refl -total multDistributesOverPlusLeft : (left : Nat) -> (centre : Nat) -> (right : Nat) ->+multDistributesOverPlusLeft : (left, centre, right : Nat) ->   (left + centre) * right = (left * right) + (centre * right)-multDistributesOverPlusLeft Z        centre right = Refl-multDistributesOverPlusLeft (S left) centre right =-  let inductiveHypothesis = multDistributesOverPlusLeft left centre right in-    rewrite inductiveHypothesis in-    rewrite plusAssociative right (mult left right) (mult centre right) in-            Refl+multDistributesOverPlusLeft Z _ _ = Refl+multDistributesOverPlusLeft (S k) centre right =+  rewrite multDistributesOverPlusLeft k centre right in+    rewrite plusAssociative right (k * right) (centre * right) in+      Refl -total multAssociative : (left : Nat) -> (centre : Nat) -> (right : Nat) ->+multDistributesOverPlusRight : (left, centre, right : Nat) ->+  left * (centre + right) = (left * centre) + (left * right)+multDistributesOverPlusRight left centre right =+  rewrite multCommutative left (centre + right) in+    rewrite multCommutative left centre in+      rewrite multCommutative left right in+  multDistributesOverPlusLeft centre right left++multAssociative : (left, centre, right : Nat) ->   left * (centre * right) = (left * centre) * right-multAssociative Z        centre right = Refl+multAssociative Z _ _ = Refl multAssociative (S left) centre right =   let inductiveHypothesis = multAssociative left centre right in     rewrite inductiveHypothesis in     rewrite multDistributesOverPlusLeft centre (mult left centre) right in             Refl -total multOneLeftNeutral : (right : Nat) -> 1 * right = right-multOneLeftNeutral Z         = Refl-multOneLeftNeutral (S right) =-  let inductiveHypothesis = multOneLeftNeutral right in-    rewrite inductiveHypothesis in-            Refl+multOneLeftNeutral : (right : Nat) -> 1 * right = right+multOneLeftNeutral right = plusZeroRightNeutral right -total multOneRightNeutral : (left : Nat) -> left * 1 = left-multOneRightNeutral Z        = Refl-multOneRightNeutral (S left) =-  let inductiveHypothesis = multOneRightNeutral left in-    rewrite inductiveHypothesis in-            Refl+multOneRightNeutral : (left : Nat) -> left * 1 = left+multOneRightNeutral left = rewrite multCommutative left 1 in multOneLeftNeutral left  -- Minus-total minusSuccSucc : (left : Nat) -> (right : Nat) ->+minusSuccSucc : (left, right : Nat) ->   minus (S left) (S right) = minus left right-minusSuccSucc left right = Refl+minusSuccSucc _ _ = Refl -total minusZeroLeft : (right : Nat) -> minus 0 right = Z-minusZeroLeft right = Refl+minusZeroLeft : (right : Nat) -> minus 0 right = Z+minusZeroLeft _ = Refl -total minusZeroRight : (left : Nat) -> minus left 0 = left-minusZeroRight Z        = Refl-minusZeroRight (S left) = Refl+minusZeroRight : (left : Nat) -> minus left 0 = left+minusZeroRight Z     = Refl+minusZeroRight (S _) = Refl -total minusZeroN : (n : Nat) -> Z = minus n n+minusZeroN : (n : Nat) -> Z = minus n n minusZeroN Z     = Refl minusZeroN (S n) = minusZeroN n -total minusOneSuccN : (n : Nat) -> S Z = minus (S n) n+minusOneSuccN : (n : Nat) -> S Z = minus (S n) n minusOneSuccN Z     = Refl minusOneSuccN (S n) = minusOneSuccN n -total minusSuccOne : (n : Nat) -> minus (S n) 1 = n+minusSuccOne : (n : Nat) -> minus (S n) 1 = n minusSuccOne Z     = Refl-minusSuccOne (S n) = Refl+minusSuccOne (S _) = Refl -total minusPlusZero : (n : Nat) -> (m : Nat) -> minus n (n + m) = Z-minusPlusZero Z     m = Refl+minusPlusZero : (n, m : Nat) -> minus n (n + m) = Z+minusPlusZero Z     _ = Refl minusPlusZero (S n) m = minusPlusZero n m -total minusMinusMinusPlus : (left : Nat) -> (centre : Nat) -> (right : Nat) ->+minusMinusMinusPlus : (left, centre, right : Nat) ->   minus (minus left centre) right = minus left (centre + right)-minusMinusMinusPlus Z        Z          right = Refl-minusMinusMinusPlus (S left) Z          right = Refl-minusMinusMinusPlus Z        (S centre) right = Refl+minusMinusMinusPlus Z Z _ = Refl+minusMinusMinusPlus (S _) Z _ = Refl+minusMinusMinusPlus Z (S _) _ = Refl minusMinusMinusPlus (S left) (S centre) right =-  let inductiveHypothesis = minusMinusMinusPlus left centre right in-    rewrite inductiveHypothesis in-            Refl+  rewrite minusMinusMinusPlus left centre right in Refl -total plusMinusLeftCancel : (left : Nat) -> (right : Nat) -> (right' : Nat) ->+plusMinusLeftCancel : (left, right : Nat) -> (right' : Nat) ->   minus (left + right) (left + right') = minus right right'-plusMinusLeftCancel Z right right'        = Refl+plusMinusLeftCancel Z _ _ = Refl plusMinusLeftCancel (S left) right right' =-  let inductiveHypothesis = plusMinusLeftCancel left right right' in-    rewrite inductiveHypothesis in-            Refl+  rewrite plusMinusLeftCancel left right right' in Refl -total multDistributesOverMinusLeft : (left : Nat) -> (centre : Nat) -> (right : Nat) ->+multDistributesOverMinusLeft : (left, centre, right : Nat) ->   (minus left centre) * right = minus (left * right) (centre * right)-multDistributesOverMinusLeft Z        Z          right = Refl-multDistributesOverMinusLeft (S left) Z          right =-    rewrite (minusZeroRight (plus right (mult left right))) in Refl-multDistributesOverMinusLeft Z        (S centre) right = Refl+multDistributesOverMinusLeft Z Z _ = Refl+multDistributesOverMinusLeft (S left) Z right =+  rewrite minusZeroRight (right + (left * right)) in Refl+multDistributesOverMinusLeft Z (S _) _ = Refl multDistributesOverMinusLeft (S left) (S centre) right =-  let inductiveHypothesis = multDistributesOverMinusLeft left centre right in-    rewrite inductiveHypothesis in-    rewrite plusMinusLeftCancel right (mult left right) (mult centre right) in-            Refl+  rewrite multDistributesOverMinusLeft left centre right in+  rewrite plusMinusLeftCancel right (left * right) (centre * right) in+          Refl -total multDistributesOverMinusRight : (left : Nat) -> (centre : Nat) -> (right : Nat) ->+multDistributesOverMinusRight : (left, centre, right : Nat) ->   left * (minus centre right) = minus (left * centre) (left * right) multDistributesOverMinusRight left centre right =     rewrite multCommutative left (minus centre right) in@@ -671,172 +638,152 @@             Refl  -- Power-total powerSuccPowerLeft : (base : Nat) -> (exp : Nat) -> power base (S exp) =+powerSuccPowerLeft : (base, exp : Nat) -> power base (S exp) =   base * (power base exp)-powerSuccPowerLeft base exp = Refl+powerSuccPowerLeft _ _ = Refl -total multPowerPowerPlus : (base : Nat) -> (exp : Nat) -> (exp' : Nat) ->+multPowerPowerPlus : (base, exp : Nat) -> (exp' : Nat) ->   (power base exp) * (power base exp') = power base (exp + exp') multPowerPowerPlus base Z       exp' =-    rewrite sym (plusZeroRightNeutral (power base exp')) in Refl+    rewrite sym $ plusZeroRightNeutral (power base exp') in Refl multPowerPowerPlus base (S exp) exp' =   let inductiveHypothesis = multPowerPowerPlus base exp exp' in     rewrite sym inductiveHypothesis in     rewrite sym (multAssociative base (power base exp) (power base exp')) in             Refl -total powerZeroOne : (base : Nat) -> power base 0 = S Z-powerZeroOne base = Refl+powerZeroOne : (base : Nat) -> power base 0 = S Z+powerZeroOne _ = Refl -total powerOneNeutral : (base : Nat) -> power base 1 = base-powerOneNeutral Z        = Refl-powerOneNeutral (S base) =-  let inductiveHypothesis = powerOneNeutral base in-    rewrite inductiveHypothesis in Refl+powerOneNeutral : (base : Nat) -> power base 1 = base+powerOneNeutral base = rewrite multCommutative base 1 in multOneLeftNeutral base -total powerOneSuccOne : (exp : Nat) -> power 1 exp = S Z+powerOneSuccOne : (exp : Nat) -> power 1 exp = S Z powerOneSuccOne Z       = Refl-powerOneSuccOne (S exp) =-  let inductiveHypothesis = powerOneSuccOne exp in-    rewrite inductiveHypothesis in Refl+powerOneSuccOne (S exp) = rewrite powerOneSuccOne exp in Refl -total powerSuccSuccMult : (base : Nat) -> power base 2 = mult base base-powerSuccSuccMult Z        = Refl-powerSuccSuccMult (S base) = rewrite multOneRightNeutral base in Refl+powerSuccSuccMult : (base : Nat) -> power base 2 = mult base base+powerSuccSuccMult base = rewrite multOneRightNeutral base in Refl -total powerPowerMultPower : (base : Nat) -> (exp : Nat) -> (exp' : Nat) ->+powerPowerMultPower : (base, exp : Nat) -> (exp' : Nat) ->   power (power base exp) exp' = power base (exp * exp')-powerPowerMultPower base exp Z        = rewrite multZeroRightZero exp in Refl+powerPowerMultPower _ exp Z = rewrite multZeroRightZero exp in Refl powerPowerMultPower base exp (S exp') =-  let inductiveHypothesis = powerPowerMultPower base exp exp' in-    rewrite inductiveHypothesis in-    rewrite multRightSuccPlus exp exp' in-    rewrite sym (multPowerPowerPlus base exp (mult exp exp')) in-            Refl+  rewrite powerPowerMultPower base exp exp' in+  rewrite multRightSuccPlus exp exp' in+  rewrite sym $ multPowerPowerPlus base exp (exp * exp') in+          Refl  -- Pred-total predSucc : (n : Nat) -> pred (S n) = n-predSucc n = Refl+predSucc : (n : Nat) -> pred (S n) = n+predSucc _ = Refl -total minusSuccPred : (left : Nat) -> (right : Nat) ->+minusSuccPred : (left, right : Nat) ->   minus left (S right) = pred (minus left right)-minusSuccPred Z        right = Refl-minusSuccPred (S left) Z =-    rewrite minusZeroRight left in Refl-minusSuccPred (S left) (S right) =-  let inductiveHypothesis = minusSuccPred left right in-    rewrite inductiveHypothesis in Refl+minusSuccPred Z _ = Refl+minusSuccPred (S left) Z = rewrite minusZeroRight left in Refl+minusSuccPred (S left) (S right) = rewrite minusSuccPred left right in Refl  -- ifThenElse-total ifThenElseSuccSucc : (cond : Bool) -> (t : Nat) -> (f : Nat) ->+ifThenElseSuccSucc : (cond : Bool) -> (t, f : Nat) ->   S (ifThenElse cond t f) = ifThenElse cond (S t) (S f)-ifThenElseSuccSucc True  t f = Refl-ifThenElseSuccSucc False t f = Refl+ifThenElseSuccSucc True  _ _ = Refl+ifThenElseSuccSucc False _ _ = Refl -total ifThenElsePlusPlusLeft : (cond : Bool) -> (left : Nat) -> (t : Nat) -> (f : Nat) ->+ifThenElsePlusPlusLeft : (cond : Bool) -> (left, t, f : Nat) ->   left + (ifThenElse cond t f) = ifThenElse cond (left + t) (left + f)-ifThenElsePlusPlusLeft True  left t f = Refl-ifThenElsePlusPlusLeft False left t f = Refl+ifThenElsePlusPlusLeft True  _ _ _ = Refl+ifThenElsePlusPlusLeft False _ _ _ = Refl -total ifThenElsePlusPlusRight : (cond : Bool) -> (right : Nat) -> (t : Nat) -> (f : Nat) ->+ifThenElsePlusPlusRight : (cond : Bool) -> (right, t, f : Nat) ->   (ifThenElse cond t f) + right = ifThenElse cond (t + right) (f + right)-ifThenElsePlusPlusRight True  right t f = Refl-ifThenElsePlusPlusRight False right t f = Refl+ifThenElsePlusPlusRight True  _ _ _ = Refl+ifThenElsePlusPlusRight False _ _ _ = Refl -total ifThenElseMultMultLeft : (cond : Bool) -> (left : Nat) -> (t : Nat) -> (f : Nat) ->+ifThenElseMultMultLeft : (cond : Bool) -> (left, t, f : Nat) ->   left * (ifThenElse cond t f) = ifThenElse cond (left * t) (left * f)-ifThenElseMultMultLeft True  left t f = Refl-ifThenElseMultMultLeft False left t f = Refl+ifThenElseMultMultLeft True  _ _ _ = Refl+ifThenElseMultMultLeft False _ _ _ = Refl -total ifThenElseMultMultRight : (cond : Bool) -> (right : Nat) -> (t : Nat) -> (f : Nat) ->+ifThenElseMultMultRight : (cond : Bool) -> (right, t, f : Nat) ->   (ifThenElse cond t f) * right = ifThenElse cond (t * right) (f * right)-ifThenElseMultMultRight True  right t f = Refl-ifThenElseMultMultRight False right t f = Refl+ifThenElseMultMultRight True  _ _ _ = Refl+ifThenElseMultMultRight False _ _ _ = Refl  -- Orders-total lteNTrue : (n : Nat) -> lte n n = True+lteNTrue : (n : Nat) -> lte n n = True lteNTrue Z     = Refl lteNTrue (S n) = lteNTrue n -total LTESuccZeroFalse : (n : Nat) -> lte (S n) Z = False+LTESuccZeroFalse : (n : Nat) -> lte (S n) Z = False LTESuccZeroFalse Z     = Refl LTESuccZeroFalse (S n) = Refl  -- Minimum and maximum-total maximumAssociative : (l,c,r : Nat) -> maximum l (maximum c r) = maximum (maximum l c) r-maximumAssociative Z c r = Refl-maximumAssociative (S k) Z r = Refl-maximumAssociative (S k) (S j) Z = Refl+maximumAssociative : (l,c,r : Nat) -> maximum l (maximum c r) = maximum (maximum l c) r+maximumAssociative Z _ _ = Refl+maximumAssociative (S _) Z _ = Refl+maximumAssociative (S _) (S _) Z = Refl maximumAssociative (S k) (S j) (S i) = rewrite maximumAssociative k j i in Refl -total maximumCommutative : (l, r : Nat) -> maximum l r = maximum r l+maximumCommutative : (l, r : Nat) -> maximum l r = maximum r l maximumCommutative Z Z = Refl-maximumCommutative Z (S k) = Refl-maximumCommutative (S k) Z = Refl+maximumCommutative Z (S _) = Refl+maximumCommutative (S _) Z = Refl maximumCommutative (S k) (S j) = rewrite maximumCommutative k j in Refl -total maximumIdempotent : (n : Nat) -> maximum n n = n+maximumIdempotent : (n : Nat) -> maximum n n = n maximumIdempotent Z = Refl-maximumIdempotent (S k) = cong (maximumIdempotent k)+maximumIdempotent (S k) = cong $ maximumIdempotent k -total minimumAssociative : (l,c,r : Nat) -> minimum l (minimum c r) = minimum (minimum l c) r-minimumAssociative Z c r = Refl-minimumAssociative (S k) Z r = Refl-minimumAssociative (S k) (S j) Z = Refl+minimumAssociative : (l,c,r : Nat) -> minimum l (minimum c r) = minimum (minimum l c) r+minimumAssociative Z _ _ = Refl+minimumAssociative (S _) Z _ = Refl+minimumAssociative (S _) (S _) Z = Refl minimumAssociative (S k) (S j) (S i) = rewrite minimumAssociative k j i in Refl -total minimumCommutative : (l, r : Nat) -> minimum l r = minimum r l+minimumCommutative : (l, r : Nat) -> minimum l r = minimum r l minimumCommutative Z Z = Refl-minimumCommutative Z (S k) = Refl-minimumCommutative (S k) Z = Refl+minimumCommutative Z (S _) = Refl+minimumCommutative (S _) Z = Refl minimumCommutative (S k) (S j) = rewrite minimumCommutative k j in Refl -total minimumIdempotent : (n : Nat) -> minimum n n = n+minimumIdempotent : (n : Nat) -> minimum n n = n minimumIdempotent Z = Refl minimumIdempotent (S k) = cong (minimumIdempotent k) -total minimumZeroZeroRight : (right : Nat) -> minimum 0 right = Z-minimumZeroZeroRight Z = Refl-minimumZeroZeroRight (S right) = minimumZeroZeroRight right+minimumZeroZeroRight : (right : Nat) -> minimum 0 right = Z+minimumZeroZeroRight _ = Refl -total minimumZeroZeroLeft : (left : Nat) -> minimum left 0 = Z-minimumZeroZeroLeft Z        = Refl-minimumZeroZeroLeft (S left) = Refl+minimumZeroZeroLeft : (left : Nat) -> minimum left 0 = Z+minimumZeroZeroLeft left = rewrite minimumCommutative left 0 in Refl -total minimumSuccSucc : (left : Nat) -> (right : Nat) ->+minimumSuccSucc : (left, right : Nat) ->   minimum (S left) (S right) = S (minimum left right)-minimumSuccSucc Z        Z         = Refl-minimumSuccSucc (S left) Z         = Refl-minimumSuccSucc Z        (S right) = Refl-minimumSuccSucc (S left) (S right) = Refl+minimumSuccSucc _ _ = Refl -total maximumZeroNRight : (right : Nat) -> maximum Z right = right-maximumZeroNRight Z         = Refl-maximumZeroNRight (S right) = Refl+maximumZeroNRight : (right : Nat) -> maximum Z right = right+maximumZeroNRight right = Refl -total maximumZeroNLeft : (left : Nat) -> maximum left Z = left-maximumZeroNLeft Z        = Refl-maximumZeroNLeft (S left) = Refl+maximumZeroNLeft : (left : Nat) -> maximum left Z = left+maximumZeroNLeft left = rewrite maximumCommutative left Z in Refl -total maximumSuccSucc : (left : Nat) -> (right : Nat) ->+maximumSuccSucc : (left, right : Nat) ->   S (maximum left right) = maximum (S left) (S right)-maximumSuccSucc Z        Z         = Refl-maximumSuccSucc (S left) Z         = Refl-maximumSuccSucc Z        (S right) = Refl-maximumSuccSucc (S left) (S right) = Refl+maximumSuccSucc _ _ = Refl -total sucMaxL : (l : Nat) -> maximum (S l) l = (S l)+sucMaxL : (l : Nat) -> maximum (S l) l = (S l) sucMaxL Z = Refl-sucMaxL (S l) = cong (sucMaxL l)+sucMaxL (S l) = cong $ sucMaxL l -total sucMaxR : (l : Nat) -> maximum l (S l) = (S l)+sucMaxR : (l : Nat) -> maximum l (S l) = (S l) sucMaxR Z = Refl-sucMaxR (S l) = cong (sucMaxR l)+sucMaxR (S l) = cong $ sucMaxR l -total sucMinL : (l : Nat) -> minimum (S l) l = l+sucMinL : (l : Nat) -> minimum (S l) l = l sucMinL Z = Refl-sucMinL (S l) = cong (sucMinL l)+sucMinL (S l) = cong $ sucMinL l -total sucMinR : (l : Nat) -> minimum l (S l) = l+sucMinR : (l : Nat) -> minimum l (S l) = l sucMinR Z = Refl-sucMinR (S l) = cong (sucMinR l)+sucMinR (S l) = cong $ sucMinR l
− logos/logo-text.svg 
@@ -1,150 +0,0 @@-<?xml version="1.0" encoding="UTF-8" standalone="no"?>-<!-- Created with VectorDraw -->--<svg-   xmlns:osb="http://www.openswatchbook.org/uri/2009/osb"-   xmlns:dc="http://purl.org/dc/elements/1.1/"-   xmlns:cc="http://creativecommons.org/ns#"-   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"-   xmlns:svg="http://www.w3.org/2000/svg"-   xmlns="http://www.w3.org/2000/svg"-   xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"-   xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"-   width="595.000000"-   height="841.000000"-   id="svg2"-   version="1.1"-   inkscape:version="0.91 r13725"-   sodipodi:docname="logo3-text.svg"-   inkscape:export-filename="/Users/edwin/Idris/Logos/logo3-text.png"-   inkscape:export-xdpi="90"-   inkscape:export-ydpi="90">-  <metadata-     id="metadata11">-    <rdf:RDF>-      <cc:Work-         rdf:about="">-        <dc:format>image/svg+xml</dc:format>-        <dc:type-           rdf:resource="http://purl.org/dc/dcmitype/StillImage" />-        <dc:title></dc:title>-      </cc:Work>-    </rdf:RDF>-  </metadata>-  <defs-     id="defs9">-    <linearGradient-       id="linearGradient5872"-       osb:paint="solid">-      <stop-         style="stop-color:#000000;stop-opacity:1;"-         offset="0"-         id="stop5874" />-    </linearGradient>-    <inkscape:perspective-       sodipodi:type="inkscape:persp3d"-       inkscape:vp_x="0 : 420.5 : 1"-       inkscape:vp_y="0 : 1000 : 0"-       inkscape:vp_z="595 : 420.5 : 1"-       inkscape:persp3d-origin="297.5 : 280.33333 : 1"-       id="perspective3611" />-    <filter-       style="color-interpolation-filters:sRGB;"-       inkscape:label="Drop Shadow"-       id="filter5878">-      <feFlood-         flood-opacity="0.498039"-         flood-color="rgb(0,0,0)"-         result="flood"-         id="feFlood5880" />-      <feComposite-         in="flood"-         in2="SourceGraphic"-         operator="in"-         result="composite1"-         id="feComposite5882" />-      <feGaussianBlur-         in="composite1"-         stdDeviation="3"-         result="blur"-         id="feGaussianBlur5884" />-      <feOffset-         dx="6"-         dy="6"-         result="offset"-         id="feOffset5886" />-      <feComposite-         in="SourceGraphic"-         in2="offset"-         operator="over"-         result="composite2"-         id="feComposite5888" />-    </filter>-  </defs>-  <sodipodi:namedview-     pagecolor="#ffffff"-     bordercolor="#666666"-     borderopacity="1"-     objecttolerance="10"-     gridtolerance="10"-     guidetolerance="10"-     inkscape:pageopacity="0"-     inkscape:pageshadow="2"-     inkscape:window-width="1408"-     inkscape:window-height="845"-     id="namedview7"-     showgrid="false"-     inkscape:zoom="2.2991361"-     inkscape:cx="215.71271"-     inkscape:cy="745.84286"-     inkscape:window-x="14"-     inkscape:window-y="0"-     inkscape:window-maximized="0"-     inkscape:current-layer="" />-  <g-     inkscape:label=""-     inkscape:groupmode="layer"-     id="">-    <g-       id="g3353"-       transform="matrix(0.32905346,0,0,0.32905346,7.0998413,0.25431021)"-       style="image-rendering:auto;fill:#aa0000;stroke:none;stroke-opacity:1;filter:url(#filter5878)"-       inkscape:export-xdpi="35.079365"-       inkscape:export-ydpi="35.079365">-      <path-         inkscape:connector-curvature="0"-         id="path3345"-         d="M 79.07716,85.235105 C 152.15731,107.3516 170.85211,125.57188 196.54561,191.60466 191.5621,111.08837 159.33816,77.523083 79.07716,85.235105 c 18.82716,-67.890093 0,0 0,0 z"-         style="fill:#aa0000;fill-opacity:1;stroke:none;stroke-opacity:1" />-      <path-         inkscape:connector-curvature="0"-         id="path3343"-         d="M -22.207669,211.87449 C 25.234912,226.48437 80.323859,238.15903 100.68023,328.79942 109.08411,215.72166 55.546121,209.96088 -22.207669,211.87449 c 90.648682,-302.180016 0,0 0,0 z"-         style="fill:#aa0000;fill-opacity:1;stroke:none;stroke-opacity:1" />-      <path-         inkscape:connector-curvature="0"-         id="path3341"-         d="M 9.8483347,139.76992 C 81.136615,154.50235 126.58014,173.85823 153.14004,265.85432 159.23348,147.17442 94.093917,135.25771 9.8483347,139.76992 c 78.3893863,-131.1880199 0,0 0,0 z"-         style="fill:#aa0000;fill-opacity:1;stroke:none;stroke-opacity:1" />-      <path-         id="path5"-         d="M 103.33025,0.379032 C 492.35181,254.04105 16.917801,258.5227 120.33008,553.01685 c 0,0 61.21588,17.8269 61.21588,17.8269 C 12.902722,342.22024 556.89801,224.698 103.33025,0.379032 c 0,0 0,0 0,0 z"-         style="fill:#aa0000;fill-opacity:1;stroke:none;stroke-opacity:1"-         inkscape:connector-curvature="0" />-    </g>-    <text-       xml:space="preserve"-       style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:173.13887024px;line-height:125%;font-family:'TeX Gyre Pagella';-inkscape-font-specification:'TeX Gyre Pagella, Normal';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"-       x="123.74978"-       y="186.47948"-       id="text3569"-       sodipodi:linespacing="125%"-       transform="scale(1.0060826,0.99395418)"-       inkscape:export-xdpi="35.079365"-       inkscape:export-ydpi="35.079365"><tspan-         sodipodi:role="line"-         id="tspan3571"-         x="123.74978"-         y="186.47948">Idris</tspan></text>-  </g>-</svg>
− logos/logo.svg 
@@ -1,80 +0,0 @@-<?xml version="1.0" encoding="UTF-8" standalone="no"?>-<!-- Created with VectorDraw -->--<svg-   xmlns:dc="http://purl.org/dc/elements/1.1/"-   xmlns:cc="http://creativecommons.org/ns#"-   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"-   xmlns:svg="http://www.w3.org/2000/svg"-   xmlns="http://www.w3.org/2000/svg"-   xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"-   xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"-   width="595.000000"-   height="841.000000"-   id="svg2"-   version="1.1"-   inkscape:version="0.91 r13725"-   sodipodi:docname="logo2.svg">-  <metadata-     id="metadata11">-    <rdf:RDF>-      <cc:Work-         rdf:about="">-        <dc:format>image/svg+xml</dc:format>-        <dc:type-           rdf:resource="http://purl.org/dc/dcmitype/StillImage" />-      </cc:Work>-    </rdf:RDF>-  </metadata>-  <defs-     id="defs9" />-  <sodipodi:namedview-     pagecolor="#ffffff"-     bordercolor="#666666"-     borderopacity="1"-     objecttolerance="10"-     gridtolerance="10"-     guidetolerance="10"-     inkscape:pageopacity="0"-     inkscape:pageshadow="2"-     inkscape:window-width="1198"-     inkscape:window-height="1598"-     id="namedview7"-     showgrid="false"-     inkscape:zoom="0.56123662"-     inkscape:cx="52.74404"-     inkscape:cy="241.68009"-     inkscape:window-x="1280"-     inkscape:window-y="0"-     inkscape:window-maximized="0"-     inkscape:current-layer="" />-  <g-     inkscape:label=""-     inkscape:groupmode="layer"-     id="">-    <g-       id="g3353"-       transform="translate(22,0)">-      <path-         inkscape:connector-curvature="0"-         id="path3345"-         d="M 79.07716,85.235105 C 152.15731,107.3516 170.85211,125.57188 196.54561,191.60466 191.5621,111.08837 159.33816,77.523083 79.07716,85.235105 c 18.82716,-67.890093 0,0 0,0 z"-         style="fill:#8a0819;fill-opacity:1;stroke:none" />-      <path-         inkscape:connector-curvature="0"-         id="path3343"-         d="M -22.207669,211.87449 C 25.234912,226.48437 80.323859,238.15903 100.68023,328.79942 109.08411,215.72166 55.546121,209.96088 -22.207669,211.87449 c 90.648682,-302.180016 0,0 0,0 z"-         style="fill:#8a0819;fill-opacity:1;stroke:none" />-      <path-         inkscape:connector-curvature="0"-         id="path3341"-         d="M 9.8483347,139.76992 C 81.136615,154.50235 126.58014,173.85823 153.14004,265.85432 159.23348,147.17442 94.093917,135.25771 9.8483347,139.76992 c 78.3893863,-131.1880199 0,0 0,0 z"-         style="fill:#8a0819;fill-opacity:1;stroke:none" />-      <path-         id="path5"-         d="M 103.33025,0.379032 C 492.35181,254.04105 16.917801,258.5227 120.33008,553.01685 c 0,0 61.21588,17.8269 61.21588,17.8269 C 12.902722,342.22024 556.89801,224.698 103.33025,0.379032 c 0,0 0,0 0,0 z"-         style="fill:#8a0819;fill-opacity:1;stroke:none"-         inkscape:connector-curvature="0" />-    </g>-  </g>-</svg>
man/idris.1 view
@@ -1,6 +1,6 @@ .\" Manpage for Idris. .\" Contact <> to correct errors or typos.-.TH man 1 "23 October 2018" "1.3.2" "Idris man page"+.TH man 1 "23 May 2020" "1.3.3" "Idris man page" .SH NAME idris -\ a general purpose pure functional programming language with dependent types. .SH SYNOPSIS@@ -113,7 +113,7 @@  .SH SEE ALSO -+ The IDRIS web site (http://idris-lang.org/++ The IDRIS web site (https://idris-lang.org/  +  The IRC channel #idris, on chat.freenode.net
rts/idris_bitstring.c view
@@ -1,5 +1,3 @@-#include <assert.h>- #include "idris_rts.h"  VAL idris_b8const(VM *vm, uint8_t a) {
rts/idris_gmp.c view
@@ -202,10 +202,10 @@         i_int vy = GETINT(y);         // we could work out likelihood of overflow by checking the number         // of necessary bits. Here's a quick conservative hack instead.-        if ((vx < (1<<15) && vy < (1<16)) ||-            (vx < (1<<16) && vy < (1<15)) ||-            (vx < (1<<20) && vy < (1<11)) ||-            (vx < (1<<11) && vy < (1<20)) ||+        if ((vx < (1<<15) && vy < (1<<16)) ||+            (vx < (1<<16) && vy < (1<<15)) ||+            (vx < (1<<20) && vy < (1<<11)) ||+            (vx < (1<<11) && vy < (1<<20)) ||             (vx < (1<<23) && vy < (1<<8)) ||             (vx < (1<<8) && vy < (1<<23))) { // ultra-conservative!             return INTOP(*,x,y);
rts/idris_rts.c view
@@ -242,6 +242,13 @@             vm->heap.size += size;         }         idris_gc(vm);++        // If there's still not enough room, grow the heap and try again+        if (vm->heap.next + size >= vm->heap.end) {+            vm->heap.size += size+vm->heap.growth;+            idris_gc(vm);+        }+ #ifdef HAS_PTHREAD         if (lock) { // not message passing            pthread_mutex_unlock(&vm->alloc_lock);@@ -1150,16 +1157,6 @@   setvbuf(stdin, NULL, _IONBF, 0);   setvbuf(stdout, NULL, _IONBF, 0); }--#ifndef SEL4-int idris_usleep(int usec) {-    struct timespec t;-    t.tv_sec = usec / 1000000;-    t.tv_nsec = (usec % 1000000) * 1000;--    return nanosleep(&t, NULL);-}-#endif // SEL4  void stackOverflow(void) {   fprintf(stderr, "Stack overflow");
rts/idris_rts.h view
@@ -291,6 +291,9 @@     if (vm->valstack_top+(x) > vm->stack_max) { stackOverflow(); } \     else { memset(vm->valstack_top, 0, (x)*sizeof(VAL)); } \   } while(0)+#define RESERVENOALLOC(x) do { \+    if (vm->valstack_top+(x) > vm->stack_max) { stackOverflow(); } \+  } while(0) #define ADDTOP(x) vm->valstack_top += (x) #define TOPBASE(x) vm->valstack_top = vm->valstack_base + (x) #define BASETOP(x) vm->valstack_base = vm->valstack_top + (x)@@ -355,7 +358,7 @@ void* idris_realloc(void* old, size_t old_size, size_t size); void idris_free(void* ptr, size_t size); -static inline void updateConF(Con * cl, unsigned tag, unsigned arity) {+static inline void updateConF(Con * cl, uint32_t tag, uint16_t arity) {     SETTY(cl, CT_CON);     cl->tag = tag;     // hdr.u16 used to store arity@@ -364,7 +367,7 @@     // cl->hdr.sz = sizeof(*cl) + sizeof(VAL) * arity; } -static inline Con * allocConF(VM * vm, unsigned tag, unsigned arity, int outer) {+static inline Con * allocConF(VM * vm, uint32_t tag, uint16_t arity, int outer) {     Con * cl = iallocate(vm, sizeof(*cl) + sizeof(VAL) * arity, outer);     SETTY(cl, CT_CON);     cl->tag = tag;@@ -503,10 +506,6 @@  // disable stdin/stdout buffering void idris_disableBuffering(void);--#ifndef SEL4-int idris_usleep(int usec);-#endif // SEL4  // Handle stack overflow. // Just reports an error and exits.
rts/idris_stdfgn.c view
@@ -74,13 +74,13 @@     } } -VAL fileModifiedTime(void* h) {+VAL fileModifiedTime(VM* vm, void* h) {     FILE* f = (FILE*)h;     int fd = fileno(f);      struct stat buf;     if (fstat(fd, &buf) == 0) {-        return MKBIGI(buf.st_mtime);+        return MKBIGUI(vm, buf.st_mtime);     } else {         return MKBIGI(-1);     }@@ -227,6 +227,16 @@ #endif     return result; }++#ifndef SEL4+int idris_usleep(int usec) {+    struct timespec t;+    t.tv_sec = usec / 1000000;+    t.tv_nsec = (usec % 1000000) * 1000;++    return nanosleep(&t, NULL);+}+#endif // SEL4  VAL idris_mkFileError(VM* vm) {     VAL result;
rts/idris_stdfgn.h view
@@ -18,7 +18,7 @@  // Return a negative number if not a file (e.g. directory or device) VAL fileAccessTime(void* h);-VAL fileModifiedTime(void* h);+VAL fileModifiedTime(VM* vm, void* h); VAL fileStatusTime(void* h);  void* idris_dirOpen(char* dname);@@ -54,6 +54,9 @@  VAL idris_time(); VAL idris_clock(VM* vm);+#ifndef SEL4+int idris_usleep(int usec);+#endif // SEL4  void idris_forceGC();
rts/idris_utf8.c view
@@ -1,5 +1,4 @@ #include "idris_utf8.h"-#include <stdio.h> #include <string.h> #include <stdlib.h>
− samples/effects/Makefile 
@@ -1,8 +0,0 @@-check:-	rm -f *.ibc-	for x in *.idr ; do \-	echo "Checking $$x"; \-	idris -p effects --check $$x; \-	done--.PHONY: check
− samples/misc/Makefile 
@@ -1,8 +0,0 @@-check:-	rm -f *.ibc-	for x in *.idr ; do \-	echo "Checking $$x"; \-	idris --check $$x; \-	done--.PHONY: check
− samples/tutorial/Makefile 
@@ -1,11 +0,0 @@-check: .PHONY-	rm -f *.ibc-	for x in *.idr ; do \-	echo "Checking $$x"; \-	idris --check $$x; \-	done--clean:-	rm -f *.ibc--.PHONY:
− src/BuildFlags_idris.hs 
@@ -1,4 +0,0 @@-module BuildFlags_idris where --extraLibDirs :: [String]-extraLibDirs = []
src/IRTS/Bytecode.hs view
@@ -86,6 +86,7 @@     -- | reserve n more stack items (i.e. check there's space, grow if     -- necessary)   | RESERVE Int+  | RESERVENOALLOC Int      -- | move the top of stack up   | ADDTOP Int@@ -127,13 +128,13 @@ bc reg (SApp False f vs) r =       if argCount == 0          then moveReg 0 vs ++ [STOREOLD, BASETOP 0, CALL f] ++ ret-         else RESERVE argCount : moveReg 0 vs +++         else RESERVENOALLOC argCount : moveReg 0 vs ++             [STOREOLD, BASETOP 0, ADDTOP argCount, CALL f] ++ ret    where       ret      = assign reg RVal ++ clean r       argCount = length vs bc reg (SApp True f vs) r-    = RESERVE (length vs) : moveReg 0 vs+    = RESERVENOALLOC (length vs) : moveReg 0 vs       ++ [SLIDE (length vs), TOPBASE (length vs), TAILCALL f] bc reg (SForeign t fname args) r     = FOREIGNCALL reg t fname (map farg args) : clean r
src/IRTS/CodegenC.hs view
@@ -321,6 +321,8 @@ bcc f i REBASE = indent i ++ "REBASE;\n" bcc f i (RESERVE 0) = "" bcc f i (RESERVE n) = indent i ++ "RESERVE(" ++ show n ++ ");\n"+bcc f i (RESERVENOALLOC 0) = ""+bcc f i (RESERVENOALLOC n) = indent i ++ "RESERVENOALLOC(" ++ show n ++ ");\n" bcc f i (ADDTOP 0) = "" bcc f i (ADDTOP n) = indent i ++ "ADDTOP(" ++ show n ++ ");\n" bcc f i (TOPBASE n) = indent i ++ "TOPBASE(" ++ show n ++ ");\n"
src/IRTS/DumpBC.hs view
@@ -63,6 +63,7 @@       SLIDE n -> "SLIDE " ++ show n       REBASE -> "REBASE"       RESERVE n -> "RESERVE " ++ show n+      RESERVENOALLOC n -> "RESERVENOALLOC " ++ show n       ADDTOP n -> "ADDTOP " ++ show n       TOPBASE n -> "TOPBASE " ++ show n       BASETOP n -> "BASETOP " ++ show n
src/IRTS/Portable.hs view
@@ -265,6 +265,7 @@     toJSON (FOREIGNCALL r fd ret exps) = object ["FOREIGNCALL" .= (r, fd, ret, exps)]     toJSON (SLIDE i) = object ["SLIDE" .= i]     toJSON (RESERVE i) = object ["RESERVE" .= i]+    toJSON (RESERVENOALLOC i) = object ["RESERVENOALLOC" .= i]     toJSON (ADDTOP i) = object ["ADDTOP" .= i]     toJSON (TOPBASE i) = object ["TOPBASE" .= i]     toJSON (BASETOP i) = object ["BASETOP" .= i]
src/Idris/CmdOptions.hs view
@@ -18,6 +18,7 @@ import Idris.Options import IRTS.CodegenCommon +import qualified Control.Monad.Fail as Fail import Control.Monad.Trans (lift) import Control.Monad.Trans.Except (throwE) import Control.Monad.Trans.Reader (ask)@@ -71,7 +72,7 @@                                         PP.empty,                                         PP.text "More details over Idris can be found online here:",                                         PP.empty,-                                        PP.indent 4 (PP.text "http://www.idris-lang.org/")]+                                        PP.indent 4 (PP.text "https://www.idris-lang.org/")]  execArgParserPure :: [String] -> ParserResult [Opt] execArgParserPure args = preProcOpts <$> execParserPure (prefs idm) (info parser idm) args@@ -264,7 +265,7 @@ parseCodegen "bytecode" = Bytecode parseCodegen cg         = Via IBCFormat (map toLower cg) -parseLogCats :: Monad m => String -> m [LogCat]+parseLogCats :: Fail.MonadFail m => String -> m [LogCat] parseLogCats s =     case lastMay (readP_to_S doParse s) of       Just (xs, _) -> return xs@@ -290,7 +291,7 @@       s <- look       fail $ "Category: " ++ s ++ " is not recognised." -parseConsoleWidth :: Monad m => String -> m ConsoleWidth+parseConsoleWidth :: Fail.MonadFail m => String -> m ConsoleWidth parseConsoleWidth "auto"     = return AutomaticWidth parseConsoleWidth "infinite" = return InfinitelyWide parseConsoleWidth  s =
src/Idris/Core/CaseTree.hs view
@@ -627,7 +627,7 @@         PConst cval -> return $ addConG cval (ps, res) acc         PSuc n -> return $ addg False CSuc [n] (ps, res) acc         PReflected fn args -> return $ addg False (CFn fn) args (ps, res) acc-        pat -> fail $ show pat ++ " is not a constructor or constant (can't happen)"+        pat -> error $ show pat ++ " is not a constructor or constant (can't happen)"      addg uniq c conargs res []            = [ConGroup uniq c [(conargs, res)]]
src/Idris/Core/TT.hs view
@@ -70,6 +70,7 @@ import Control.Applicative (Alternative, Applicative(..)) import qualified Control.Applicative as A (Alternative(..)) import Control.DeepSeq (($!!))+import qualified Control.Monad.Fail as Fail import Control.Monad.State.Strict import Data.Binary hiding (get, put) import Data.Char@@ -324,6 +325,11 @@ instance Monad TC where     return x = OK x     x >>= k = bindTC x k+#if !(MIN_VERSION_base(4,13,0))+    fail = Fail.fail+#endif++instance Fail.MonadFail TC where     fail e = Error (InternalMsg e)  instance MonadPlus TC where
src/Idris/ModeCommon.hs view
@@ -167,7 +167,7 @@ banner = "     ____    __     _                                          \n" ++          "    /  _/___/ /____(_)____                                     \n" ++          "    / // __  / ___/ / ___/     Version " ++ getIdrisVersion ++ "\n" ++-         "  _/ // /_/ / /  / (__  )      http://www.idris-lang.org/      \n" +++         "  _/ // /_/ / /  / (__  )      https://www.idris-lang.org/     \n" ++          " /___/\\__,_/_/  /_/____/       Type :? for help               \n" ++          "\n" ++          "Idris is free software with ABSOLUTELY NO WARRANTY.            \n" ++
src/Idris/Parser/Stack.hs view
@@ -5,7 +5,7 @@ License     : BSD3 Maintainer  : The Idris Community. -}-{-# LANGUAGE ConstraintKinds, FlexibleContexts, MultiParamTypeClasses #-}+{-# LANGUAGE CPP, ConstraintKinds, FlexibleContexts, MultiParamTypeClasses #-} module Idris.Parser.Stack   ( -- * Parsing     Parser(..)@@ -36,6 +36,7 @@ import Idris.Output (Message(..))  import Control.Arrow (app)+import qualified Control.Monad.Fail as Fail import Control.Monad.State.Strict (StateT(..), evalStateT) import Control.Monad.Writer.Strict (MonadWriter(..), WriterT(..), listen,                                     runWriterT, tell)@@ -51,7 +52,7 @@ type Parser s = StateT s (WriterT FC (P.Parsec Void String))  -- | A constraint for parsing without state-type Parsing m = (P.MonadParsec Void String m, MonadWriter FC m)+type Parsing m = (Fail.MonadFail m, P.MonadParsec Void String m, MonadWriter FC m)  -- | Run the Idris parser stack runparser :: Parser st res -> st -> String -> String -> Either ParseError res@@ -76,11 +77,20 @@ instance Message ParseError where   messageExtent err = sourcePositionFC pos     where+#if MIN_VERSION_megaparsec(8,0,0)+      P.PosState {P.pstateSourcePos = pos} =+        P.reachOffsetNoLine (parseErrorOffset err) (parseErrorPosState err)+#else       (pos, _) = P.reachOffsetNoLine (parseErrorOffset err) (parseErrorPosState err)+#endif   messageText = PP.text . init . P.parseErrorTextPretty . parseError   messageSource err = Just sline     where+#if MIN_VERSION_megaparsec(8,0,0)+      (sline, _) = P.reachOffset (parseErrorOffset err) (parseErrorPosState err)+#else       (_, sline, _) = P.reachOffset (parseErrorOffset err) (parseErrorPosState err)+#endif  -- | A fully formatted parse error, with caret and bar, etc. prettyError :: ParseError -> String@@ -88,7 +98,11 @@  {- * Mark and restore -} +#if MIN_VERSION_megaparsec(8,0,0)+type Mark = P.State String Void+#else type Mark = P.State String+#endif  -- | Retrieve the parser state so we can restart from this point later. mark :: Parsing m => m Mark
src/Idris/Reflection.hs view
@@ -1105,7 +1105,7 @@     ua args t         = (t, args)  -- | Build the reflected function definition(s) that correspond(s) to--- a provided unqualifed name+-- a provided unqualified name buildFunDefns :: IState -> Name -> [RFunDefn Term] buildFunDefns ist n =   [ mkFunDefn name clauses
− src/Target_idris.hs 
@@ -1,13 +0,0 @@-module Target_idris where--import System.FilePath-import System.Environment-getDataDir :: IO String-getDataDir = do -   expath <- getExecutablePath-   execDir <- return $ dropFileName expath-   return $ execDir ++ "./libs"-getDataFileName :: FilePath -> IO FilePath-getDataFileName name = do-   dir <- getDataDir-   return (dir ++ "/" ++ name)
− src/Tools_idris.hs 
@@ -1,4 +0,0 @@-module Tools_idris where--hasBundledToolchain = False-getToolchainDir = ""
− src/Version_idris.hs 
@@ -1,4 +0,0 @@-module Version_idris where--gitHash :: String-gitHash = ""
− stack-alt.yaml 
@@ -1,25 +0,0 @@-#recheck extra-deps next on resolver or cabal file change-resolver: lts-11.4--packages:-  - location: .--extra-deps:-  - network-2.8.0.0@sha256:aae171e6c6028a7791dbe4de5b9d2da398056359e3cc7927465ffa3cdae1aa0b-  - Cabal-2.2.0.1@sha256:2a80d8fb655474f0eaeb20434c47f64f84e6302e55973056f00df8ca050b9683-  - megaparsec-7.0.4-  - parser-combinators-1.0.0-  - zip-archive-0.3.3@sha256:47cf2d66cc8e237f7226837758e1b041e24048ef3820d3d10276c500edb921bf-  - containers-0.5.11.0@sha256:28ad7337057442f75bc689315ab4ec7bdf5e6b2c39668f306672cecd82c02798--flags:-  idris:-    FFI: true-    GMP: true--ghc-options:-  idris: -fwarn-unused-imports -fwarn-unused-binds--nix:-  enable: false-  shell-file: stack-shell.nix
stack.yaml view
@@ -1,24 +1,1 @@-#recheck extra-deps next on resolver or cabal file change-resolver: lts-13.21--extra-deps:-  - network-2.8.0.0@sha256:aae171e6c6028a7791dbe4de5b9d2da398056359e3cc7927465ffa3cdae1aa0b-  - Cabal-2.2.0.1@sha256:2a80d8fb655474f0eaeb20434c47f64f84e6302e55973056f00df8ca050b9683-  - megaparsec-7.0.4-  - parser-combinators-1.0.0-  - zip-archive-0.3.3@sha256:47cf2d66cc8e237f7226837758e1b041e24048ef3820d3d10276c500edb921bf-  - containers-0.5.11.0@sha256:28ad7337057442f75bc689315ab4ec7bdf5e6b2c39668f306672cecd82c02798-  - tasty-rerun-1.1.14@sha256:ba9c19a281535bea566e1044bc02c36ef17abcb310af4b6a149ec11780c7ce35-  - binary-0.8.7.0@sha256:ae3e6cca723ac55c54bbb3fa771bcf18142bc727afd57818e66d6ee6c8044f12--flags:-  idris:-    FFI: true-    GMP: true--ghc-options:-  idris: -fwarn-unused-imports -fwarn-unused-binds--nix:-  enable: false-  shell-file: stack-shell.nix+stack-15.12.yaml
test/README.md view
@@ -113,18 +113,18 @@  1. Choose the family your test shall belong to and remember its identifier. 2. Pick the next available integer in the test family. It will be the index.-3. Say the family's identifier is `foo` and the index is `42`. You should call `./mktest.pl foo042` ; this will create the directory and a simple `run` script.+3. Say the family's identifier is `foo` and the index is `42`. You should call `./mktest.pl foo042` ; this will create the directory and a simple `run.sh` script. 4. Modify the `run` script to your liking. If you want to call the idris executable, write `${IDRIS:-idris} $@`. 5. Add any file you may need in the directory. If they don't end in `.idr`, you should remember them for the next step. 6. Add your test in `TestData.hs`. Each family has a list of `(Index, CompatCodegen)`.  See the next section for the available values in `CompatCodegen`. In most cases, you should write `( 42, ANY)`.-7. Generate the `expected` file by doing:+7. Generate the `expected.out` file by doing:     ```     # Using cabal     cabal test --test-options="--pattern foo042 --accept"     # Using stack     stack test --test-arguments="--pattern foo042 --accept"     ```-8. Check the content of `expected`. Maybe the test didn't do what you thought it would. Fix and go back to 7 until it's ok.+8. Check the content of `expected.out`. Maybe the test didn't do what you thought it would. Fix and go back to 7 until it's ok.  ### Specifying compatible backends @@ -146,7 +146,7 @@  ### Updating golden files -To update the `expected` file for every test, do one of the following:+To update the `expected.out` file for every test, do one of the following:  ``` # Using make@@ -157,4 +157,4 @@ stack test --test-arguments="--accept" ``` -"Accepted" tests are the ones that update the golden file. A test can still fail if the `run` script itself crashes.+"Accepted" tests are the ones that update the golden file. A test can still fail if the `run.sh` script itself crashes.
test/TestRun.hs view
@@ -62,7 +62,7 @@ test :: String -> String -> IO () -> TestTree test testName path = goldenVsFileDiff testName diff ref output   where-    ref = path </> "expected"+    ref = path </> "expected.out"     output = path </> "output"     diff ref new | os == "openbsd" = ["diff", "-u", new, ref]                  | otherwise = ["diff", "--strip-trailing-cr", "-u", new, ref]@@ -92,7 +92,7 @@ -- this thing. runTest :: String -> Flags -> IO () runTest path flags = do-  let run = (proc "bash" ("run" : flags)) {cwd = Just path}+  let run = (proc "bash" ("run.sh" : flags)) {cwd = Just path}   (_, output, error_out) <- readCreateProcessWithExitCode run ""   writeFile (path </> "output") (normalise output)   when (error_out /= "") $ hPutStrLn stderr ("\nError: " ++ path ++ "\n" ++ error_out)
− test/base001/expected 
@@ -1,25 +0,0 @@-Type checking ./base001.idr-exit1: Executing cmd 'exit 1'-exit1: raw exitStatus = 256-exit1: WEXITSTATUS(exitStatus) = 1-exit1: Executing cmd './does-not-exist'-exit1: raw exitStatus = 32512-exit1: WEXITSTATUS(exitStatus) = 127---------------------------------------------Executing 'exit 1'-raw status = 256-exit status = 1-True----------------------------------------------Executing './exit1'-raw status = 256-exit status = 1-True----------------------------------------------Executing './does-not-exist'-raw status = 32512-exit status = 127-True-
+ test/base001/expected.out view
@@ -0,0 +1,25 @@+Type checking ./base001.idr+exit1: Executing cmd 'exit 1'+exit1: raw exitStatus = 256+exit1: WEXITSTATUS(exitStatus) = 1+exit1: Executing cmd './does-not-exist'+exit1: raw exitStatus = 32512+exit1: WEXITSTATUS(exitStatus) = 127+-------------------------------------------+Executing 'exit 1'+raw status = 256+exit status = 1+True++-------------------------------------------+Executing './exit1'+raw status = 256+exit status = 1+True++-------------------------------------------+Executing './does-not-exist'+raw status = 32512+exit status = 127+True+
− test/base001/run 
@@ -1,12 +0,0 @@-#!/usr/bin/env bash--set -u--if [[ ${OSTYPE} = 'msys' ]]; then-  cat expected # skip this test on Windows-else-  ${IDRIS:-idris} "$@" --build base001.ipkg | grep -v 'make.*:'-  ./base001 2>&1 | grep -v '^sh:.*\./does-not-exist:'-  make clean | grep -v 'make.*:'-  rm -f -- *.ibc base001-fi
+ test/base001/run.sh view
@@ -0,0 +1,12 @@+#!/usr/bin/env bash++set -u++if [[ ${OSTYPE} = 'msys' ]]; then+  cat expected.out # skip this test on Windows+else+  ${IDRIS:-idris} "$@" --build base001.ipkg | grep -v 'make.*:'+  ./base001 2>&1 | grep -v '^sh:.*\./does-not-exist:'+  make clean | grep -v 'make.*:'+  rm -f -- *.ibc base001+fi
− test/basic001/expected 
@@ -1,2 +0,0 @@-1f4o1b4a1r1b3a1z-1f4o1b4a1r1b3a1z
+ test/basic001/expected.out view
@@ -0,0 +1,2 @@+1f4o1b4a1r1b3a1z+1f4o1b4a1r1b3a1z
− test/basic001/run 
@@ -1,6 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ reg005.idr -o reg005-${IDRIS:-idris} $@ basic001a.idr -o basic001a-./reg005-./basic001a-rm -f reg005 basic001a *.ibc
+ test/basic001/run.sh view
@@ -0,0 +1,6 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ reg005.idr -o reg005+${IDRIS:-idris} $@ basic001a.idr -o basic001a+./reg005+./basic001a+rm -f reg005 basic001a *.ibc
− test/basic002/expected 
@@ -1,13 +0,0 @@-test006.idr:25:23-27:-   |-25 | Main.parity_lemma_2 = proof {-   |                       ~~~~~-This style of tactic proof is deprecated. See %runElab for the replacement.--test006.idr:32:23-27:-   |-32 | Main.parity_lemma_1 = proof {-   |                       ~~~~~-This style of tactic proof is deprecated. See %runElab for the replacement.--[False, True, False, True, False, True]
+ test/basic002/expected.out view
@@ -0,0 +1,13 @@+test006.idr:25:23-27:+   |+25 | Main.parity_lemma_2 = proof {+   |                       ~~~~~+This style of tactic proof is deprecated. See %runElab for the replacement.++test006.idr:32:23-27:+   |+32 | Main.parity_lemma_1 = proof {+   |                       ~~~~~+This style of tactic proof is deprecated. See %runElab for the replacement.++[False, True, False, True, False, True]
− test/basic002/run 
@@ -1,4 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ --nocolour test006.idr -o test006-./test006-rm -f test006 test006.ibc
+ test/basic002/run.sh view
@@ -0,0 +1,4 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ --nocolour test006.idr -o test006+./test006+rm -f test006 test006.ibc
− test/basic003/expected 
@@ -1,3 +0,0 @@-[1, 1, 3, 5, 5, 8, 9]-55-3628800
+ test/basic003/expected.out view
@@ -0,0 +1,3 @@+[1, 1, 3, 5, 5, 8, 9]+55+3628800
− test/basic003/run 
@@ -1,4 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ test027.idr -o test027-./test027-rm -f test027 *.ibc
+ test/basic003/run.sh view
@@ -0,0 +1,4 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ test027.idr -o test027+./test027+rm -f test027 *.ibc
− test/basic004/expected 
@@ -1,1 +0,0 @@-[10, 11, 12, 13, 14, 15, 16, 17, 18, 19]
+ test/basic004/expected.out view
@@ -0,0 +1,1 @@+[10, 11, 12, 13, 14, 15, 16, 17, 18, 19]
− test/basic004/run 
@@ -1,4 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ test016.idr -o test016-./test016-rm -f test016 *.ibc
+ test/basic004/run.sh view
@@ -0,0 +1,4 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ test016.idr -o test016+./test016+rm -f test016 *.ibc
− test/basic005/expected 
@@ -1,1 +0,0 @@-1
+ test/basic005/expected.out view
@@ -0,0 +1,1 @@+1
− test/basic005/run 
@@ -1,4 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ test019.lidr -o test019-./test019-rm -f test019 *.ibc
+ test/basic005/run.sh view
@@ -0,0 +1,4 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ test019.lidr -o test019+./test019+rm -f test019 *.ibc
− test/basic006/expected 
@@ -1,15 +0,0 @@-test020a.idr:16:10-19:-   |-16 | foo xs = reverse xs-   |          ~~~~~~~~~~-When checking right hand side of foo with expected type-        List a--When checking an application of function Prelude.List.reverse:-        Type mismatch between-                Vect n a (Type of xs)-        and-                List a (Expected type)--[3, 2, 1]-"Number 42"
+ test/basic006/expected.out view
@@ -0,0 +1,15 @@+test020a.idr:16:10-19:+   |+16 | foo xs = reverse xs+   |          ~~~~~~~~~~+When checking right hand side of foo with expected type+        List a++When checking an application of function Prelude.List.reverse:+        Type mismatch between+                Vect n a (Type of xs)+        and+                List a (Expected type)++[3, 2, 1]+"Number 42"
− test/basic006/run 
@@ -1,6 +0,0 @@-#!/usr/bin/env bash--${IDRIS:-idris} $@ test020.idr -o test020-${IDRIS:-idris} $@ test020a.idr --check --nocolor-./test020-rm -f test020 *.ibc
+ test/basic006/run.sh view
@@ -0,0 +1,6 @@+#!/usr/bin/env bash++${IDRIS:-idris} $@ test020.idr -o test020+${IDRIS:-idris} $@ test020a.idr --check --nocolor+./test020+rm -f test020 *.ibc
− test/basic007/expected 
@@ -1,1 +0,0 @@-True
+ test/basic007/expected.out view
@@ -0,0 +1,1 @@+True
− test/basic007/run 
@@ -1,4 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ -o test033 test033.idr-./test033-rm -f *.ibc test033
+ test/basic007/run.sh view
@@ -0,0 +1,4 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ -o test033 test033.idr+./test033+rm -f *.ibc test033
− test/basic008/expected 
@@ -1,1 +0,0 @@-Just 2
+ test/basic008/expected.out view
@@ -0,0 +1,1 @@+Just 2
− test/basic008/run 
@@ -1,4 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ test036.idr -o test036-./test036-rm -f test036 *.ibc
+ test/basic008/run.sh view
@@ -0,0 +1,4 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ test036.idr -o test036+./test036+rm -f test036 *.ibc
− test/basic009/expected 
@@ -1,32 +0,0 @@-MAIN-PASS-Faulty.idr:6:9-11:-  |-6 | fault : num = Z-  |         ~~~-num is bound as an implicit-	Did you mean to refer to A.num?--Faulty.idr:7:9-12:-  |-7 | fault = Refl-  |         ~~~~-When checking right hand side of fault with expected type-        num = 0--Type mismatch between-        0 = 0 (Type of Refl)-and-        num = 0 (Expected type)--Specifically:-        Type mismatch between-                0-        and-                num--Multiple.idr:3:21:-  |-3 | import Data.Vect as X-  |                     ^-import alias not unique: "X"-
+ test/basic009/expected.out view
@@ -0,0 +1,32 @@+MAIN-PASS+Faulty.idr:6:9-11:+  |+6 | fault : num = Z+  |         ~~~+num is bound as an implicit+	Did you mean to refer to A.num?++Faulty.idr:7:9-12:+  |+7 | fault = Refl+  |         ~~~~+When checking right hand side of fault with expected type+        num = 0++Type mismatch between+        0 = 0 (Type of Refl)+and+        num = 0 (Expected type)++Specifically:+        Type mismatch between+                0+        and+                num++Multiple.idr:3:21:+  |+3 | import Data.Vect as X+  |                     ^+import alias not unique: "X"+
− test/basic009/run 
@@ -1,8 +0,0 @@-#!/usr/bin/env bash--${IDRIS:-idris} $@ Main.idr --nocolour --check && echo MAIN-PASS-${IDRIS:-idris} $@ Faulty.idr --nocolour --check && echo FAULTY-PASS-${IDRIS:-idris} $@ Multiple.idr --nocolour --check && echo MULTIPLE-PASS---rm -f *.ibc B/*.ibc
+ test/basic009/run.sh view
@@ -0,0 +1,8 @@+#!/usr/bin/env bash++${IDRIS:-idris} $@ Main.idr --nocolour --check && echo MAIN-PASS+${IDRIS:-idris} $@ Faulty.idr --nocolour --check && echo FAULTY-PASS+${IDRIS:-idris} $@ Multiple.idr --nocolour --check && echo MULTIPLE-PASS+++rm -f *.ibc B/*.ibc
− test/basic010/expected 
@@ -1,3 +0,0 @@-*oink*-10000-Axiom 10000
+ test/basic010/expected.out view
@@ -0,0 +1,3 @@+*oink*+10000+Axiom 10000
− test/basic010/run 
@@ -1,10 +0,0 @@-#!/usr/bin/env bash--set -eu--TIMEOUT=../scripts/timeout--$TIMEOUT 20 "${IDRIS:-idris}" "$@" Main.idr --nocolour --check --warnreach -o basic010-$TIMEOUT 20  ./basic010--rm -f -- *.ibc basic010
+ test/basic010/run.sh view
@@ -0,0 +1,10 @@+#!/usr/bin/env bash++set -eu++TIMEOUT=../scripts/timeout++$TIMEOUT 20 "${IDRIS:-idris}" "$@" Main.idr --nocolour --check --warnreach -o basic010+$TIMEOUT 20  ./basic010++rm -f -- *.ibc basic010
− test/basic011/expected 
@@ -1,14 +0,0 @@-6EA049D797FA18D6-6EA049D797FA18D6-FDA01C93B78A192F-AD85270E93646134-6EA049D797FA18D6-6EA049D797FA18D6-6EA049D797FA18D6-6EA049D797FA18D6-6EA049D797FA18D6-6EA049D797FA18D6-00-0000-00000000-0000000000000000
+ test/basic011/expected.out view
@@ -0,0 +1,14 @@+6EA049D797FA18D6+6EA049D797FA18D6+FDA01C93B78A192F+AD85270E93646134+6EA049D797FA18D6+6EA049D797FA18D6+6EA049D797FA18D6+6EA049D797FA18D6+6EA049D797FA18D6+6EA049D797FA18D6+00+0000+00000000+0000000000000000
− test/basic011/run 
@@ -1,4 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ basic011.idr -p contrib -o basic011-./basic011-rm -f basic011 *.ibc
+ test/basic011/run.sh view
@@ -0,0 +1,4 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ basic011.idr -p contrib -o basic011+./basic011+rm -f basic011 *.ibc
− test/basic012/expected 
@@ -1,2 +0,0 @@-4242-[1, 2, 3, 4, 5, 6]
+ test/basic012/expected.out view
@@ -0,0 +1,2 @@+4242+[1, 2, 3, 4, 5, 6]
− test/basic012/run 
@@ -1,5 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ basic012.idr -o basic012-./basic012-${IDRIS:-idris} $@ basic012a.idr --check-rm -f basic012 *.ibc
+ test/basic012/run.sh view
@@ -0,0 +1,5 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ basic012.idr -o basic012+./basic012+${IDRIS:-idris} $@ basic012a.idr --check+rm -f basic012 *.ibc
− test/basic013/expected 
@@ -1,59 +0,0 @@-λx→x-λx→xλx→x-x→xλx→xλ-4-'\955'-"\321"-"\321"-λx→xλx→xλx→xλx→xλx→x-'\955'-20-'\955'-λ-Tail: x→xλx→xλx→xλx→xλx→x-Tail Tail: →xλx→xλx→xλx→xλx→x-Cons: λλx→xλx→xλx→xλx→xλx→x-Reverse: x→xλx→xλx→xλx→xλx→xλ-[1, 2, 3, 4, 5]-[5, 4, 3, 2, 1]-[-9, -7, -5, -3, -1]-[17, 15, 13, 11, 9, 7, 5, 3, 1]-[19, 15, 11, 7, 3]-[-2, 0, 2, 4]-[1, 0, -1, -2]-[3]-[2]-[4]-[1]-[]-[]-[]-[]-[1, 2, 3, 4, 5]-[5, 4, 3, 2, 1]-[5, 4, 3, 2, 1]-[1, 3, 5]-[5, 3, 1]-[3]-[2]-[4]-[1]-[]-[]-[]-[]-[-1, -2, -3, -4, -5]-[-2, 0, 2, 4]-[1, 0, -1, -2]-[3]-[2]-[4]-[1]-[]-[]-[]-[]-['z', 'y', 'x']-['g', 'e', 'c', 'a']-['x', 'y', 'z']-['a', 'c', 'e', 'g']
+ test/basic013/expected.out view
@@ -0,0 +1,59 @@+λx→x+λx→xλx→x+x→xλx→xλ+4+'\955'+"\321"+"\321"+λx→xλx→xλx→xλx→xλx→x+'\955'+20+'\955'+λ+Tail: x→xλx→xλx→xλx→xλx→x+Tail Tail: →xλx→xλx→xλx→xλx→x+Cons: λλx→xλx→xλx→xλx→xλx→x+Reverse: x→xλx→xλx→xλx→xλx→xλ+[1, 2, 3, 4, 5]+[5, 4, 3, 2, 1]+[-9, -7, -5, -3, -1]+[17, 15, 13, 11, 9, 7, 5, 3, 1]+[19, 15, 11, 7, 3]+[-2, 0, 2, 4]+[1, 0, -1, -2]+[3]+[2]+[4]+[1]+[]+[]+[]+[]+[1, 2, 3, 4, 5]+[5, 4, 3, 2, 1]+[5, 4, 3, 2, 1]+[1, 3, 5]+[5, 3, 1]+[3]+[2]+[4]+[1]+[]+[]+[]+[]+[-1, -2, -3, -4, -5]+[-2, 0, 2, 4]+[1, 0, -1, -2]+[3]+[2]+[4]+[1]+[]+[]+[]+[]+['z', 'y', 'x']+['g', 'e', 'c', 'a']+['x', 'y', 'z']+['a', 'c', 'e', 'g']
− test/basic013/run 
@@ -1,4 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ basic013.idr -o basic013-./basic013-rm -f basic013 *.ibc
+ test/basic013/run.sh view
@@ -0,0 +1,4 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ basic013.idr -o basic013+./basic013+rm -f basic013 *.ibc
− test/basic014/expected 
+ test/basic014/expected.out view
− test/basic014/run 
@@ -1,3 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ basic014.idr --check-rm -f *.ibc
+ test/basic014/run.sh view
@@ -0,0 +1,3 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ basic014.idr --check+rm -f *.ibc
− test/basic015/expected 
@@ -1,3 +0,0 @@-Rows: Columns: [[0, 1, 2, 3, 4, 5], [6, 7, 8, 9, 10, 11], [12, 13, 14, 15, 16, 17], [18, 19, 20, 21, 22, 23], [24, 25, 26, 27, 28, 29]]-Transposed:-[[0, 6, 12, 18, 24], [1, 7, 13, 19, 25], [2, 8, 14, 20, 26], [3, 9, 15, 21, 27], [4, 10, 16, 22, 28], [5, 11, 17, 23, 29]]
+ test/basic015/expected.out view
@@ -0,0 +1,3 @@+Rows: Columns: [[0, 1, 2, 3, 4, 5], [6, 7, 8, 9, 10, 11], [12, 13, 14, 15, 16, 17], [18, 19, 20, 21, 22, 23], [24, 25, 26, 27, 28, 29]]+Transposed:+[[0, 6, 12, 18, 24], [1, 7, 13, 19, 25], [2, 8, 14, 20, 26], [3, 9, 15, 21, 27], [4, 10, 16, 22, 28], [5, 11, 17, 23, 29]]
− test/basic015/run 
@@ -1,4 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ basic015.idr -o basic015-./basic015-rm -f basic015 *.ibc
+ test/basic015/run.sh view
@@ -0,0 +1,4 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ basic015.idr -o basic015+./basic015+rm -f basic015 *.ibc
− test/basic016/expected 
@@ -1,1 +0,0 @@- Cycle detected in imports: CycleA.idr -> CycleB -> CycleC -> CycleA -> CycleB
+ test/basic016/expected.out view
@@ -0,0 +1,1 @@+ Cycle detected in imports: CycleA.idr -> CycleB -> CycleC -> CycleA -> CycleB
− test/basic016/run 
@@ -1,3 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ CycleA.idr --nocolour --check-rm -f *.ibc
+ test/basic016/run.sh view
@@ -0,0 +1,3 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ CycleA.idr --nocolour --check+rm -f *.ibc
− test/basic017/expected 
@@ -1,8 +0,0 @@-basic017a.idr:11:8:-   |-11 | append : Vect n a -> Vect m a -> Vect (n + m) a-   |        ^-When checking type of Main.append:-When checking an application of Main.Vect:-        No such variable n-
+ test/basic017/expected.out view
@@ -0,0 +1,8 @@+basic017a.idr:11:8:+   |+11 | append : Vect n a -> Vect m a -> Vect (n + m) a+   |        ^+When checking type of Main.append:+When checking an application of Main.Vect:+        No such variable n+
− test/basic017/run 
@@ -1,4 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ basic017.idr --check --nocolor-${IDRIS:-idris} $@ basic017a.idr --check --nocolor-rm -f *.ibc
+ test/basic017/run.sh view
@@ -0,0 +1,4 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ basic017.idr --check --nocolor+${IDRIS:-idris} $@ basic017a.idr --check --nocolor+rm -f *.ibc
− test/basic018/expected 
@@ -1,32 +0,0 @@-basic018.idr:7:12-16:-  |-7 |       Vect thing elem-  |            ~~~~~-thing is bound as an implicit-	Did you mean to refer to Main.thing?--basic018.idr:12:8-12:-   |-12 | test : thing = S 41-   |        ~~~~~-thing is bound as an implicit-	Did you mean to refer to Main.thing?--basic018.idr:13:8-11:-   |-13 | test = Refl-   |        ~~~~-When checking right hand side of test with expected type-        thing = S 41--Type mismatch between-        42 = 42 (Type of Refl)-and-        thing = 42 (Expected type)--Specifically:-        Type mismatch between-                42-        and-                thing-
+ test/basic018/expected.out view
@@ -0,0 +1,32 @@+basic018.idr:7:12-16:+  |+7 |       Vect thing elem+  |            ~~~~~+thing is bound as an implicit+	Did you mean to refer to Main.thing?++basic018.idr:12:8-12:+   |+12 | test : thing = S 41+   |        ~~~~~+thing is bound as an implicit+	Did you mean to refer to Main.thing?++basic018.idr:13:8-11:+   |+13 | test = Refl+   |        ~~~~+When checking right hand side of test with expected type+        thing = S 41++Type mismatch between+        42 = 42 (Type of Refl)+and+        thing = 42 (Expected type)++Specifically:+        Type mismatch between+                42+        and+                thing+
− test/basic018/run 
@@ -1,3 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ basic018.idr --check --nocolor-rm -f *.ibc
+ test/basic018/run.sh view
@@ -0,0 +1,3 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ basic018.idr --check --nocolor+rm -f *.ibc
− test/basic019/expected 
@@ -1,12 +0,0 @@-[1, 2, 3, 4, 5, 6, 7, 8, 9, 10]-[10, 9, 8, 7, 6, 5, 4, 3, 2, 1]-[1, 2, 3, 4, 5, 6, 7, 8, 9, 10]-[1, 3, 5, 7, 9, 11, 13, 15, 17, 19]-[1, 2, 3, 4, 5, 6, 7, 8, 9, 10]-[10, 9, 8, 7, 6, 5, 4, 3, 2, 1]-[1, 2, 3, 4, 5, 6, 7, 8, 9, 10]-[1, 3, 5, 7, 9, 11, 13, 15, 17, 19]-[1, 2, 3, 4, 5, 6, 7, 8, 9, 10]-[10, 9, 8, 7, 6, 5, 4, 3, 2, 1]-[1, 2, 3, 4, 5, 6, 7, 8, 9, 10]-[1, 3, 5, 7, 9, 11, 13, 15, 17, 19]
+ test/basic019/expected.out view
@@ -0,0 +1,12 @@+[1, 2, 3, 4, 5, 6, 7, 8, 9, 10]+[10, 9, 8, 7, 6, 5, 4, 3, 2, 1]+[1, 2, 3, 4, 5, 6, 7, 8, 9, 10]+[1, 3, 5, 7, 9, 11, 13, 15, 17, 19]+[1, 2, 3, 4, 5, 6, 7, 8, 9, 10]+[10, 9, 8, 7, 6, 5, 4, 3, 2, 1]+[1, 2, 3, 4, 5, 6, 7, 8, 9, 10]+[1, 3, 5, 7, 9, 11, 13, 15, 17, 19]+[1, 2, 3, 4, 5, 6, 7, 8, 9, 10]+[10, 9, 8, 7, 6, 5, 4, 3, 2, 1]+[1, 2, 3, 4, 5, 6, 7, 8, 9, 10]+[1, 3, 5, 7, 9, 11, 13, 15, 17, 19]
− test/basic019/run 
@@ -1,4 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ basic019.idr -o basic019-./basic019-rm -f basic019 *.ibc
+ test/basic019/run.sh view
@@ -0,0 +1,4 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ basic019.idr -o basic019+./basic019+rm -f basic019 *.ibc
− test/basic020/expected 
@@ -1,1 +0,0 @@-OK
+ test/basic020/expected.out view
@@ -0,0 +1,1 @@+OK
− test/basic020/run 
@@ -1,4 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ basic020.idr -o basic020-./basic020-rm -f basic020 *.ibc
+ test/basic020/run.sh view
@@ -0,0 +1,4 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ basic020.idr -o basic020+./basic020+rm -f basic020 *.ibc
− test/basic021/expected 
@@ -1,2 +0,0 @@-1000000-1000
+ test/basic021/expected.out view
@@ -0,0 +1,2 @@+1000000+1000
− test/basic021/run 
@@ -1,6 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ basic021.idr -o basic021-${IDRIS:-idris} $@ basic021_2.idr -o basic021_2-./basic021-./basic021_2-rm -f basic021 basic021_2 *.ibc
+ test/basic021/run.sh view
@@ -0,0 +1,6 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ basic021.idr -o basic021+${IDRIS:-idris} $@ basic021_2.idr -o basic021_2+./basic021+./basic021_2+rm -f basic021 basic021_2 *.ibc
− test/basic022/expected 
@@ -1,1 +0,0 @@-1000
+ test/basic022/expected.out view
@@ -0,0 +1,1 @@+1000
− test/basic022/run 
@@ -1,4 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ basic022.idr -o basic022-./basic022-rm -f basic022 *.ibc
+ test/basic022/run.sh view
@@ -0,0 +1,4 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ basic022.idr -o basic022+./basic022+rm -f basic022 *.ibc
− test/basic023/expected 
@@ -1,10 +0,0 @@-True-True-True-True-True-True-True-True-True-True
+ test/basic023/expected.out view
@@ -0,0 +1,10 @@+True+True+True+True+True+True+True+True+True+True
− test/basic023/run 
@@ -1,4 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ sections.idr -o sections-./sections-rm -f sections *.ibc
+ test/basic023/run.sh view
@@ -0,0 +1,4 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ sections.idr -o sections+./sections+rm -f sections *.ibc
− test/basic024/expected 
@@ -1,76 +0,0 @@-2 : Integer-2 : Int-2 : Bits8-2 : Bits16-2 : Bits32-2 : Bits64-2 : Nat-1 : Integer-1 : Int-1 : Bits8-1 : Bits16-1 : Bits32-1 : Bits64-1 : Nat-0 : Integer-0 : Int-0 : Bits8-0 : Bits16-0 : Bits32-0 : Bits64-0 : Nat-3 : Integer-3 : Int-3 : Bits8-3 : Bits16-3 : Bits32-3 : Bits64-3 : Nat--2 : Integer--2 : Int--1 : Integer--1 : Int-0 : Integer-0 : Int--3 : Integer--3 : Int--11861903511836511836 : Integer--25643355395 : Integer-2-2-02-0002-00000002-0000000000000002-2-1-1-01-0001-00000001-0000000000000001-1-0-0-00-0000-00000000-0000000000000000-0-3-3-03-0003-00000003-0000000000000003-3--2--2--1--1-0-0--3--3--11861903511836511836--25643355395
+ test/basic024/expected.out view
@@ -0,0 +1,76 @@+2 : Integer+2 : Int+2 : Bits8+2 : Bits16+2 : Bits32+2 : Bits64+2 : Nat+1 : Integer+1 : Int+1 : Bits8+1 : Bits16+1 : Bits32+1 : Bits64+1 : Nat+0 : Integer+0 : Int+0 : Bits8+0 : Bits16+0 : Bits32+0 : Bits64+0 : Nat+3 : Integer+3 : Int+3 : Bits8+3 : Bits16+3 : Bits32+3 : Bits64+3 : Nat+-2 : Integer+-2 : Int+-1 : Integer+-1 : Int+0 : Integer+0 : Int+-3 : Integer+-3 : Int+-11861903511836511836 : Integer+-25643355395 : Integer+2+2+02+0002+00000002+0000000000000002+2+1+1+01+0001+00000001+0000000000000001+1+0+0+00+0000+00000000+0000000000000000+0+3+3+03+0003+00000003+0000000000000003+3+-2+-2+-1+-1+0+0+-3+-3+-11861903511836511836+-25643355395
− test/basic024/input 
@@ -1,46 +0,0 @@-:x div (the Integer 5) 2-:x div (the Int 5) 2-:x div (the Bits8 5) 2-:x div (the Bits16 5) 2-:x div (the Bits32 5) 2-:x div (the Bits64 5) 2-:x div (the Nat 5) 2--:x mod (the Integer 5) 2-:x mod (the Int 5) 2-:x mod (the Bits8 5) 2-:x mod (the Bits16 5) 2-:x mod (the Bits32 5) 2-:x mod (the Bits64 5) 2-:x mod (the Nat 5) 2--:x div (the Integer 3) 5-:x div (the Int 3) 5-:x div (the Bits8 3) 5-:x div (the Bits16 3) 5-:x div (the Bits32 3) 5-:x div (the Bits64 3) 5-:x div (the Nat 3) 5--:x mod (the Integer 3) 5-:x mod (the Int 3) 5-:x mod (the Bits8 3) 5-:x mod (the Bits16 3) 5-:x mod (the Bits32 3) 5-:x mod (the Bits64 3) 5-:x mod (the Nat 3) 5--:x div (the Integer (-5)) 2-:x div (the Int (-5)) 2--:x mod (the Integer (-5)) 2-:x mod (the Int (-5)) 2--:x div (the Integer (-3)) 5-:x div (the Int (-3)) 5--:x mod (the Integer (-3)) 5-:x mod (the Int (-3)) 5--:x div (-432642342742368327462378462387) 36473264372-:x mod (-432642342742368327462378462387) 36473264372
+ test/basic024/input.in view
@@ -0,0 +1,46 @@+:x div (the Integer 5) 2+:x div (the Int 5) 2+:x div (the Bits8 5) 2+:x div (the Bits16 5) 2+:x div (the Bits32 5) 2+:x div (the Bits64 5) 2+:x div (the Nat 5) 2++:x mod (the Integer 5) 2+:x mod (the Int 5) 2+:x mod (the Bits8 5) 2+:x mod (the Bits16 5) 2+:x mod (the Bits32 5) 2+:x mod (the Bits64 5) 2+:x mod (the Nat 5) 2++:x div (the Integer 3) 5+:x div (the Int 3) 5+:x div (the Bits8 3) 5+:x div (the Bits16 3) 5+:x div (the Bits32 3) 5+:x div (the Bits64 3) 5+:x div (the Nat 3) 5++:x mod (the Integer 3) 5+:x mod (the Int 3) 5+:x mod (the Bits8 3) 5+:x mod (the Bits16 3) 5+:x mod (the Bits32 3) 5+:x mod (the Bits64 3) 5+:x mod (the Nat 3) 5++:x div (the Integer (-5)) 2+:x div (the Int (-5)) 2++:x mod (the Integer (-5)) 2+:x mod (the Int (-5)) 2++:x div (the Integer (-3)) 5+:x div (the Int (-3)) 5++:x mod (the Integer (-3)) 5+:x mod (the Int (-3)) 5++:x div (-432642342742368327462378462387) 36473264372+:x mod (-432642342742368327462378462387) 36473264372
− test/basic024/run 
@@ -1,8 +0,0 @@-#!/usr/bin/env bash--${IDRIS:-idris} $@ --quiet --port none < input-${IDRIS:-idris} $@ basic024.idr -o basic024--./basic024--rm -f basic024 *.ibc
+ test/basic024/run.sh view
@@ -0,0 +1,8 @@+#!/usr/bin/env bash++${IDRIS:-idris} $@ --quiet --port none < input.in+${IDRIS:-idris} $@ basic024.idr -o basic024++./basic024++rm -f basic024 *.ibc
− test/basic025/expected 
@@ -1,12 +0,0 @@-0.7853981633974483 : Double--0.7853981633974483 : Double-2.356194490192345 : Double--2.356194490192345 : Double-0.0 : Double-1.5707963267948966 : Double-0.7853981633--0.7853981633-2.3561944901--2.3561944901-0-1.5707963267
+ test/basic025/expected.out view
@@ -0,0 +1,12 @@+0.7853981633974483 : Double+-0.7853981633974483 : Double+2.356194490192345 : Double+-2.356194490192345 : Double+0.0 : Double+1.5707963267948966 : Double+0.7853981633+-0.7853981633+2.3561944901+-2.3561944901+0+1.5707963267
− test/basic025/input 
@@ -1,7 +0,0 @@-:x atan2   1    1-:x atan2 (-1)   1-:x atan2   1  (-1)-:x atan2 (-1) (-1)--:x atan2 0 1-:x atan2 1 0
+ test/basic025/input.in view
@@ -0,0 +1,7 @@+:x atan2   1    1+:x atan2 (-1)   1+:x atan2   1  (-1)+:x atan2 (-1) (-1)++:x atan2 0 1+:x atan2 1 0
− test/basic025/run 
@@ -1,7 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ --quiet --port none < input-${IDRIS:-idris} $@ -o basic025 basic025.idr--./basic025 input--rm -f basic025 *.ibc
+ test/basic025/run.sh view
@@ -0,0 +1,7 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ --quiet --port none < input.in+${IDRIS:-idris} $@ -o basic025 basic025.idr++./basic025 input.in++rm -f basic025 *.ibc
− test/basic026/expected 
@@ -1,2 +0,0 @@-True-True
+ test/basic026/expected.out view
@@ -0,0 +1,2 @@+True+True
− test/basic026/run 
@@ -1,4 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ basic026.idr -o basic026-./basic026-rm -f basic026 *.ibc
+ test/basic026/run.sh view
@@ -0,0 +1,4 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ basic026.idr -o basic026+./basic026+rm -f basic026 *.ibc
− test/bignum001/expected 
@@ -1,1 +0,0 @@-OK
+ test/bignum001/expected.out view
@@ -0,0 +1,1 @@+OK
− test/bignum001/run 
@@ -1,4 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ bignum001.idr -o bignum001-./bignum001-rm -f bignum001 *.ibc
+ test/bignum001/run.sh view
@@ -0,0 +1,4 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ bignum001.idr -o bignum001+./bignum001+rm -f bignum001 *.ibc
− test/bignum002/expected 
@@ -1,8 +0,0 @@-19827346982734--11861903511836511836-14531-14531-14531--14531--14531--14531
+ test/bignum002/expected.out view
@@ -0,0 +1,8 @@+19827346982734+-11861903511836511836+14531+14531+14531+-14531+-14531+-14531
− test/bignum002/run 
@@ -1,4 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ bignum002.idr -o bignum002-./bignum002-rm -f bignum002 *.ibc
+ test/bignum002/run.sh view
@@ -0,0 +1,4 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ bignum002.idr -o bignum002+./bignum002+rm -f bignum002 *.ibc
− test/bignum003/expected 
@@ -1,2 +0,0 @@-True-True
+ test/bignum003/expected.out view
@@ -0,0 +1,2 @@+True+True
− test/bignum003/run 
@@ -1,4 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ bignum003.idr -o bignum003-./bignum003-rm -f bignum003 *.ibc
+ test/bignum003/run.sh view
@@ -0,0 +1,4 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ bignum003.idr -o bignum003+./bignum003+rm -f bignum003 *.ibc
− test/bounded001/expected 
@@ -1,6 +0,0 @@-FFFF-0000-FFFFFFFF-00000000-FFFFFFFFFFFFFFFF-0000000000000000
+ test/bounded001/expected.out view
@@ -0,0 +1,6 @@+FFFF+0000+FFFFFFFF+00000000+FFFFFFFFFFFFFFFF+0000000000000000
− test/bounded001/run 
@@ -1,4 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ bounded001.idr -o bounded001-./bounded001-rm -f bounded001 *.ibc
+ test/bounded001/run.sh view
@@ -0,0 +1,4 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ bounded001.idr -o bounded001+./bounded001+rm -f bounded001 *.ibc
− test/buffer001/expected 
@@ -1,7 +0,0 @@-40-[00, 00, 00, 00, 00, 2A, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 48, 65, 6C, 6C, 6F, 20, 77, 6F, 72, 6C, 64, 21, 00, 00, 00, 00, 00, 00, 00, 00]-Resized-[00, 00, 00, 00, 00, 2A, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 48, 65, 6C, 6C, 6F, 20, 77, 6F, 72, 6C, 64, 21, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]-Writing to file-Reading from file twice-[00, 00, 00, 00, 00, 2A, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 48, 65, 6C, 6C, 6F, 20, 77, 6F, 72, 6C, 64, 21, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 2A, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 48, 65, 6C, 6C, 6F, 20, 77, 6F, 72, 6C, 64, 21, 00, 00, 00, 00, 00, 00, 00, 00]
+ test/buffer001/expected.out view
@@ -0,0 +1,7 @@+40+[00, 00, 00, 00, 00, 2A, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 48, 65, 6C, 6C, 6F, 20, 77, 6F, 72, 6C, 64, 21, 00, 00, 00, 00, 00, 00, 00, 00]+Resized+[00, 00, 00, 00, 00, 2A, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 48, 65, 6C, 6C, 6F, 20, 77, 6F, 72, 6C, 64, 21, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]+Writing to file+Reading from file twice+[00, 00, 00, 00, 00, 2A, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 48, 65, 6C, 6C, 6F, 20, 77, 6F, 72, 6C, 64, 21, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 2A, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 48, 65, 6C, 6C, 6F, 20, 77, 6F, 72, 6C, 64, 21, 00, 00, 00, 00, 00, 00, 00, 00]
− test/buffer001/run 
@@ -1,4 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ buffer001.idr -o buffer001-./buffer001-rm -f buffer001 test.buf *.ibc
+ test/buffer001/run.sh view
@@ -0,0 +1,4 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ buffer001.idr -o buffer001+./buffer001+rm -f buffer001 test.buf *.ibc
− test/buffer002/expected 
@@ -1,11 +0,0 @@-40-[00, 00, 00, 00, 00, AE, 55, EE, C2, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 48, 65, 6C, 6C, 6F, 20, 77, 6F, 72, 6C, 64, 21, 00, 00, 00, 00, D2, 40, AA, 3D]--1024567890-12774997-123.456-1034567890-0-Hello worl-Hello world!-""-""
+ test/buffer002/expected.out view
@@ -0,0 +1,11 @@+40+[00, 00, 00, 00, 00, AE, 55, EE, C2, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 48, 65, 6C, 6C, 6F, 20, 77, 6F, 72, 6C, 64, 21, 00, 00, 00, 00, D2, 40, AA, 3D]+-1024567890+12774997+123.456+1034567890+0+Hello worl+Hello world!+""+""
− test/buffer002/run 
@@ -1,4 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ buffer002.idr -o buffer002-./buffer002-rm -f buffer002 test.buf *.ibc
+ test/buffer002/run.sh view
@@ -0,0 +1,4 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ buffer002.idr -o buffer002+./buffer002+rm -f buffer002 test.buf *.ibc
− test/contrib001/expected 
@@ -1,12 +0,0 @@-thisisalong-sentencewitha-lotofwordsthatI-canusefor-testingthe-performanceof-theprettier-printer-implementation.-Ineedafewmore-wordstoprovemy-point,though.
+ test/contrib001/expected.out view
@@ -0,0 +1,12 @@+thisisalong+sentencewitha+lotofwordsthatI+canusefor+testingthe+performanceof+theprettier+printer+implementation.+Ineedafewmore+wordstoprovemy+point,though.
− test/contrib001/run 
@@ -1,4 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ contrib001.idr -o contrib001 -p contrib-./contrib001-rm -f contrib001 *.ibc
+ test/contrib001/run.sh view
@@ -0,0 +1,4 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ contrib001.idr -o contrib001 -p contrib+./contrib001+rm -f contrib001 *.ibc
− test/corecords001/expected 
@@ -1,5 +0,0 @@-0-1-3-1-0
+ test/corecords001/expected.out view
@@ -0,0 +1,5 @@+0+1+3+1+0
− test/corecords001/run 
@@ -1,4 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ corecords001.idr -o corecords001-./corecords001-rm -f corecords001 corecords001.ibc
+ test/corecords001/run.sh view
@@ -0,0 +1,4 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ corecords001.idr -o corecords001+./corecords001+rm -f corecords001 corecords001.ibc
− test/corecords002/expected 
@@ -1,3 +0,0 @@-"Foo"-"Foo"-"Foo"
+ test/corecords002/expected.out view
@@ -0,0 +1,3 @@+"Foo"+"Foo"+"Foo"
− test/corecords002/run 
@@ -1,4 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ corecords002.idr -o corecords002-./corecords002-rm -f corecords002 corecords002.ibc
+ test/corecords002/run.sh view
@@ -0,0 +1,4 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ corecords002.idr -o corecords002+./corecords002+rm -f corecords002 corecords002.ibc
− test/delab001/expected 
@@ -1,12 +0,0 @@-foo : Nat -> String-foo n = case n of-          0 => "z"-          S _ => "s"-bar : Nat -> String -> String-bar x y = case x of-            0 => y-            S _ => y ++ y-append : List a -> List a -> List a-append xs ys = case xs of-                 [] => ys-                 x :: xs => x :: append xs ys
+ test/delab001/expected.out view
@@ -0,0 +1,12 @@+foo : Nat -> String+foo n = case n of+          0 => "z"+          S _ => "s"+bar : Nat -> String -> String+bar x y = case x of+            0 => y+            S _ => y ++ y+append : List a -> List a -> List a+append xs ys = case xs of+                 [] => ys+                 x :: xs => x :: append xs ys
− test/delab001/input 
@@ -1,4 +0,0 @@-:consolewidth infinite-:printdef foo-:printdef bar-:printdef append
+ test/delab001/input.in view
@@ -0,0 +1,4 @@+:consolewidth infinite+:printdef foo+:printdef bar+:printdef append
− test/delab001/run 
@@ -1,3 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ --quiet --port none --nocolor delab001.idr < input-rm -f *.ibc
+ test/delab001/run.sh view
@@ -0,0 +1,3 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ --quiet --port none --nocolor delab001.idr < input.in+rm -f *.ibc
− test/directives001/expected 
@@ -1,42 +0,0 @@-directives001.idr:14:7:-   |-14 | mkFoo : String -> Foo-   |       ^-Use of deprecated name directives001.Foo-To be replaced with `Bar`.--directives001.idr:14:7:-   |-14 | mkFoo : String -> Foo-   |       ^-Use of deprecated name directives001.Foo-To be replaced with `Bar`.--directives001.idr:15:9-13:-   |-15 | mkFoo = MkFoo-   |         ~~~~~-Use of deprecated name directives001.Foo-To be replaced with `Bar`.--directives001.idr:15:9-13:-   |-15 | mkFoo = MkFoo-   |         ~~~~~-Use of deprecated name directives001.Foo-To be replaced with `Bar`.--directives001.idr:26:10-28:28:-   |-26 |   main = do-   |          ~~ ...-Use of a fragile construct directives001.mkBar-How `Bar`s are to be created is still being discussed, `mkBar` is subject to change.--directives001.idr:26:10-28:28:-   |-26 |   main = do-   |          ~~ ...-Use of a fragile construct directives001.mkBar-How `Bar`s are to be created is still being discussed, `mkBar` is subject to change.-
+ test/directives001/expected.out view
@@ -0,0 +1,42 @@+directives001.idr:14:7:+   |+14 | mkFoo : String -> Foo+   |       ^+Use of deprecated name directives001.Foo+To be replaced with `Bar`.++directives001.idr:14:7:+   |+14 | mkFoo : String -> Foo+   |       ^+Use of deprecated name directives001.Foo+To be replaced with `Bar`.++directives001.idr:15:9-13:+   |+15 | mkFoo = MkFoo+   |         ~~~~~+Use of deprecated name directives001.Foo+To be replaced with `Bar`.++directives001.idr:15:9-13:+   |+15 | mkFoo = MkFoo+   |         ~~~~~+Use of deprecated name directives001.Foo+To be replaced with `Bar`.++directives001.idr:26:10-28:28:+   |+26 |   main = do+   |          ~~ ...+Use of a fragile construct directives001.mkBar+How `Bar`s are to be created is still being discussed, `mkBar` is subject to change.++directives001.idr:26:10-28:28:+   |+26 |   main = do+   |          ~~ ...+Use of a fragile construct directives001.mkBar+How `Bar`s are to be created is still being discussed, `mkBar` is subject to change.+
− test/directives001/run 
@@ -1,4 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ directives001.idr --check --nocolour--rm -f directives001 *.ibc
+ test/directives001/run.sh view
@@ -0,0 +1,4 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ directives001.idr --check --nocolour++rm -f directives001 *.ibc
− test/directives002/expected 
@@ -1,6 +0,0 @@-directives002.idr:12:3-14:28:-   |-12 |   main = do-   |   ~~~~~~~~~ ...-directives002.Main.main is possibly not total due to: directives002.loop-
+ test/directives002/expected.out view
@@ -0,0 +1,6 @@+directives002.idr:12:3-14:28:+   |+12 |   main = do+   |   ~~~~~~~~~ ...+directives002.Main.main is possibly not total due to: directives002.loop+
− test/directives002/run 
@@ -1,4 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ directives002.idr --check --nocolour--rm -f directives002 *.ibc
+ test/directives002/run.sh view
@@ -0,0 +1,4 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ directives002.idr --check --nocolour++rm -f directives002 *.ibc
− test/directives003/expected 
@@ -1,6 +0,0 @@-nuyahcha-mohgiide-apeekair-eeraimam-rahhahwi-goocheiv
+ test/directives003/expected.out view
@@ -0,0 +1,6 @@+nuyahcha+mohgiide+apeekair+eeraimam+rahhahwi+goocheiv
− test/directives003/run 
@@ -1,13 +0,0 @@-#!/usr/bin/env bash--# %lib C "nuyahcha"-# %lib C "mohgiide"-# %lib C "apeekair"-# %flag C "-Wl,-leeraimam -Wl,-lrahhahwi -Wl,-lgoocheiv"--${IDRIS:-idris} $@ -o directives003 directives003.idr \-    | tr ' ,"' '\n' \-    | sed 's/-l//' \-    | grep -E 'nuyahcha|mohgiide|apeekair|eeraimam|rahhahwi|goocheiv'--rm -f directives003 *.ibc
+ test/directives003/run.sh view
@@ -0,0 +1,13 @@+#!/usr/bin/env bash++# %lib C "nuyahcha"+# %lib C "mohgiide"+# %lib C "apeekair"+# %flag C "-Wl,-leeraimam -Wl,-lrahhahwi -Wl,-lgoocheiv"++${IDRIS:-idris} $@ -o directives003 directives003.idr \+    | tr ' ,"' '\n' \+    | sed 's/-l//' \+    | grep -E 'nuyahcha|mohgiide|apeekair|eeraimam|rahhahwi|goocheiv'++rm -f directives003 *.ibc
− test/disambig002/expected 
+ test/disambig002/expected.out view
− test/disambig002/run 
@@ -1,3 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ disambig002.idr --check-rm -f *.ibc
+ test/disambig002/run.sh view
@@ -0,0 +1,3 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ disambig002.idr --check+rm -f *.ibc
− test/docs001/expected 
@@ -1,17 +0,0 @@-Interface C-    interface--Parameters:-    t   -- a type--Methods:-    m : C t => t-        member of interface-        -        The function is: Total & public export-Implementations:-    C A-        implementation of interface-    C (D a b)-        another implementation of interface-        a   -- parameter type
+ test/docs001/expected.out view
@@ -0,0 +1,17 @@+Interface C+    interface++Parameters:+    t   -- a type++Methods:+    m : C t => t+        member of interface+        +        The function is: Total & public export+Implementations:+    C A+        implementation of interface+    C (D a b)+        another implementation of interface+        a   -- parameter type
− test/docs001/input 
@@ -1,1 +0,0 @@-:doc C
+ test/docs001/input.in view
@@ -0,0 +1,1 @@+:doc C
− test/docs001/run 
@@ -1,3 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ --quiet --port none --nocolor docs001.idr < input-rm *.ibc
+ test/docs001/run.sh view
@@ -0,0 +1,3 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ --quiet --port none --nocolor docs001.idr < input.in+rm *.ibc
− test/docs002/expected 
@@ -1,12 +0,0 @@-T1 : Type-    Some documentation-    -    The function is: Total & public export-T2 : Type-    Some other documentation-    -    The function is: Total & public export-T3 : Int-    Some provided postulate-    -    The function is: not yet checked for totality & public export
+ test/docs002/expected.out view
@@ -0,0 +1,12 @@+T1 : Type+    Some documentation+    +    The function is: Total & public export+T2 : Type+    Some other documentation+    +    The function is: Total & public export+T3 : Int+    Some provided postulate+    +    The function is: not yet checked for totality & public export
− test/docs002/input 
@@ -1,3 +0,0 @@-:doc T1-:doc T2-:doc T3
+ test/docs002/input.in view
@@ -0,0 +1,3 @@+:doc T1+:doc T2+:doc T3
− test/docs002/run 
@@ -1,3 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ --nobanner --nocolor --quiet --port none docs002.idr < input-rm *.ibc
+ test/docs002/run.sh view
@@ -0,0 +1,3 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ --nobanner --nocolor --quiet --port none docs002.idr < input.in+rm *.ibc
− test/docs003/expected 
@@ -1,41 +0,0 @@-Interface Functor-    Functors allow a uniform action over a parameterised type.--Parameters:-    f   -- a parameterised type--Methods:-    map : Functor f => (func : a -> b) -> f a -> f b-        Apply a function across everything of type 'a' in a parameterised type-        -        The function is: Total & public export-Implementations:-    Functor (Pair a)-    Functor List-    Functor (IO' ffi)-    Functor Stream-    Functor Provider-    Functor Binder-    Functor Elab-    Functor PrimIO-    Functor Maybe-    Functor (Either e)--Named implementations:-    docs003.mine : Functor List-    docs003.another : Functor List-        More functors!--Child interfaces:-    Traversable f-    Applicative f-Named implementation:-    docs003.mine : Functor List-        -        -        The function is: public export-Named implementation:-    docs003.another : Functor List-        More functors!-        -        The function is: public export
+ test/docs003/expected.out view
@@ -0,0 +1,41 @@+Interface Functor+    Functors allow a uniform action over a parameterised type.++Parameters:+    f   -- a parameterised type++Methods:+    map : Functor f => (func : a -> b) -> f a -> f b+        Apply a function across everything of type 'a' in a parameterised type+        +        The function is: Total & public export+Implementations:+    Functor (Pair a)+    Functor List+    Functor (IO' ffi)+    Functor Stream+    Functor Provider+    Functor Binder+    Functor Elab+    Functor PrimIO+    Functor Maybe+    Functor (Either e)++Named implementations:+    docs003.mine : Functor List+    docs003.another : Functor List+        More functors!++Child interfaces:+    Traversable f+    Applicative f+Named implementation:+    docs003.mine : Functor List+        +        +        The function is: public export+Named implementation:+    docs003.another : Functor List+        More functors!+        +        The function is: public export
− test/docs003/input 
@@ -1,3 +0,0 @@-:doc Functor-:doc mine-:doc another
+ test/docs003/input.in view
@@ -0,0 +1,3 @@+:doc Functor+:doc mine+:doc another
− test/docs003/run 
@@ -1,3 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ --quiet --port none --nocolor docs003.idr < input-rm *.ibc
+ test/docs003/run.sh view
@@ -0,0 +1,3 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ --quiet --port none --nocolor docs003.idr < input.in+rm *.ibc
− test/docs004/expected 
@@ -1,18 +0,0 @@-Main.MkFoo : (bar : Nat) -> (baz : Bool) -> Foo a-    Constructor for Foo-    Arguments:-        (implicit) a : Type  -- a type-        -        bar : Nat  -- A field bar-        -        baz : Bool  -- A field baz-        -    The function is: Total & public export-Main.Foo.bar : (rec : Foo a) -> Nat-    A field bar-    -    The function is: Total & public export-Main.Foo.baz : (rec : Foo a) -> Bool-    A field baz-    -    The function is: Total & public export
+ test/docs004/expected.out view
@@ -0,0 +1,18 @@+Main.MkFoo : (bar : Nat) -> (baz : Bool) -> Foo a+    Constructor for Foo+    Arguments:+        (implicit) a : Type  -- a type+        +        bar : Nat  -- A field bar+        +        baz : Bool  -- A field baz+        +    The function is: Total & public export+Main.Foo.bar : (rec : Foo a) -> Nat+    A field bar+    +    The function is: Total & public export+Main.Foo.baz : (rec : Foo a) -> Bool+    A field baz+    +    The function is: Total & public export
− test/docs004/input 
@@ -1,3 +0,0 @@-:doc MkFoo-:doc bar-:doc baz
+ test/docs004/input.in view
@@ -0,0 +1,3 @@+:doc MkFoo+:doc bar+:doc baz
− test/docs004/run 
@@ -1,3 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ --quiet --port none --nocolor docs004.idr < input-rm *.ibc
+ test/docs004/run.sh view
@@ -0,0 +1,3 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ --quiet --port none --nocolor docs004.idr < input.in+rm *.ibc
− test/docs005/expected 
@@ -1,31 +0,0 @@-Data type docs005.Foobar : Type-    A foobar with an auto implicit-    -    The function is: public export-Constructors:-    NewFoo : (xs : List String) ->-        (ys : List Nat) -> {auto prf : NonEmpty ys} -> Foobar-        New Foo-        Arguments:-            xs : List String  -- Some xs-            -            ys : List Nat  -- Some ys-            -            (implicit) prf1 : NonEmpty xs  -- A prf-            -            (auto implicit) prf : NonEmpty ys  -- The prf-            -        The function is: public export-docs005.NewFoo : (xs : List String) ->-    (ys : List Nat) -> {auto prf : NonEmpty ys} -> Foobar-    New Foo-    Arguments:-        xs : List String  -- Some xs-        -        ys : List Nat  -- Some ys-        -        (implicit) prf1 : NonEmpty xs  -- A prf-        -        (auto implicit) prf : NonEmpty ys  -- The prf-        -    The function is: Total & public export
+ test/docs005/expected.out view
@@ -0,0 +1,31 @@+Data type docs005.Foobar : Type+    A foobar with an auto implicit+    +    The function is: public export+Constructors:+    NewFoo : (xs : List String) ->+        (ys : List Nat) -> {auto prf : NonEmpty ys} -> Foobar+        New Foo+        Arguments:+            xs : List String  -- Some xs+            +            ys : List Nat  -- Some ys+            +            (implicit) prf1 : NonEmpty xs  -- A prf+            +            (auto implicit) prf : NonEmpty ys  -- The prf+            +        The function is: public export+docs005.NewFoo : (xs : List String) ->+    (ys : List Nat) -> {auto prf : NonEmpty ys} -> Foobar+    New Foo+    Arguments:+        xs : List String  -- Some xs+        +        ys : List Nat  -- Some ys+        +        (implicit) prf1 : NonEmpty xs  -- A prf+        +        (auto implicit) prf : NonEmpty ys  -- The prf+        +    The function is: Total & public export
− test/docs005/input 
@@ -1,2 +0,0 @@-:doc Foobar-:doc NewFoo
+ test/docs005/input.in view
@@ -0,0 +1,2 @@+:doc Foobar+:doc NewFoo
− test/docs005/run 
@@ -1,3 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ --quiet --port none --nocolor docs005.idr < input-rm *.ibc
+ test/docs005/run.sh view
@@ -0,0 +1,3 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ --quiet --port none --nocolor docs005.idr < input.in+rm *.ibc
− test/docs006/expected 
@@ -1,16 +0,0 @@-Interface Foo-    interface--Parameters:-    t   -- some parameter--Constraints:-    Eq t--Methods:-    m : Foo t => t-        member of interface-        -        The function is: Total & public export-Implementations:-    <no implementations>
+ test/docs006/expected.out view
@@ -0,0 +1,16 @@+Interface Foo+    interface++Parameters:+    t   -- some parameter++Constraints:+    Eq t++Methods:+    m : Foo t => t+        member of interface+        +        The function is: Total & public export+Implementations:+    <no implementations>
− test/docs006/input 
@@ -1,1 +0,0 @@-:doc Foo
+ test/docs006/input.in view
@@ -0,0 +1,1 @@+:doc Foo
− test/docs006/run 
@@ -1,3 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ --quiet --port none --nocolor docs006.idr < input-rm *.ibc
+ test/docs006/run.sh view
@@ -0,0 +1,3 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ --quiet --port none --nocolor docs006.idr < input.in+rm *.ibc
− test/dsl001/expected 
@@ -1,14 +0,0 @@-24-12-testFac : Int-testFac = PE_interp_9b251b28 [] (PE_fromInteger_d6648df 4)-PE_interp_9b251b28 : Env G -> Int -> Int-PE_interp_9b251b28 (3arg) = \x =>-                              ifThenElse (PE_==_ba2f651f x-                                                         (PE_fromInteger_d6648df 0))-                                         (Delay (PE_fromInteger_d6648df 1))-                                         (Delay (PE_*_ba2f651f (PE_interp_9b251b28 (x ::-                                                                                    (3arg))-                                                                                   (PE_-_ba2f651f x-                                                                                                  (PE_fromInteger_d6648df 1)))-                                                               x))
+ test/dsl001/expected.out view
@@ -0,0 +1,14 @@+24+12+testFac : Int+testFac = PE_interp_9b251b28 [] (PE_fromInteger_d6648df 4)+PE_interp_9b251b28 : Env G -> Int -> Int+PE_interp_9b251b28 (3arg) = \x =>+                              ifThenElse (PE_==_ba2f651f x+                                                         (PE_fromInteger_d6648df 0))+                                         (Delay (PE_fromInteger_d6648df 1))+                                         (Delay (PE_*_ba2f651f (PE_interp_9b251b28 (x ::+                                                                                    (3arg))+                                                                                   (PE_-_ba2f651f x+                                                                                                  (PE_fromInteger_d6648df 1)))+                                                               x))
− test/dsl001/input 
@@ -1,2 +0,0 @@-:printdef testFac-:printdef PE_interp_9b251b28
+ test/dsl001/input.in view
@@ -0,0 +1,2 @@+:printdef testFac+:printdef PE_interp_9b251b28
− test/dsl001/run 
@@ -1,5 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ test001.idr -o test001 --partial-eval-./test001-${IDRIS:-idris} $@ test001.idr --partial-eval --quiet --port none < input-rm -f test001 test001.ibc
+ test/dsl001/run.sh view
@@ -0,0 +1,5 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ test001.idr -o test001 --partial-eval+./test001+${IDRIS:-idris} $@ test001.idr --partial-eval --quiet --port none < input.in+rm -f test001 test001.ibc
− test/dsl002/expected 
@@ -1,1 +0,0 @@-foo
+ test/dsl002/expected.out view
@@ -0,0 +1,1 @@+foo
− test/dsl002/run 
@@ -1,4 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ test014.idr -o test014-./test014-rm -f test014 Resimp.ibc test014.ibc
+ test/dsl002/run.sh view
@@ -0,0 +1,4 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ test014.idr -o test014+./test014+rm -f test014 Resimp.ibc test014.ibc
− test/dsl002/test 
@@ -1,2 +0,0 @@-foo-bar
+ test/dsl002/test.in view
@@ -0,0 +1,2 @@+foo+bar
test/dsl002/test014.idr view
@@ -64,6 +64,6 @@                        else rputStrLn "Error")  main : IO ()-main = run (readH "test")+main = run (readH "test.in")  
− test/dsl003/expected 
@@ -1,2 +0,0 @@-Refl : ARR BOOL (ARR INT UNIT) = ARR BOOL (ARR INT UNIT)-ForAll INT (ForAll INT (ItHolds (Var (FS FZ) === Var FZ))) : Spec []
+ test/dsl003/expected.out view
@@ -0,0 +1,2 @@+Refl : ARR BOOL (ARR INT UNIT) = ARR BOOL (ARR INT UNIT)+ForAll INT (ForAll INT (ItHolds (Var (FS FZ) === Var FZ))) : Spec []
− test/dsl003/run 
@@ -1,3 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ --nocolour --check DSLPi.idr -e test1 -e test2-rm -f *.ibc
+ test/dsl003/run.sh view
@@ -0,0 +1,3 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ --nocolour --check DSLPi.idr -e test1 -e test2+rm -f *.ibc
− test/dsl004/expected 
+ test/dsl004/expected.out view
− test/dsl004/run 
@@ -1,5 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ Door0.idr --check-${IDRIS:-idris} $@ Door1.idr --check-${IDRIS:-idris} $@ Door2.idr --check-rm -f *.ibc
+ test/dsl004/run.sh view
@@ -0,0 +1,5 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ Door0.idr --check+${IDRIS:-idris} $@ Door1.idr --check+${IDRIS:-idris} $@ Door2.idr --check+rm -f *.ibc
− test/effects001/expected 
@@ -1,4 +0,0 @@-["HELLO!!!\n", "WORLD!!!\n", ""]-3-7-Answer: 91
+ test/effects001/expected.out view
@@ -0,0 +1,4 @@+["HELLO!!!\n", "WORLD!!!\n", ""]+3+7+Answer: 91
− test/effects001/run 
@@ -1,6 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ -p effects test021.idr -o test021-${IDRIS:-idris} $@ -p effects test021a.idr -o test021a-./test021-./test021a-rm -f test021 test021a *.ibc
+ test/effects001/run.sh view
@@ -0,0 +1,6 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ -p effects test021.idr -o test021+${IDRIS:-idris} $@ -p effects test021a.idr -o test021a+./test021+./test021a+rm -f test021 test021a *.ibc
test/effects001/test021.idr view
@@ -31,7 +31,7 @@  testFile : TestFileIO () () testFile = do-    Success <- open "testFile" Read+    Success <- open "testFile.in" Read              | (FError err) => do                  putStrLn "Error!"                  pure ()
− test/effects001/testFile 
@@ -1,2 +0,0 @@-HELLO!!!-WORLD!!!
+ test/effects001/testFile.in view
@@ -0,0 +1,2 @@+HELLO!!!+WORLD!!!
− test/effects002/expected 
@@ -1,1 +0,0 @@-[1, 2, 3, 4]
+ test/effects002/expected.out view
@@ -0,0 +1,1 @@+[1, 2, 3, 4]
− test/effects002/run 
@@ -1,4 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ -p effects test025.idr -o test025-./test025-rm -f test025 *.ibc
+ test/effects002/run.sh view
@@ -0,0 +1,4 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ -p effects test025.idr -o test025+./test025+rm -f test025 *.ibc
− test/effects003/expected 
@@ -1,31 +0,0 @@-hangman.idr:204:8-12:-    |-204 | wlen = proof search-    |        ~~~~~-This style of tactic proof is deprecated. See %runElab for the replacement.--------6 guesses left-Enter guess: Good guess!--a-a--6 guesses left-Enter guess: No, sorry--a-a--5 guesses left-Enter guess: No, sorry--a-a--4 guesses left-Enter guess: No, sorry--a-a--3 guesses left-Enter guess: Good guess!-ja-a--3 guesses left-Enter guess: Good guess!-You won! Successfully guessed java
+ test/effects003/expected.out view
@@ -0,0 +1,31 @@+hangman.idr:204:8-12:+    |+204 | wlen = proof search+    |        ~~~~~+This style of tactic proof is deprecated. See %runElab for the replacement.++----++6 guesses left+Enter guess: Good guess!+-a-a++6 guesses left+Enter guess: No, sorry+-a-a++5 guesses left+Enter guess: No, sorry+-a-a++4 guesses left+Enter guess: No, sorry+-a-a++3 guesses left+Enter guess: Good guess!+ja-a++3 guesses left+Enter guess: Good guess!+You won! Successfully guessed java
− test/effects003/input 
@@ -1,6 +0,0 @@-a-e-i-o-j-v
+ test/effects003/input.in view
@@ -0,0 +1,6 @@+a+e+i+o+j+v
− test/effects003/run 
@@ -1,4 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ hangman.idr --nocolour -p effects -o hangman-./hangman < input-rm -f hangman *.ibc
+ test/effects003/run.sh view
@@ -0,0 +1,4 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ hangman.idr --nocolour -p effects -o hangman+./hangman < input.in+rm -f hangman *.ibc
− test/effects004/expected 
@@ -1,11 +0,0 @@-Off we go!-Counter at 0-Counter at 1-Counter at 2-Counter at 3-Counter at 4-Counter at 5-Counter at 6-Counter at 7-Counter at 8-Finished!
+ test/effects004/expected.out view
@@ -0,0 +1,11 @@+Off we go!+Counter at 0+Counter at 1+Counter at 2+Counter at 3+Counter at 4+Counter at 5+Counter at 6+Counter at 7+Counter at 8+Finished!
− test/effects004/input 
@@ -1,10 +0,0 @@---------done-
+ test/effects004/input.in view
@@ -0,0 +1,10 @@+++++++++done+
− test/effects004/run 
@@ -1,4 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ effects004.idr -o effects004 -p effects-./effects004 < input-rm -f effects004 *.ibc
+ test/effects004/run.sh view
@@ -0,0 +1,4 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ effects004.idr -o effects004 -p effects+./effects004 < input.in+rm -f effects004 *.ibc
− test/effects005/expected 
@@ -1,5 +0,0 @@-WARN : Doing the double with 3-6-8-WARN : ["NumOPS"] : Doing the double with 3-6
+ test/effects005/expected.out view
@@ -0,0 +1,5 @@+WARN : Doing the double with 3+6+8+WARN : ["NumOPS"] : Doing the double with 3+6
− test/effects005/run 
@@ -1,6 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ defaultLogger.idr -o default -p effects-./default-${IDRIS:-idris} $@ categoryLogger.idr -o category -p effects-./category-rm -f default category *.ibc
+ test/effects005/run.sh view
@@ -0,0 +1,6 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ defaultLogger.idr -o default -p effects+./default+${IDRIS:-idris} $@ categoryLogger.idr -o category -p effects+./category+rm -f default category *.ibc
− test/error001/expected 
@@ -1,13 +0,0 @@-test002.idr:1:6:-  |-1 | myid : (a : Type) -> a -> a-  |      ^-Universe inconsistency.-        Working on: ./test002.idr.z-        Old domain: (6,6)-        New domain: (6,5)-        Involved constraints: -                ConstraintFC {uconstraint = ./test002.idr.z <= ./test002.idr.a1, ufc = test002.idr:1:6}-                ConstraintFC {uconstraint = ./test002.idr.y < ./test002.idr.z, ufc = test002.idr:1:6}-                ConstraintFC {uconstraint = ./test002.idr.z <= ./test002.idr.a1, ufc = test002.idr:1:6}-
+ test/error001/expected.out view
@@ -0,0 +1,13 @@+test002.idr:1:6:+  |+1 | myid : (a : Type) -> a -> a+  |      ^+Universe inconsistency.+        Working on: ./test002.idr.z+        Old domain: (6,6)+        New domain: (6,5)+        Involved constraints: +                ConstraintFC {uconstraint = ./test002.idr.z <= ./test002.idr.a1, ufc = test002.idr:1:6}+                ConstraintFC {uconstraint = ./test002.idr.y < ./test002.idr.z, ufc = test002.idr:1:6}+                ConstraintFC {uconstraint = ./test002.idr.z <= ./test002.idr.a1, ufc = test002.idr:1:6}+
− test/error001/expected_ttquot 
@@ -1,1 +0,0 @@-test002.idr:5:Universe inconsistency
− test/error001/run 
@@ -1,3 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ test002.idr --check --noprelude --consolewidth 70-rm -f *.ibc
+ test/error001/run.sh view
@@ -0,0 +1,3 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ test002.idr --check --noprelude --consolewidth 70+rm -f *.ibc
− test/error002/expected 
+ test/error002/expected.out view
− test/error002/run 
@@ -1,4 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ test031.idr -o test031-./test031-rm -f test031 *.ibc
+ test/error002/run.sh view
@@ -0,0 +1,4 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ test031.idr -o test031+./test031+rm -f test031 *.ibc
− test/error003/expected 
@@ -1,9 +0,0 @@-ErrorReflection.idr:68:7-20:-   |-68 | bad = Lam (Var Here)-   |       ~~~~~~~~~~~~~~-When checking right hand side of bad with expected type-        Tm [] TUnit--DSL type error: (t(504) => t'(503)) doesn't match ()-
+ test/error003/expected.out view
@@ -0,0 +1,9 @@+ErrorReflection.idr:68:7-20:+   |+68 | bad = Lam (Var Here)+   |       ~~~~~~~~~~~~~~+When checking right hand side of bad with expected type+        Tm [] TUnit++DSL type error: (t(504) => t'(503)) doesn't match ()+
− test/error003/run 
@@ -1,3 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ ErrorReflection.idr --nocolour --check-rm -f *.ibc
+ test/error003/run.sh view
@@ -0,0 +1,3 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ ErrorReflection.idr --nocolour --check+rm -f *.ibc
− test/error004/expected 
@@ -1,20 +0,0 @@-FunErrTest.idr:35:12-18:-   |-35 | badCadr1 = cadr []-   |            ~~~~~~~-When checking right hand side of badCadr1 with expected type-        Int--When checking argument cons2 to function FunErrTest.cadr:-        Could not prove that [] has at least two elements.--FunErrTest.idr:38:12-19:-   |-38 | badCadr2 = cadr [1]-   |            ~~~~~~~~-When checking right hand side of badCadr2 with expected type-        Int--When checking argument cons2 to function FunErrTest.cadr:-        Could not prove that [] has at least two elements.-
+ test/error004/expected.out view
@@ -0,0 +1,20 @@+FunErrTest.idr:35:12-18:+   |+35 | badCadr1 = cadr []+   |            ~~~~~~~+When checking right hand side of badCadr1 with expected type+        Int++When checking argument cons2 to function FunErrTest.cadr:+        Could not prove that [] has at least two elements.++FunErrTest.idr:38:12-19:+   |+38 | badCadr2 = cadr [1]+   |            ~~~~~~~~+When checking right hand side of badCadr2 with expected type+        Int++When checking argument cons2 to function FunErrTest.cadr:+        Could not prove that [] has at least two elements.+
− test/error004/run 
@@ -1,3 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ FunErrTest.idr --nocolour --check-rm -f *.ibc
+ test/error004/run.sh view
@@ -0,0 +1,3 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ FunErrTest.idr --nocolour --check+rm -f *.ibc
− test/error005/expected 
@@ -1,56 +0,0 @@-error005.idr:11:7:-   |-11 | two = 2-   |       ^-When checking right hand side of two with expected type-        Fin 2--When checking argument prf to function Data.Fin.fromInteger:-        When using 2 as a literal for a Fin 2 -                2 is not strictly less than 2--error005.idr:14:12:-   |-14 | hahaha n = 0-   |            ^-When checking right hand side of hahaha with expected type-        Fin n--When checking argument prf to function Data.Fin.fromInteger:-        When using 0 as a literal for a Fin n -                0 is not strictly less than n--error005.idr:20:11:-   |-20 | notOk n = 2-   |           ^-When checking right hand side of notOk with expected type-        Fin (plus 2 n)--When checking argument prf to function Data.Fin.fromInteger:-        When using 2 as a literal for a Fin (S (S n)) -                2 is not strictly less than S (S n)--error005.idr:23:12-24:-   |-23 | b0rken n = fromInteger n-   |            ~~~~~~~~~~~~~-When checking right hand side of b0rken with expected type-        Fin 3--When checking argument prf to function Data.Fin.fromInteger:-        When using n as a literal for a Fin 3 -                Could not show that n is less than 3 because n is a bound-                variable instead of a constant Integer--error005.idr:26:17:-   |-26 | x = the (Fin 4) 5-   |                 ^-When checking right hand side of x with expected type-        Fin 4--When checking argument prf to function Data.Fin.fromInteger:-        When using 5 as a literal for a Fin 4 -                5 is not strictly less than 4-
+ test/error005/expected.out view
@@ -0,0 +1,56 @@+error005.idr:11:7:+   |+11 | two = 2+   |       ^+When checking right hand side of two with expected type+        Fin 2++When checking argument prf to function Data.Fin.fromInteger:+        When using 2 as a literal for a Fin 2 +                2 is not strictly less than 2++error005.idr:14:12:+   |+14 | hahaha n = 0+   |            ^+When checking right hand side of hahaha with expected type+        Fin n++When checking argument prf to function Data.Fin.fromInteger:+        When using 0 as a literal for a Fin n +                0 is not strictly less than n++error005.idr:20:11:+   |+20 | notOk n = 2+   |           ^+When checking right hand side of notOk with expected type+        Fin (plus 2 n)++When checking argument prf to function Data.Fin.fromInteger:+        When using 2 as a literal for a Fin (S (S n)) +                2 is not strictly less than S (S n)++error005.idr:23:12-24:+   |+23 | b0rken n = fromInteger n+   |            ~~~~~~~~~~~~~+When checking right hand side of b0rken with expected type+        Fin 3++When checking argument prf to function Data.Fin.fromInteger:+        When using n as a literal for a Fin 3 +                Could not show that n is less than 3 because n is a bound+                variable instead of a constant Integer++error005.idr:26:17:+   |+26 | x = the (Fin 4) 5+   |                 ^+When checking right hand side of x with expected type+        Fin 4++When checking argument prf to function Data.Fin.fromInteger:+        When using 5 as a literal for a Fin 4 +                5 is not strictly less than 4+
− test/error005/run 
@@ -1,3 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ --check --nocolour error005.idr-rm -f *.ibc
+ test/error005/run.sh view
@@ -0,0 +1,3 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ --check --nocolour error005.idr+rm -f *.ibc
− test/error006/expected 
@@ -1,21 +0,0 @@-WithPatsNoWith.idr:4:1-13:-  |-4 | foo 1 | 2 | 3 = True-  | ~~~~~~~~~~~~~-When checking left hand side of foo:-unexpected patterns outside of "with" block--WithPatsNoWith.idr:9:3-16:-  |-9 |   foo2 n | 1 | 2 = True-  |   ~~~~~~~~~~~~~~-When checking left hand side of with block in WithPatsNoWith.foo2:-unexpected extra "with" patterns--WithPatsNoWith.idr:15:5-24:-   |-15 |     foo3 _ _ | 2 | 3 | 4 = True-   |     ~~~~~~~~~~~~~~~~~~~~-When checking left hand side of with block in with block in WithPatsNoWith.foo3:-unexpected extra "with" patterns-
+ test/error006/expected.out view
@@ -0,0 +1,21 @@+WithPatsNoWith.idr:4:1-13:+  |+4 | foo 1 | 2 | 3 = True+  | ~~~~~~~~~~~~~+When checking left hand side of foo:+unexpected patterns outside of "with" block++WithPatsNoWith.idr:9:3-16:+  |+9 |   foo2 n | 1 | 2 = True+  |   ~~~~~~~~~~~~~~+When checking left hand side of with block in WithPatsNoWith.foo2:+unexpected extra "with" patterns++WithPatsNoWith.idr:15:5-24:+   |+15 |     foo3 _ _ | 2 | 3 | 4 = True+   |     ~~~~~~~~~~~~~~~~~~~~+When checking left hand side of with block in with block in WithPatsNoWith.foo3:+unexpected extra "with" patterns+
− test/error006/run 
@@ -1,3 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ --check --nocolour WithPatsNoWith.idr-rm -f *.ibc
+ test/error006/run.sh view
@@ -0,0 +1,3 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ --check --nocolour WithPatsNoWith.idr+rm -f *.ibc
− test/error007/expected 
@@ -1,19 +0,0 @@-error007.idr:26:7-29:-   |-26 |       send_page conn str code -- (prim__zextB32_Int code)-   |       ~~~~~~~~~~~~~~~~~~~~~~~-When checking right hand side of answer_to_connection with expected type-        IO Int--When checking argument code to function Main.send_page:-        Type mismatch between-                translate I32 (Type of code)-        and-                Int (Expected type)-        -        Specifically:-                Type mismatch between-                        Bits32-                and-                        Int-
+ test/error007/expected.out view
@@ -0,0 +1,19 @@+error007.idr:26:7-29:+   |+26 |       send_page conn str code -- (prim__zextB32_Int code)+   |       ~~~~~~~~~~~~~~~~~~~~~~~+When checking right hand side of answer_to_connection with expected type+        IO Int++When checking argument code to function Main.send_page:+        Type mismatch between+                translate I32 (Type of code)+        and+                Int (Expected type)+        +        Specifically:+                Type mismatch between+                        Bits32+                and+                        Int+
− test/error007/run 
@@ -1,3 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ --check --nocolour error007.idr -p contrib-rm -f *.ibc
+ test/error007/run.sh view
@@ -0,0 +1,3 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ --check --nocolour error007.idr -p contrib+rm -f *.ibc
− test/error008/expected 
@@ -1,14 +0,0 @@-error008.idr:3:4:-  |-3 | s2 : x + sum Nil = x * fromInteger 0-  |    ^-When checking type of Main.s2:-Can't disambiguate name: Prelude.List.Nil, Data.Vect.Nil--error008a.idr:3:4:-  |-3 | s1 : Num a => {x : a} -> x + sum {a} Nil = x -- * fromInteger 0-  |    ^-When checking type of Main.s1:-Can't disambiguate name: Prelude.List.Nil, Data.Vect.Nil-
+ test/error008/expected.out view
@@ -0,0 +1,14 @@+error008.idr:3:4:+  |+3 | s2 : x + sum Nil = x * fromInteger 0+  |    ^+When checking type of Main.s2:+Can't disambiguate name: Prelude.List.Nil, Data.Vect.Nil++error008a.idr:3:4:+  |+3 | s1 : Num a => {x : a} -> x + sum {a} Nil = x -- * fromInteger 0+  |    ^+When checking type of Main.s1:+Can't disambiguate name: Prelude.List.Nil, Data.Vect.Nil+
− test/error008/run 
@@ -1,4 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ --check --nocolour error008.idr-${IDRIS:-idris} $@ --check --nocolour error008a.idr-rm -f *.ibc
+ test/error008/run.sh view
@@ -0,0 +1,4 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ --check --nocolour error008.idr+${IDRIS:-idris} $@ --check --nocolour error008a.idr+rm -f *.ibc
− test/error009/expected 
@@ -1,1 +0,0 @@-Uncaught error: Nothing found in namespace "Foo.Bar".
+ test/error009/expected.out view
@@ -0,0 +1,1 @@+Uncaught error: Nothing found in namespace "Foo.Bar".
− test/error009/run 
@@ -1,2 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ -e "with Foo.Bar 42"
+ test/error009/run.sh view
@@ -0,0 +1,2 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ -e "with Foo.Bar 42"
− test/ffi001/expected 
@@ -1,1 +0,0 @@-0.9995736030415051
+ test/ffi001/expected.out view
@@ -0,0 +1,1 @@+0.9995736030415051
− test/ffi001/run 
@@ -1,3 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ --quiet --port none --nocolour test022.idr --exec main-rm -f *.ibc
+ test/ffi001/run.sh view
@@ -0,0 +1,3 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ --quiet --port none --nocolour test022.idr --exec main+rm -f *.ibc
− test/ffi002/expected 
@@ -1,6 +0,0 @@-test023.idr:20:26-36:-   |-20 | %provide (t : Type) with badProvider-   |                          ~~~~~~~~~~~-Type provider error: Always fails-
+ test/ffi002/expected.out view
@@ -0,0 +1,6 @@+test023.idr:20:26-36:+   |+20 | %provide (t : Type) with badProvider+   |                          ~~~~~~~~~~~+Type provider error: Always fails+
− test/ffi002/run 
@@ -1,3 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ --quiet --port none test023.idr -o test023-rm -f test023 *.ibc
+ test/ffi002/run.sh view
@@ -0,0 +1,3 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ --quiet --port none test023.idr -o test023+rm -f test023 *.ibc
− test/ffi003/expected 
@@ -1,1 +0,0 @@-testtest
+ test/ffi003/expected.out view
@@ -0,0 +1,1 @@+testtest
− test/ffi003/input 
@@ -1,1 +0,0 @@-test
+ test/ffi003/input.in view
@@ -0,0 +1,1 @@+test
− test/ffi003/run 
@@ -1,3 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ --quiet --port none --nocolour test024.idr --exec main < input-rm -f *.ibc
+ test/ffi003/run.sh view
@@ -0,0 +1,3 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ --quiet --port none --nocolour test024.idr --exec main < input.in+rm -f *.ibc
− test/ffi004/expected 
+ test/ffi004/expected.out view
− test/ffi004/run 
@@ -1,3 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ --quiet --port none --nocolour --check test026.idr-rm -f *.ibc
+ test/ffi004/run.sh view
@@ -0,0 +1,3 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ --quiet --port none --nocolour --check test026.idr+rm -f *.ibc
− test/ffi005/expected 
@@ -1,1 +0,0 @@-oops
+ test/ffi005/expected.out view
@@ -0,0 +1,1 @@+oops
− test/ffi005/run 
@@ -1,5 +0,0 @@-#!/usr/bin/env bash--${IDRIS:-idris} $@ Postulate.idr -o postulate-./postulate-rm -f postulate *.ibc
+ test/ffi005/run.sh view
@@ -0,0 +1,5 @@+#!/usr/bin/env bash++${IDRIS:-idris} $@ Postulate.idr -o postulate+./postulate+rm -f postulate *.ibc
− test/ffi006/expected 
@@ -1,2 +0,0 @@-Ready to show...-[10, 20, 30, 40]
+ test/ffi006/expected.out view
@@ -0,0 +1,2 @@+Ready to show...+[10, 20, 30, 40]
− test/ffi006/run 
@@ -1,5 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ ffi006.idr --interface -o ffi006.o-${CC:=cc} ffi006.c ffi006.o `${IDRIS:-idris} $@ --include` `${IDRIS:-idris} $@ --link` -o ffi006-./ffi006-rm -f ffi006 *.ibc *.o *.h
+ test/ffi006/run.sh view
@@ -0,0 +1,5 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ ffi006.idr --interface -o ffi006.o+${CC:=cc} ffi006.c ffi006.o `${IDRIS:-idris} $@ --include` `${IDRIS:-idris} $@ --link` -o ffi006+./ffi006+rm -f ffi006 *.ibc *.o *.h
− test/ffi007/expected 
@@ -1,10 +0,0 @@-8-5-Before calling callback-In an Idris callback-After calling callback-00000377-I'm dynamic 3-6-7-3
+ test/ffi007/expected.out view
@@ -0,0 +1,10 @@+8+5+Before calling callback+In an Idris callback+After calling callback+00000377+I'm dynamic 3+6+7+3
− test/ffi007/run 
@@ -1,4 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ ffi007.idr -o ffi007 --cg-opt "ffi007.c"-./ffi007-rm -f ffi007 *.ibc
+ test/ffi007/run.sh view
@@ -0,0 +1,4 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ ffi007.idr -o ffi007 --cg-opt "ffi007.c"+./ffi007+rm -f ffi007 *.ibc
− test/ffi008/expected 
@@ -1,5 +0,0 @@-True-True-a: 122 b: 0-4-00000010
+ test/ffi008/expected.out view
@@ -0,0 +1,5 @@+True+True+a: 122 b: 0+4+00000010
− test/ffi008/run 
@@ -1,4 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ ffi008.idr -o ffi008 -p contrib --cg-opt "ffi008.c"-./ffi008-rm -f ffi008 *.ibc
+ test/ffi008/run.sh view
@@ -0,0 +1,4 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ ffi008.idr -o ffi008 -p contrib --cg-opt "ffi008.c"+./ffi008+rm -f ffi008 *.ibc
− test/ffi009/expected 
@@ -1,1 +0,0 @@-"I should be seen."
+ test/ffi009/expected.out view
@@ -0,0 +1,1 @@+"I should be seen."
− test/ffi009/run 
@@ -1,5 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ Bad.idr -o bad --cg-opt "ffi009.c" --cg-opt "-fno-strict-overflow"-${IDRIS:-idris} $@ Good.idr -o good --cg-opt "ffi009.c"-./good-rm -f *.ibc good
+ test/ffi009/run.sh view
@@ -0,0 +1,5 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ Bad.idr -o bad --cg-opt "ffi009.c" --cg-opt "-fno-strict-overflow"+${IDRIS:-idris} $@ Good.idr -o good --cg-opt "ffi009.c"+./good+rm -f *.ibc good
− test/ffi010/expected 
@@ -1,3 +0,0 @@-start-olare-end
+ test/ffi010/expected.out view
@@ -0,0 +1,3 @@+start+olare+end
− test/ffi010/run 
@@ -1,4 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ ffi010.idr -o ffi010-./ffi010-rm -f ffi010 *.ibc
+ test/ffi010/run.sh view
@@ -0,0 +1,4 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ ffi010.idr -o ffi010+./ffi010+rm -f ffi010 *.ibc
− test/ffi011/expected 
@@ -1,2 +0,0 @@-Ready to show...-[10, 20, 30, 40]
+ test/ffi011/expected.out view
@@ -0,0 +1,2 @@+Ready to show...+[10, 20, 30, 40]
− test/ffi011/ffi011 
@@ -1,7 +0,0 @@-l = require("./lib.js");--x = l.cons(10, l.cons(20, l.nil()));-y = l.cons(30, l.cons(40, l.nil()));-z = l.addLists(x, y);--console.log(l.showList(z));
+ test/ffi011/ffi011.js view
@@ -0,0 +1,7 @@+l = require("./lib.js");++x = l.cons(10, l.cons(20, l.nil()));+y = l.cons(30, l.cons(40, l.nil()));+z = l.addLists(x, y);++console.log(l.showList(z));
− test/ffi011/run 
@@ -1,4 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ ffi011.idr --interface -o lib.js-node ./ffi011-rm -f *.ibc lib.js
+ test/ffi011/run.sh view
@@ -0,0 +1,4 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ ffi011.idr --interface -o lib.js+node ./ffi011.js+rm -f *.ibc lib.js
− test/ffi012/expected 
@@ -1,1 +0,0 @@-Hello?
+ test/ffi012/expected.out view
@@ -0,0 +1,1 @@+Hello?
− test/ffi012/ffi012 
@@ -1,3 +0,0 @@-l = require("./lib.js");--l.f()
+ test/ffi012/ffi012.js view
@@ -0,0 +1,3 @@+l = require("./lib.js");++l.f()
− test/ffi012/run 
@@ -1,4 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ ffi012.idr --interface -o lib.js-node ./ffi012-rm -f *.ibc lib.js
+ test/ffi012/run.sh view
@@ -0,0 +1,4 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ ffi012.idr --interface -o lib.js+node ./ffi012+rm -f *.ibc lib.js
− test/ffi013/expected 
@@ -1,4 +0,0 @@-success-confirmed-success-confirmed
+ test/ffi013/expected.out view
@@ -0,0 +1,4 @@+success+confirmed+success+confirmed
− test/ffi013/run 
@@ -1,17 +0,0 @@-#!/usr/bin/env bash-echo "test" > remove.me-${IDRIS:-idris} $@ --quiet --port none ffi013.idr -o ffi013-./ffi013-if [ -f "remove.me" ]; then-    echo "still exists"-else -    echo "confirmed"-fi-echo "test2" > remove.me-${IDRIS:-idris} $@ --quiet --port none --nocolour ffi013.idr --exec main-if [ -f "remove.me" ]; then-    echo "still exists"-else -    echo "confirmed"-fi-rm -f ffi013 remove.me *.ibc
+ test/ffi013/run.sh view
@@ -0,0 +1,17 @@+#!/usr/bin/env bash+echo "test" > remove.me+${IDRIS:-idris} $@ --quiet --port none ffi013.idr -o ffi013+./ffi013+if [ -f "remove.me" ]; then+    echo "still exists"+else +    echo "confirmed"+fi+echo "test2" > remove.me+${IDRIS:-idris} $@ --quiet --port none --nocolour ffi013.idr --exec main+if [ -f "remove.me" ]; then+    echo "still exists"+else +    echo "confirmed"+fi+rm -f ffi013 remove.me *.ibc
− test/folding001/expected 
@@ -1,4 +0,0 @@-([], []) -> ([], [])-([1], [1]) -> ([1], [1])-([1, 2, 3], [1, 2, 3]) -> ([1, 2, 3], [1, 2, 3])-([3, 2, 1], [3, 2, 1]) -> ([3, 2, 1], [3, 2, 1])
+ test/folding001/expected.out view
@@ -0,0 +1,4 @@+([], []) -> ([], [])+([1], [1]) -> ([1], [1])+([1, 2, 3], [1, 2, 3]) -> ([1, 2, 3], [1, 2, 3])+([3, 2, 1], [3, 2, 1]) -> ([3, 2, 1], [3, 2, 1])
− test/folding001/run 
@@ -1,4 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ folding001.idr -o folding001-./folding001-rm -f folding001 *.ibc
+ test/folding001/run.sh view
@@ -0,0 +1,4 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ folding001.idr -o folding001+./folding001+rm -f folding001 *.ibc
− test/idrisdoc001/expected 
@@ -1,3 +0,0 @@-Warning: Ignoring empty or non-existing namespace 'TestEmpty'-Warning: Ignoring empty or non-existing namespace 'TestPrivate'-No namespaces to generate documentation for
+ test/idrisdoc001/expected.out view
@@ -0,0 +1,3 @@+Warning: Ignoring empty or non-existing namespace 'TestEmpty'+Warning: Ignoring empty or non-existing namespace 'TestPrivate'+No namespaces to generate documentation for
− test/idrisdoc001/run 
@@ -1,4 +0,0 @@-#!/usr/bin/env bash-# Tests that no documentation is built for empty and/or private-only namespaces-${IDRIS:-idris} $@ --mkdoc test_empty.ipkg-rm -rf *.ibc *_doc
+ test/idrisdoc001/run.sh view
@@ -0,0 +1,4 @@+#!/usr/bin/env bash+# Tests that no documentation is built for empty and/or private-only namespaces+${IDRIS:-idris} $@ --mkdoc test_empty.ipkg+rm -rf *.ibc *_doc
− test/idrisdoc002/expected 
@@ -1,1 +0,0 @@-Functions are documented
+ test/idrisdoc002/expected.out view
@@ -0,0 +1,1 @@+Functions are documented
− test/idrisdoc002/run 
@@ -1,5 +0,0 @@-#!/usr/bin/env bash-# Tests that documentation is generated for functions-${IDRIS:-idris} $@ --mkdoc test_functions.ipkg-[ -d test_functions_doc ] && echo "Functions are documented"-rm -rf *.ibc *_doc
+ test/idrisdoc002/run.sh view
@@ -0,0 +1,5 @@+#!/usr/bin/env bash+# Tests that documentation is generated for functions+${IDRIS:-idris} $@ --mkdoc test_functions.ipkg+[ -d test_functions_doc ] && echo "Functions are documented"+rm -rf *.ibc *_doc
− test/idrisdoc003/expected 
@@ -1,1 +0,0 @@-Data types are documented
+ test/idrisdoc003/expected.out view
@@ -0,0 +1,1 @@+Data types are documented
− test/idrisdoc003/run 
@@ -1,5 +0,0 @@-#!/usr/bin/env bash-# Tests that documentation is generated for data types-${IDRIS:-idris} $@ --mkdoc test_datatypes.ipkg-[ -d test_datatypes_doc ] && echo "Data types are documented"-rm -rf *.ibc *_doc
+ test/idrisdoc003/run.sh view
@@ -0,0 +1,5 @@+#!/usr/bin/env bash+# Tests that documentation is generated for data types+${IDRIS:-idris} $@ --mkdoc test_datatypes.ipkg+[ -d test_datatypes_doc ] && echo "Data types are documented"+rm -rf *.ibc *_doc
− test/idrisdoc004/expected 
@@ -1,1 +0,0 @@-Interfaces are documented
+ test/idrisdoc004/expected.out view
@@ -0,0 +1,1 @@+Interfaces are documented
− test/idrisdoc004/run 
@@ -1,5 +0,0 @@-#!/usr/bin/env bash-# Tests that documentation is generated for interfaces-${IDRIS:-idris} $@ --mkdoc test_interfaces.ipkg-[ -d test_interfaces_doc ] && echo "Interfaces are documented"-rm -rf *.ibc *_doc
+ test/idrisdoc004/run.sh view
@@ -0,0 +1,5 @@+#!/usr/bin/env bash+# Tests that documentation is generated for interfaces+${IDRIS:-idris} $@ --mkdoc test_interfaces.ipkg+[ -d test_interfaces_doc ] && echo "Interfaces are documented"+rm -rf *.ibc *_doc
− test/idrisdoc005/expected 
@@ -1,2 +0,0 @@-TestTracing: Check-Prelude.Bool: Check
+ test/idrisdoc005/expected.out view
@@ -0,0 +1,2 @@+TestTracing: Check+Prelude.Bool: Check
− test/idrisdoc005/run 
@@ -1,6 +0,0 @@-#!/usr/bin/env bash-# Tests that references to other namespaces are traced-${IDRIS:-idris} $@ --mkdoc test_tracing.ipkg-[ -f test_tracing_doc/docs/TestTracing.html ] && echo "TestTracing: Check"-[ -f test_tracing_doc/docs/Prelude.Bool.html ] && echo "Prelude.Bool: Check"-rm -rf *.ibc *_doc
+ test/idrisdoc005/run.sh view
@@ -0,0 +1,6 @@+#!/usr/bin/env bash+# Tests that references to other namespaces are traced+${IDRIS:-idris} $@ --mkdoc test_tracing.ipkg+[ -f test_tracing_doc/docs/TestTracing.html ] && echo "TestTracing: Check"+[ -f test_tracing_doc/docs/Prelude.Bool.html ] && echo "Prelude.Bool: Check"+rm -rf *.ibc *_doc
− test/idrisdoc006/expected 
@@ -1,5 +0,0 @@-IdrisDoc file written-A.fully.Qualified.NAME.html-B.html-A.fully.Qualified.NAME is in the index-B is in the index
+ test/idrisdoc006/expected.out view
@@ -0,0 +1,5 @@+IdrisDoc file written+A.fully.Qualified.NAME.html+B.html+A.fully.Qualified.NAME is in the index+B is in the index
− test/idrisdoc006/run 
@@ -1,17 +0,0 @@-#!/usr/bin/env bash-# Tests that documentation properly is merged with existent.-${IDRIS:-idris} $@ --mkdoc package_a.ipkg-[ -f test_merge_doc/IdrisDoc ] && echo "IdrisDoc file written"-${IDRIS:-idris} $@ --mkdoc package_b.ipkg-ls -1p test_merge_doc/docs-if grep -q "href\\=\"docs/A.fully.Qualified.NAME\\.html\"" test_merge_doc/index.html; then-  echo A.fully.Qualified.NAME is in the index-else-  echo A.fully.Qualified.NAME is NOT in the index-fi-if grep -q "href\\=\"docs/B\\.html\"" test_merge_doc/index.html; then-  echo B is in the index-else-  echo B is NOT in the index-fi-rm -rf *.ibc *_doc A/fully/Qualified/NAME.ibc
+ test/idrisdoc006/run.sh view
@@ -0,0 +1,17 @@+#!/usr/bin/env bash+# Tests that documentation properly is merged with existent.+${IDRIS:-idris} $@ --mkdoc package_a.ipkg+[ -f test_merge_doc/IdrisDoc ] && echo "IdrisDoc file written"+${IDRIS:-idris} $@ --mkdoc package_b.ipkg+ls -1p test_merge_doc/docs+if grep -q "href\\=\"docs/A.fully.Qualified.NAME\\.html\"" test_merge_doc/index.html; then+  echo A.fully.Qualified.NAME is in the index+else+  echo A.fully.Qualified.NAME is NOT in the index+fi+if grep -q "href\\=\"docs/B\\.html\"" test_merge_doc/index.html; then+  echo B is in the index+else+  echo B is NOT in the index+fi+rm -rf *.ibc *_doc A/fully/Qualified/NAME.ibc
− test/idrisdoc007/expected 
@@ -1,1 +0,0 @@-Exit status (expects 1): 1
+ test/idrisdoc007/expected.out view
@@ -0,0 +1,1 @@+Exit status (expects 1): 1
− test/idrisdoc007/run 
@@ -1,6 +0,0 @@-#!/usr/bin/env bash-# Tests that documentation only is written when safe-mkdir do_not_delete_doc-${IDRIS:-idris} $@ --mkdoc package.ipkg > nowhere-echo Exit status \(expects 1\): $?-rm -rf do_not_delete_doc *.ibc nowhere
+ test/idrisdoc007/run.sh view
@@ -0,0 +1,6 @@+#!/usr/bin/env bash+# Tests that documentation only is written when safe+mkdir do_not_delete_doc+${IDRIS:-idris} $@ --mkdoc package.ipkg > nowhere+echo Exit status \(expects 1\): $?+rm -rf do_not_delete_doc *.ibc nowhere
− test/idrisdoc008/expected 
@@ -1,2 +0,0 @@-Abstract members are documented-Public members are documented
+ test/idrisdoc008/expected.out view
@@ -0,0 +1,2 @@+Abstract members are documented+Public members are documented
− test/idrisdoc008/run 
@@ -1,6 +0,0 @@-#!/usr/bin/env bash-# Tests that documentation is generated for both public and abstract members.-${IDRIS:-idris} $@ --mkdoc visibility.ipkg-[ -f visibility_doc/docs/Abstract.html ] && echo "Abstract members are documented"-[ -f visibility_doc/docs/Visible.html ] && echo "Public members are documented"-rm -rf *.ibc *_doc
+ test/idrisdoc008/run.sh view
@@ -0,0 +1,6 @@+#!/usr/bin/env bash+# Tests that documentation is generated for both public and abstract members.+${IDRIS:-idris} $@ --mkdoc visibility.ipkg+[ -f visibility_doc/docs/Abstract.html ] && echo "Abstract members are documented"+[ -f visibility_doc/docs/Visible.html ] && echo "Public members are documented"+rm -rf *.ibc *_doc
− test/idrisdoc009/expected 
@@ -1,30 +0,0 @@-Data type Test.Test : Type-    Docs for datatype Test.-    -    The function is: public export-Constructors:-    MkTest : Test-        -        -        The function is: public export-Module Test:-    Docs for module Test.-    -    It is a great module. Prelude thingy:-    -        > "foo" ++ "bar"-        "foobar"-    -    Imported thingy:-    -        > 0.0 :+ 0.2-        0.0 :+ 0.2-    -    Type error:-    -        "foo" + 2-    -    From this module:-    -        > MkTest-        MkTest
+ test/idrisdoc009/expected.out view
@@ -0,0 +1,30 @@+Data type Test.Test : Type+    Docs for datatype Test.+    +    The function is: public export+Constructors:+    MkTest : Test+        +        +        The function is: public export+Module Test:+    Docs for module Test.+    +    It is a great module. Prelude thingy:+    +        > "foo" ++ "bar"+        "foobar"+    +    Imported thingy:+    +        > 0.0 :+ 0.2+        0.0 :+ 0.2+    +    Type error:+    +        "foo" + 2+    +    From this module:+    +        > MkTest+        MkTest
− test/idrisdoc009/input 
@@ -1,2 +0,0 @@-:consolewidth infinite-:doc Test
+ test/idrisdoc009/input.in view
@@ -0,0 +1,2 @@+:consolewidth infinite+:doc Test
− test/idrisdoc009/run 
@@ -1,3 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ --nocolour --quiet --port none Test.idr < input-rm -f *.ibc
+ test/idrisdoc009/run.sh view
@@ -0,0 +1,3 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ --nocolour --quiet --port none Test.idr < input.in+rm -f *.ibc
− test/interactive001/expected 
@@ -1,20 +0,0 @@-isElem x [] = ?isElem_rhs_1-isElem x (y :: xs) = ?isElem_rhs_3--   localZipWith f (_ :: _) (x :: ys) = ?localZipWith_rhs_1--f x :: map f xs-isElem2 x (y :: ys) with (_)-        isElem2 x (y :: ys) | with_pat = ?isElem2_rhs--  isElem3 y (y :: ys) | (Yes Refl) = ?isElem3_rhs_3--              [] => ?bar_1-              (x :: ys) => ?bar_2--elemVoid1 Here impossible-elemVoid1 (There _) impossible--                   Here impossible-                   (There _) impossible-
+ test/interactive001/expected.out view
@@ -0,0 +1,20 @@+isElem x [] = ?isElem_rhs_1+isElem x (y :: xs) = ?isElem_rhs_3++   localZipWith f (_ :: _) (x :: ys) = ?localZipWith_rhs_1++f x :: map f xs+isElem2 x (y :: ys) with (_)+        isElem2 x (y :: ys) | with_pat = ?isElem2_rhs++  isElem3 y (y :: ys) | (Yes Refl) = ?isElem3_rhs_3++              [] => ?bar_1+              (x :: ys) => ?bar_2++elemVoid1 Here impossible+elemVoid1 (There _) impossible++                   Here impossible+                   (There _) impossible+
− test/interactive001/input 
@@ -1,8 +0,0 @@-:casesplit 12 xs-:casesplit 18 ys-:proofsearch 22 maprhs-:makewith 26 isElem2-:casesplit 31 p-:casesplit 36 xs'-:casesplit 39 x-:casesplit 43 case_val
+ test/interactive001/input.in view
@@ -0,0 +1,8 @@+:casesplit 12 xs+:casesplit 18 ys+:proofsearch 22 maprhs+:makewith 26 isElem2+:casesplit 31 p+:casesplit 36 xs'+:casesplit 39 x+:casesplit 43 case_val
− test/interactive001/run 
@@ -1,5 +0,0 @@-#!/usr/bin/env bash--${IDRIS:-idris} $@ --quiet --port none --indent-with 8 interactive001.idr < input--rm -f *.ibc
+ test/interactive001/run.sh view
@@ -0,0 +1,5 @@+#!/usr/bin/env bash++${IDRIS:-idris} $@ --quiet --port none --indent-with 8 interactive001.idr < input.in++rm -f *.ibc
− test/interactive002/expected 
@@ -1,10 +0,0 @@-Nat-Nat-Nat-Nat-Vect (n + m) a-Nat-Nat-(S n)-String-()
+ test/interactive002/expected.out view
@@ -0,0 +1,10 @@+Nat+Nat+Nat+Nat+Vect (n + m) a+Nat+Nat+(S n)+String+()
− test/interactive002/input 
@@ -1,11 +0,0 @@-:ps 3 foo_arg1-:ps 3 foo_arg2-:ps 3 foo_arg3-:ps 3 foo_ret-:ps 7 bar_out-:ps 10 plus_in1-:ps 10 plus_out-:ps 14 what-:ps 17 ifoo_arg1-:ps 17 ifoo_out-
+ test/interactive002/input.in view
@@ -0,0 +1,11 @@+:ps 3 foo_arg1+:ps 3 foo_arg2+:ps 3 foo_arg3+:ps 3 foo_ret+:ps 7 bar_out+:ps 10 plus_in1+:ps 10 plus_out+:ps 14 what+:ps 17 ifoo_arg1+:ps 17 ifoo_out+
− test/interactive002/run 
@@ -1,3 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ --quiet --port none interactive002.idr < input-rm -f *.ibc
+ test/interactive002/run.sh view
@@ -0,0 +1,3 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ --quiet --port none interactive002.idr < input.in+rm -f *.ibc
− test/interactive003/expected 
@@ -1,5 +0,0 @@-ys-x :: app xs ys-[]-f x y :: vzipWith f xs ys-0 :: word_length xs
+ test/interactive003/expected.out view
@@ -0,0 +1,5 @@+ys+x :: app xs ys+[]+f x y :: vzipWith f xs ys+0 :: word_length xs
− test/interactive003/input 
@@ -1,5 +0,0 @@-:ps 4 app_rhs_1-:ps 5 app_rhs_2-:ps 8 vzipWith_rhs_3-:ps 9 vzipWith_rhs_1-:ps 13 word_length_rhs_2
+ test/interactive003/input.in view
@@ -0,0 +1,5 @@+:ps 4 app_rhs_1+:ps 5 app_rhs_2+:ps 8 vzipWith_rhs_3+:ps 9 vzipWith_rhs_1+:ps 13 word_length_rhs_2
− test/interactive003/run 
@@ -1,3 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ --quiet --port none interactive003.idr < input-rm -f *.ibc
+ test/interactive003/run.sh view
@@ -0,0 +1,3 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ --quiet --port none interactive003.idr < input.in+rm -f *.ibc
− test/interactive004/expected 
@@ -1,2 +0,0 @@-plus ?foo_rhs2 ?foo_rhs3-(append k m ?append_rhs2 ?append_rhs3)
+ test/interactive004/expected.out view
@@ -0,0 +1,2 @@+plus ?foo_rhs2 ?foo_rhs3+(append k m ?append_rhs2 ?append_rhs3)
− test/interactive004/input 
@@ -1,2 +0,0 @@-:ref 4 foo_rhs1 plus -:ref 8 append_rhs1 append
+ test/interactive004/input.in view
@@ -0,0 +1,2 @@+:ref 4 foo_rhs1 plus +:ref 8 append_rhs1 append
− test/interactive004/run 
@@ -1,3 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ --quiet --port none interactive004.idr < input-rm -f *.ibc
+ test/interactive004/run.sh view
@@ -0,0 +1,3 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ --quiet --port none interactive004.idr < input.in+rm -f *.ibc
− test/interactive005/expected 
@@ -1,36 +0,0 @@-3 : Nat-Hello, World-Main.main : IO ()-    This is a docstring-    -    The function is: Total & public export-Main.main is Total-Hello, World-id : a -> a-Prelude.Basics.id : {a : Type} -> a -> a-id : a -> a--	 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS ``AS IS'' AND ANY  -	 EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE     -	 IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR    -	 PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE   -	 LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR   -	 CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF  -	 SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR       -	 BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, -	 WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE  -	 OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN-	 IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.--Main.main : IO ()-    This-    is a-    docstring-    -    The function is: Total & public export-Main.main : IO ()-    This is a docstring-    -    The function is: Total & public export-Nat2 : Type-Invalid filename for compiler output "Test.idr"
+ test/interactive005/expected.out view
@@ -0,0 +1,36 @@+3 : Nat+Hello, World+Main.main : IO ()+    This is a docstring+    +    The function is: Total & public export+Main.main is Total+Hello, World+id : a -> a+Prelude.Basics.id : {a : Type} -> a -> a+id : a -> a++	 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS ``AS IS'' AND ANY  +	 EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE     +	 IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR    +	 PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE   +	 LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR   +	 CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF  +	 SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR       +	 BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, +	 WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE  +	 OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN+	 IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.++Main.main : IO ()+    This+    is a+    docstring+    +    The function is: Total & public export+Main.main : IO ()+    This is a docstring+    +    The function is: Total & public export+Nat2 : Type+Invalid filename for compiler output "Test.idr"
− test/interactive005/input 
@@ -1,26 +0,0 @@-:consolewidth 80-the Nat (1 + 2)-:exec-:c bytecode hello.bytecode-:c c hello-:doc main-:reload-:consolewidth 80-:load interactive005.idr-:total main-:exec-:consolewidth 80-:t id-:set showimplicits-:t id-:unset showimplicits-:t id-:warranty-:consolewidth 10-:doc main-:consolewidth infinite-:doc main-:let data Nat2 = Zero | Succ Nat2-:t Nat2-:compile Test.idr-:compile a.out
+ test/interactive005/input.in view
@@ -0,0 +1,26 @@+:consolewidth 80+the Nat (1 + 2)+:exec+:c bytecode hello.bytecode+:c c hello+:doc main+:reload+:consolewidth 80+:load interactive005.idr+:total main+:exec+:consolewidth 80+:t id+:set showimplicits+:t id+:unset showimplicits+:t id+:warranty+:consolewidth 10+:doc main+:consolewidth infinite+:doc main+:let data Nat2 = Zero | Succ Nat2+:t Nat2+:compile Test.idr+:compile a.out
− test/interactive005/run 
@@ -1,6 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ --nocolour --quiet --port none interactive005.idr --consolewidth 70 < input-rm -f *.ibc-rm -f hello.bytecode-rm -f hello-rm -f a.out
+ test/interactive005/run.sh view
@@ -0,0 +1,6 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ --nocolour --quiet --port none interactive005.idr --consolewidth 70 < input.in+rm -f *.ibc+rm -f hello.bytecode+rm -f hello+rm -f a.out
− test/interactive006/expected 
@@ -1,1 +0,0 @@-plus ?foo_rhs2 ?foo_rhs3
+ test/interactive006/expected.out view
@@ -0,0 +1,1 @@+plus ?foo_rhs2 ?foo_rhs3
− test/interactive006/input 
@@ -1,1 +0,0 @@-:ref 2 foo_rhs1 plus
+ test/interactive006/input.in view
@@ -0,0 +1,1 @@+:ref 2 foo_rhs1 plus
− test/interactive006/run 
@@ -1,3 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ --quiet --port none --port 5000 interactive006.idr < input-rm -f *.ibc
+ test/interactive006/run.sh view
@@ -0,0 +1,3 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ --quiet --port none --port 5000 interactive006.idr < input.in+rm -f *.ibc
− test/interactive007/expected 
@@ -1,1 +0,0 @@-Idris> *Data/ZZ> *Data/ZZ> *Data/ZZ> *Data/ZZ> Bye bye
+ test/interactive007/expected.out view
@@ -0,0 +1,1 @@+Idris> *Data/ZZ> *Data/ZZ> *Data/ZZ> *Data/ZZ> Bye bye
− test/interactive007/input 
@@ -1,4 +0,0 @@-:module Data.ZZ-:module Data.ZZ-:r-:module Data.ZZ
+ test/interactive007/input.in view
@@ -0,0 +1,4 @@+:module Data.ZZ+:module Data.ZZ+:r+:module Data.ZZ
− test/interactive007/run 
@@ -1,2 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ -p contrib --nobanner --nocolor --port none < input | perl -pe 's-Data\\Z-Data/Z-g'
+ test/interactive007/run.sh view
@@ -0,0 +1,2 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ -p contrib --nobanner --nocolor --port none < input.in | perl -pe 's-Data\\Z-Data/Z-g'
− test/interactive008/expected 
@@ -1,204 +0,0 @@-Idris> Idris> Idris> 1 ::-2 :: 3 :: 4 :: 5 :: ... : List Integer-Idris> Idris> [1,- 2,- 3,- 4,- 5,- 6,- 7,- 8,- 9,- 10,- 11,- 12,- 13,- 14,- 15,- 16,- 17,- 18,- 19,- 20,- 21,- 22,- 23,- 24,- 25,- 26,- 27,- 28,- 29,- 30,- 31,- 32,- 33,- 34,- 35,- 36,- 37,- 38,- 39,- 40,- 41,- 42,- 43,- 44,- 45,- 46,- 47,- 48,- 49,- 50,- 51,- 52,- 53,- 54,- 55,- 56,- 57,- 58,- 59,- 60,- 61,- 62,- 63,- 64,- 65,- 66,- 67,- 68,- 69,- 70,- 71,- 72,- 73,- 74,- 75,- 76,- 77,- 78,- 79,- 80,- 81,- 82,- 83,- 84,- 85,- 86,- 87,- 88,- 89,- 90,- 91,- 92,- 93,- 94,- 95,- 96,- 97,- 98,- 99,- 100] : List Integer-Idris> Idris> ... : ...-Idris> Idris> [1,- 2,- 3,- 4,- 5,- 6,- 7,- 8,- 9,- 10,- 11,- 12,- 13,- 14,- 15,- 16,- 17,- 18,- 19,- 20,- 21,- 22,- 23,- 24,- 25,- 26,- 27,- 28,- 29,- 30,- 31,- 32,- 33,- 34,- 35,- 36,- 37,- 38,- 39,- 40,- 41,- 42,- 43,- 44,- 45,- 46,- 47,- 48,- 49,- 50,- 51,- 52,- 53,- 54,- 55,- 56,- 57,- 58,- 59,- 60,- 61,- 62,- 63,- 64,- 65,- 66,- 67,- 68,- 69,- 70,- 71,- 72,- 73,- 74,- 75,- 76,- 77,- 78,- 79,- 80,- 81,- 82,- 83,- 84,- 85,- 86,- 87,- 88,- 89,- 90,- 91,- 92,- 93,- 94,- 95,- 96,- 97,- 98,- 99,- 100] : List Integer-Idris> Bye bye
+ test/interactive008/expected.out view
@@ -0,0 +1,204 @@+Idris> Idris> Idris> 1 ::+2 :: 3 :: 4 :: 5 :: ... : List Integer+Idris> Idris> [1,+ 2,+ 3,+ 4,+ 5,+ 6,+ 7,+ 8,+ 9,+ 10,+ 11,+ 12,+ 13,+ 14,+ 15,+ 16,+ 17,+ 18,+ 19,+ 20,+ 21,+ 22,+ 23,+ 24,+ 25,+ 26,+ 27,+ 28,+ 29,+ 30,+ 31,+ 32,+ 33,+ 34,+ 35,+ 36,+ 37,+ 38,+ 39,+ 40,+ 41,+ 42,+ 43,+ 44,+ 45,+ 46,+ 47,+ 48,+ 49,+ 50,+ 51,+ 52,+ 53,+ 54,+ 55,+ 56,+ 57,+ 58,+ 59,+ 60,+ 61,+ 62,+ 63,+ 64,+ 65,+ 66,+ 67,+ 68,+ 69,+ 70,+ 71,+ 72,+ 73,+ 74,+ 75,+ 76,+ 77,+ 78,+ 79,+ 80,+ 81,+ 82,+ 83,+ 84,+ 85,+ 86,+ 87,+ 88,+ 89,+ 90,+ 91,+ 92,+ 93,+ 94,+ 95,+ 96,+ 97,+ 98,+ 99,+ 100] : List Integer+Idris> Idris> ... : ...+Idris> Idris> [1,+ 2,+ 3,+ 4,+ 5,+ 6,+ 7,+ 8,+ 9,+ 10,+ 11,+ 12,+ 13,+ 14,+ 15,+ 16,+ 17,+ 18,+ 19,+ 20,+ 21,+ 22,+ 23,+ 24,+ 25,+ 26,+ 27,+ 28,+ 29,+ 30,+ 31,+ 32,+ 33,+ 34,+ 35,+ 36,+ 37,+ 38,+ 39,+ 40,+ 41,+ 42,+ 43,+ 44,+ 45,+ 46,+ 47,+ 48,+ 49,+ 50,+ 51,+ 52,+ 53,+ 54,+ 55,+ 56,+ 57,+ 58,+ 59,+ 60,+ 61,+ 62,+ 63,+ 64,+ 65,+ 66,+ 67,+ 68,+ 69,+ 70,+ 71,+ 72,+ 73,+ 74,+ 75,+ 76,+ 77,+ 78,+ 79,+ 80,+ 81,+ 82,+ 83,+ 84,+ 85,+ 86,+ 87,+ 88,+ 89,+ 90,+ 91,+ 92,+ 93,+ 94,+ 95,+ 96,+ 97,+ 98,+ 99,+ 100] : List Integer+Idris> Bye bye
− test/interactive008/input 
@@ -1,9 +0,0 @@-:consolewidth 50-:printerdepth 5-the (List Integer) [1..20]-:printerdepth 1000-the (List Integer) [1..100]-:printerdepth 0-the (List Integer) [1..100]-:printerdepth-the (List Integer) [1..100]
+ test/interactive008/input.in view
@@ -0,0 +1,9 @@+:consolewidth 50+:printerdepth 5+the (List Integer) [1..20]+:printerdepth 1000+the (List Integer) [1..100]+:printerdepth 0+the (List Integer) [1..100]+:printerdepth+the (List Integer) [1..100]
− test/interactive008/run 
@@ -1,2 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ --nobanner --nocolor --port none < input
+ test/interactive008/run.sh view
@@ -0,0 +1,2 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ --nobanner --nocolor --port none < input.in
− test/interactive009/expected 
@@ -1,1 +0,0 @@-(IsSetCons pf prfRec)
+ test/interactive009/expected.out view
@@ -0,0 +1,1 @@+(IsSetCons pf prfRec)
− test/interactive009/input 
@@ -1,1 +0,0 @@-:ps 26 rec
+ test/interactive009/input.in view
@@ -0,0 +1,1 @@+:ps 26 rec
− test/interactive009/run 
@@ -1,3 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ --quiet --port none interactive009.idr < input-rm -f *.ibc
+ test/interactive009/run.sh view
@@ -0,0 +1,3 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ --quiet --port none interactive009.idr < input.in+rm -f *.ibc
− test/interactive010/expected 
@@ -1,24 +0,0 @@-Prelude.List.(++) : List a -> List a -> List a-Prelude.Strings.(++) : String -> String -> String-(input):1:7-20:a is not an implicit argument of Prelude.Interfaces./-Usage is :doc <functionname>-Usage is :wc <functionname>-Usage is :printdef <functionname>-pat {ty_503} : Type toplevel.u. pat {__interface_504} : Prelude.Interfaces.Fractional {ty_503}. Prelude.Interfaces./ {ty_503} {__interface_504}-- : pty {ty_503} : Type toplevel.u. pty {__interface_504} : Prelude.Interfaces.Fractional {ty_503}. {ty_503} -> {ty_503} -> {ty_503}-(input):1:1:-  |-1 | /-  | ^-unexpected '/'-expecting ':', dependent type signature, or end of input--(input):1:1:-  |-1 | ++-  | ^-unexpected "++"-expecting ':', dependent type signature, or end of input--Can't find implementation for Fractional ty
+ test/interactive010/expected.out view
@@ -0,0 +1,24 @@+Prelude.List.(++) : List a -> List a -> List a+Prelude.Strings.(++) : String -> String -> String+(input):1:7-20:a is not an implicit argument of Prelude.Interfaces./+Usage is :doc <functionname>+Usage is :wc <functionname>+Usage is :printdef <functionname>+pat {ty_503} : Type toplevel.u. pat {__interface_504} : Prelude.Interfaces.Fractional {ty_503}. Prelude.Interfaces./ {ty_503} {__interface_504}++ : pty {ty_503} : Type toplevel.u. pty {__interface_504} : Prelude.Interfaces.Fractional {ty_503}. {ty_503} -> {ty_503} -> {ty_503}+(input):1:1:+  |+1 | /+  | ^+unexpected '/'+expecting ':', dependent type signature, or end of input++(input):1:1:+  |+1 | +++  | ^+unexpected "++"+expecting ':', dependent type signature, or end of input++Can't find implementation for Fractional ty
− test/interactive010/input 
@@ -1,9 +0,0 @@-:type ++-:core (/) {a=Double}-:doc +-:wc +-:printdef --:patt /-/-++-:whnf /
+ test/interactive010/input.in view
@@ -0,0 +1,9 @@+:type +++:core (/) {a=Double}+:doc ++:wc ++:printdef -+:patt /+/++++:whnf /
− test/interactive010/run 
@@ -1,2 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ --quiet --port none --nobanner --nocolor  < input
+ test/interactive010/run.sh view
@@ -0,0 +1,2 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ --quiet --port none --nobanner --nocolor  < input.in
− test/interactive011/.gitignore 
@@ -1,1 +0,0 @@-interactive011
− test/interactive011/expected 
@@ -1,3 +0,0 @@-    show x = ?Show_rhs_1-    showPrec d x = ?Show_rhs_2-append [] _ = ?append_rhs_1
+ test/interactive011/expected.out view
@@ -0,0 +1,3 @@+    show x = ?Show_rhs_1+    showPrec d x = ?Show_rhs_2+append [] _ = ?append_rhs_1
− test/interactive011/input 
@@ -1,2 +0,0 @@-:addclause 8 Show-:addclause 10 append
+ test/interactive011/input.in view
@@ -0,0 +1,2 @@+:addclause 8 Show+:addclause 10 append
− test/interactive011/run 
@@ -1,6 +0,0 @@-#!/usr/bin/env bash--cd src-${IDRIS:-idris} "$@" --quiet --port none --indent-clause 4 Main.idr <../input--rm -f *.ibc
+ test/interactive011/run.sh view
@@ -0,0 +1,6 @@+#!/usr/bin/env bash++cd src+${IDRIS:-idris} "$@" --quiet --port none --indent-clause 4 Main.idr <../input.in++rm -f *.ibc
− test/interactive012/expected 
@@ -1,33 +0,0 @@-  x : Int----------------------------------------mkString_rhs_1 : String-  x : String----------------------------------------mkString_rhs_2 : String----------------------------------------mkThing_rhs_1 : Int----------------------------------------mkThing_rhs_2 : String-  str : Bool-  x : IntString str----------------------------------------mkString2_rhs : String-  x : ?what----------------------------------------mkString3_rhs_1 : String-  x : ?what----------------------------------------mkString3_rhs_2 : String-  a : Type-  m : Nat-  ys : Vect m a----------------------------------------append_rhs_1 : Vect m a-  a : Type-  x : a-  m : Nat-  ys : Vect m a-  k : Nat-  xs : Vect k a----------------------------------------append_rhs_2 : Vect (S (plus k m)) a
+ test/interactive012/expected.out view
@@ -0,0 +1,33 @@+  x : Int+--------------------------------------+mkString_rhs_1 : String+  x : String+--------------------------------------+mkString_rhs_2 : String+--------------------------------------+mkThing_rhs_1 : Int+--------------------------------------+mkThing_rhs_2 : String+  str : Bool+  x : IntString str+--------------------------------------+mkString2_rhs : String+  x : ?what+--------------------------------------+mkString3_rhs_1 : String+  x : ?what+--------------------------------------+mkString3_rhs_2 : String+  a : Type+  m : Nat+  ys : Vect m a+--------------------------------------+append_rhs_1 : Vect m a+  a : Type+  x : a+  m : Nat+  ys : Vect m a+  k : Nat+  xs : Vect k a+--------------------------------------+append_rhs_2 : Vect (S (plus k m)) a
− test/interactive012/input 
@@ -1,9 +0,0 @@-:t mkString_rhs_1-:t mkString_rhs_2-:t mkThing_rhs_1-:t mkThing_rhs_2-:t mkString2_rhs-:t mkString3_rhs_1-:t mkString3_rhs_2-:t append_rhs_1-:t append_rhs_2
+ test/interactive012/input.in view
@@ -0,0 +1,9 @@+:t mkString_rhs_1+:t mkString_rhs_2+:t mkThing_rhs_1+:t mkThing_rhs_2+:t mkString2_rhs+:t mkString3_rhs_1+:t mkString3_rhs_2+:t append_rhs_1+:t append_rhs_2
− test/interactive012/run 
@@ -1,3 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ --nocolour --consolewidth 70 --quiet --port none interactive012.idr < input-rm -f *.ibc
+ test/interactive012/run.sh view
@@ -0,0 +1,3 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ --nocolour --consolewidth 70 --quiet --port none interactive012.idr < input.in+rm -f *.ibc
− test/interactive013/expected 
@@ -1,4 +0,0 @@-gcd aa (aa + (S y)) (CmpLT y) = ?gcd_rhs_1-gcd bb bb CmpEQ = ?gcd_rhs_2-gcd (bb + (S x)) bb (CmpGT x) = ?gcd_rhs_3-
+ test/interactive013/expected.out view
@@ -0,0 +1,4 @@+gcd aa (aa + (S y)) (CmpLT y) = ?gcd_rhs_1+gcd bb bb CmpEQ = ?gcd_rhs_2+gcd (bb + (S x)) bb (CmpGT x) = ?gcd_rhs_3+
− test/interactive013/input 
@@ -1,1 +0,0 @@-:cs 3 cc
+ test/interactive013/input.in view
@@ -0,0 +1,1 @@+:cs 3 cc
− test/interactive013/run 
@@ -1,3 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ --quiet --port none interactive013.idr < input-rm -f *.ibc
+ test/interactive013/run.sh view
@@ -0,0 +1,3 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ --quiet --port none interactive013.idr < input.in+rm -f *.ibc
− test/interactive014/expected 
@@ -1,7 +0,0 @@-aa-bb-123-cc-"dd"-456-"xyz"
+ test/interactive014/expected.out view
@@ -0,0 +1,7 @@+aa+bb+123+cc+"dd"+456+"xyz"
− test/interactive014/input 
@@ -1,5 +0,0 @@-:exec voidIO-:exec intIO-:exec stringIO-:exec 456-:exec "xyz"
+ test/interactive014/input.in view
@@ -0,0 +1,5 @@+:exec voidIO+:exec intIO+:exec stringIO+:exec 456+:exec "xyz"
− test/interactive014/run 
@@ -1,3 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ --quiet --port none interactive014.idr < input-rm -f *.ibc
+ test/interactive014/run.sh view
@@ -0,0 +1,3 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ --quiet --port none interactive014.idr < input.in+rm -f *.ibc
− test/interactive015/expected 
@@ -1,6 +0,0 @@-test (Just x) = ?Nothing_rhs_1--test : Maybe a -> Bool-test Nothing = False-test (Just x) = ?Nothing_rhs_1-
+ test/interactive015/expected.out view
@@ -0,0 +1,6 @@+test (Just x) = ?Nothing_rhs_1++test : Maybe a -> Bool+test Nothing = False+test (Just x) = ?Nothing_rhs_1+
− test/interactive015/input 
@@ -1,2 +0,0 @@-:addmissing  3 Nothing-:addmissing! 3 Nothing
+ test/interactive015/input.in view
@@ -0,0 +1,2 @@+:addmissing  3 Nothing+:addmissing! 3 Nothing
− test/interactive015/run 
@@ -1,8 +0,0 @@-#!/usr/bin/env bash--cp src/interactive015.idr .-${IDRIS:-idris} "$@" --quiet --port none interactive015.idr < input--cat interactive015.idr--rm -f *.ibc interactive015.idr
+ test/interactive015/run.sh view
@@ -0,0 +1,8 @@+#!/usr/bin/env bash++cp src/interactive015.idr .+${IDRIS:-idris} "$@" --quiet --port none interactive015.idr < input.in++cat interactive015.idr++rm -f *.ibc interactive015.idr
− test/interactive016/expected 
@@ -1,7 +0,0 @@--test : Maybe a -> Bool-test Nothing = False-test (Just x)  = True--other : Int-other = 3
+ test/interactive016/expected.out view
@@ -0,0 +1,7 @@++test : Maybe a -> Bool+test Nothing = False+test (Just x)  = True++other : Int+other = 3
− test/interactive016/input 
@@ -1,2 +0,0 @@-:addmissing  3 Nothing-:addmissing! 3 Nothing
+ test/interactive016/input.in view
@@ -0,0 +1,2 @@+:addmissing  3 Nothing+:addmissing! 3 Nothing
− test/interactive016/run 
@@ -1,8 +0,0 @@-#!/usr/bin/env bash--cp src/interactive016.idr .-${IDRIS:-idris} "$@" --quiet --port none interactive016.idr < input--cat interactive016.idr--rm -f *.ibc interactive016.idr
+ test/interactive016/run.sh view
@@ -0,0 +1,8 @@+#!/usr/bin/env bash++cp src/interactive016.idr .+${IDRIS:-idris} "$@" --quiet --port none interactive016.idr < input.in++cat interactive016.idr++rm -f *.ibc interactive016.idr
− test/interactive017/expected 
@@ -1,7 +0,0 @@-hello from C-hello from C-hello from node-hello from node-Hello ["aaa"]-Hello ["bbb", "aaa"]-Hello from a module
+ test/interactive017/expected.out view
@@ -0,0 +1,7 @@+hello from C+hello from C+hello from node+hello from node+Hello ["aaa"]+Hello ["bbb", "aaa"]+Hello from a module
− test/interactive017/run 
@@ -1,9 +0,0 @@-#!/bin/sh-PATH="../../scripts:$PATH"-./shebang.idr-./shebang.idr-./shebang-node.idr-./shebang-node.idr-./shebang-args.idr aaa-./shebang-args.idr bbb aaa-./shebang-import.idr
+ test/interactive017/run.sh view
@@ -0,0 +1,9 @@+#!/bin/sh+PATH="../../scripts:$PATH"+./shebang.idr+./shebang.idr+./shebang-node.idr+./shebang-node.idr+./shebang-args.idr aaa+./shebang-args.idr bbb aaa+./shebang-import.idr
− test/interactive018/expected 
@@ -1,20 +0,0 @@-1 : Integer-top_private : a -> a-1 : Integer-top_visible : a -> a-No such variable imported1_private-No such variable imported1_private-1 : Integer-imported1_visible : a -> a-No such variable imported2_private-No such variable imported2_private-No such variable imported2_visible-No such variable imported2_visible-No such variable public1_private-No such variable public1_private-1 : Integer-public1_visible : a -> a-No such variable public2_private-No such variable public2_private-1 : Integer-public2_visible : a -> a
+ test/interactive018/expected.out view
@@ -0,0 +1,20 @@+1 : Integer+top_private : a -> a+1 : Integer+top_visible : a -> a+No such variable imported1_private+No such variable imported1_private+1 : Integer+imported1_visible : a -> a+No such variable imported2_private+No such variable imported2_private+No such variable imported2_visible+No such variable imported2_visible+No such variable public1_private+No such variable public1_private+1 : Integer+public1_visible : a -> a+No such variable public2_private+No such variable public2_private+1 : Integer+public2_visible : a -> a
− test/interactive018/input 
@@ -1,20 +0,0 @@-top_private 1-:t top_private-top_visible 1-:t top_visible-imported1_private 1-:t imported1_private-imported1_visible 1-:t imported1_visible-imported2_private 1-:t imported2_private-imported2_visible 1-:t imported2_visible-public1_private 1-:t public1_private-public1_visible 1-:t public1_visible-public2_private 1-:t public2_private-public2_visible 1-:t public2_visible
+ test/interactive018/input.in view
@@ -0,0 +1,20 @@+top_private 1+:t top_private+top_visible 1+:t top_visible+imported1_private 1+:t imported1_private+imported1_visible 1+:t imported1_visible+imported2_private 1+:t imported2_private+imported2_visible 1+:t imported2_visible+public1_private 1+:t public1_private+public1_visible 1+:t public1_visible+public2_private 1+:t public2_private+public2_visible 1+:t public2_visible
− test/interactive018/run 
@@ -1,3 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ --quiet --port none Top.idr < input-rm -f *.ibc
+ test/interactive018/run.sh view
@@ -0,0 +1,3 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ --quiet --port none Top.idr < input.in+rm -f *.ibc
− test/interfaces001/expected 
@@ -1,30 +0,0 @@-Interface MyShow-    A fancy shower with a constructor--Parameters:-    a   -- the thing to be shown--Methods:-    myShow : MyShow a => (x : a) -> String-        The shower-        -        The function is: Total & public export-Implementation constructor:-    MkMyShow : (myShow : a -> String) -> MyShow a-        Build a MyShow-        Arguments:-            (implicit) a : Type  -- the thing to be shown-            -            myShow : a -> String  -- The shower-            -        The function is: public export-Implementations:-    MyShow Integer-MkMyShow : (myShow : a -> String) -> MyShow a-    Build a MyShow-    Arguments:-        (implicit) a : Type  -- the thing to be shown-        -        myShow : a -> String  -- The shower-        -    The function is: Total & public export
+ test/interfaces001/expected.out view
@@ -0,0 +1,30 @@+Interface MyShow+    A fancy shower with a constructor++Parameters:+    a   -- the thing to be shown++Methods:+    myShow : MyShow a => (x : a) -> String+        The shower+        +        The function is: Total & public export+Implementation constructor:+    MkMyShow : (myShow : a -> String) -> MyShow a+        Build a MyShow+        Arguments:+            (implicit) a : Type  -- the thing to be shown+            +            myShow : a -> String  -- The shower+            +        The function is: public export+Implementations:+    MyShow Integer+MkMyShow : (myShow : a -> String) -> MyShow a+    Build a MyShow+    Arguments:+        (implicit) a : Type  -- the thing to be shown+        +        myShow : a -> String  -- The shower+        +    The function is: Total & public export
− test/interfaces001/input 
@@ -1,2 +0,0 @@-:doc MyShow-:doc MkMyShow
+ test/interfaces001/input.in view
@@ -0,0 +1,2 @@+:doc MyShow+:doc MkMyShow
− test/interfaces001/run 
@@ -1,3 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ --quiet --port none --nocolour --consolewidth 70 InterfaceName.idr < input-rm -f *.ibc
+ test/interfaces001/run.sh view
@@ -0,0 +1,3 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ --quiet --port none --nocolour --consolewidth 70 InterfaceName.idr < input.in+rm -f *.ibc
− test/interfaces002/expected 
@@ -1,1 +0,0 @@-41
+ test/interfaces002/expected.out view
@@ -0,0 +1,1 @@+41
− test/interfaces002/run 
@@ -1,4 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ --nocolour --consolewidth 70 interfaces002.idr -o interfaces002-./interfaces002-rm -f interfaces002 *.ibc
+ test/interfaces002/run.sh view
@@ -0,0 +1,4 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ --nocolour --consolewidth 70 interfaces002.idr -o interfaces002+./interfaces002+rm -f interfaces002 *.ibc
− test/interfaces003/expected 
@@ -1,2 +0,0 @@-10-9
+ test/interfaces003/expected.out view
@@ -0,0 +1,2 @@+10+9
− test/interfaces003/run 
@@ -1,4 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ --nocolour --consolewidth 70 interfaces003.idr -o interfaces003-./interfaces003-rm -f interfaces003 *.ibc
+ test/interfaces003/run.sh view
@@ -0,0 +1,4 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ --nocolour --consolewidth 70 interfaces003.idr -o interfaces003+./interfaces003+rm -f interfaces003 *.ibc
− test/interfaces004/expected 
@@ -1,4 +0,0 @@-12-36-True-False
+ test/interfaces004/expected.out view
@@ -0,0 +1,4 @@+12+36+True+False
− test/interfaces004/run 
@@ -1,4 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ --nocolour --consolewidth 70 interfaces004.idr -o interfaces004-./interfaces004-rm -f interfaces004 *.ibc
+ test/interfaces004/run.sh view
@@ -0,0 +1,4 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ --nocolour --consolewidth 70 interfaces004.idr -o interfaces004+./interfaces004+rm -f interfaces004 *.ibc
− test/interfaces005/expected 
@@ -1,7 +0,0 @@-interfaces005a.idr:18:3:-Set.TreeSet.Set must be defined by a type or data constructor-No such variable TreeSet-interfaces005b.idr:4:11:-Data definitions not allowed in an interface declaration-interfaces005b.idr:18:3:SetSig is not an interface-No such variable TreeSet
+ test/interfaces005/expected.out view
@@ -0,0 +1,7 @@+interfaces005a.idr:18:3:+Set.TreeSet.Set must be defined by a type or data constructor+No such variable TreeSet+interfaces005b.idr:4:11:+Data definitions not allowed in an interface declaration+interfaces005b.idr:18:3:SetSig is not an interface+No such variable TreeSet
− test/interfaces005/run 
@@ -1,5 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ --nocolour --consolewidth 70 interfaces005.idr --check-${IDRIS:-idris} $@ --nocolour --consolewidth 70 interfaces005a.idr --check-${IDRIS:-idris} $@ --nocolour --consolewidth 70 interfaces005b.idr --check-rm -rf *.ibc
+ test/interfaces005/run.sh view
@@ -0,0 +1,5 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ --nocolour --consolewidth 70 interfaces005.idr --check+${IDRIS:-idris} $@ --nocolour --consolewidth 70 interfaces005a.idr --check+${IDRIS:-idris} $@ --nocolour --consolewidth 70 interfaces005b.idr --check+rm -rf *.ibc
− test/interfaces006/expected 
+ test/interfaces006/expected.out view
− test/interfaces006/run 
@@ -1,3 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ --nocolour --consolewidth 70 interfaces006.idr --noprelude --check-rm -rf *.ibc
+ test/interfaces006/run.sh view
@@ -0,0 +1,3 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ --nocolour --consolewidth 70 interfaces006.idr --noprelude --check+rm -rf *.ibc
− test/interfaces007/expected 
@@ -1,1 +0,0 @@-(2, 6)
+ test/interfaces007/expected.out view
@@ -0,0 +1,1 @@+(2, 6)
− test/interfaces007/run 
@@ -1,4 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ interfaces007.idr -o interfaces007-./interfaces007-rm -f interfaces007 *.ibc
+ test/interfaces007/run.sh view
@@ -0,0 +1,4 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ interfaces007.idr -o interfaces007+./interfaces007+rm -f interfaces007 *.ibc
− test/interfaces008/expected 
@@ -1,6 +0,0 @@-interfaces008.idr:20:18-23:-   |-20 |   implementation Foo2 a where-   |                  ~~~~~~-Default implementations must be for a super interface constraint on the containing interface.-
+ test/interfaces008/expected.out view
@@ -0,0 +1,6 @@+interfaces008.idr:20:18-23:+   |+20 |   implementation Foo2 a where+   |                  ~~~~~~+Default implementations must be for a super interface constraint on the containing interface.+
− test/interfaces008/run 
@@ -1,3 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ --nocolour --consolewidth 70 interfaces008.idr --noprelude --check-rm -f interfaces008 *.ibc
+ test/interfaces008/run.sh view
@@ -0,0 +1,3 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ --nocolour --consolewidth 70 interfaces008.idr --noprelude --check+rm -f interfaces008 *.ibc
− test/interfaces009/expected 
+ test/interfaces009/expected.out view
− test/interfaces009/run 
@@ -1,3 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ --nocolour --consolewidth 70 interfaces009.idr --noprelude --check-rm -f interfaces009 *.ibc
+ test/interfaces009/run.sh view
@@ -0,0 +1,3 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ --nocolour --consolewidth 70 interfaces009.idr --noprelude --check+rm -f interfaces009 *.ibc
− test/interfaces010/expected 
+ test/interfaces010/expected.out view
− test/interfaces010/run 
@@ -1,3 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ --nocolour --consolewidth 70 interfaces010.idr --check-rm -f interfaces010 *.ibc
+ test/interfaces010/run.sh view
@@ -0,0 +1,3 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ --nocolour --consolewidth 70 interfaces010.idr --check+rm -f interfaces010 *.ibc
− test/interpret001/expected 
@@ -1,2 +0,0 @@-testtest-MkIO (\w => prim_io_pure ()) : IO' (MkFFI C_Types String String) ()
+ test/interpret001/expected.out view
@@ -0,0 +1,2 @@+testtest+MkIO (\w => prim_io_pure ()) : IO' (MkFFI C_Types String String) ()
− test/interpret001/input 
@@ -1,2 +0,0 @@-:x main-test
+ test/interpret001/input.in view
@@ -0,0 +1,2 @@+:x main+test
− test/interpret001/run 
@@ -1,3 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ --quiet --port none --nocolour double-echo.idr < input-rm -f *.ibc
+ test/interpret001/run.sh view
@@ -0,0 +1,3 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ --quiet --port none --nocolour double-echo.idr < input.in+rm -f *.ibc
− test/interpret002/expected 
@@ -1,4 +0,0 @@-File Not Found-MkIO (\w => prim_io_pure ()) : IO' (MkFFI C_Types String String) ()-"readable"-MkIO (\w => prim_io_pure ()) : IO' (MkFFI C_Types String String) ()
+ test/interpret002/expected.out view
@@ -0,0 +1,4 @@+File Not Found+MkIO (\w => prim_io_pure ()) : IO' (MkFFI C_Types String String) ()+"readable"+MkIO (\w => prim_io_pure ()) : IO' (MkFFI C_Types String String) ()
− test/interpret002/input 
@@ -1,2 +0,0 @@-:x echo "not a file"-:x echo "readable.txt"
+ test/interpret002/input.in view
@@ -0,0 +1,2 @@+:x echo "not a file"+:x echo "readable.txt"
− test/interpret002/run 
@@ -1,3 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ --quiet --port none --nocolour file-error.idr < input-rm -f *.ibc
+ test/interpret002/run.sh view
@@ -0,0 +1,3 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ --quiet --port none --nocolour file-error.idr < input.in+rm -f *.ibc
− test/interpret003/expected 
@@ -1,1 +0,0 @@-Compiled program terminated with exit code 1
+ test/interpret003/expected.out view
@@ -0,0 +1,1 @@+Compiled program terminated with exit code 1
− test/interpret003/input 
@@ -1,1 +0,0 @@-:exec
+ test/interpret003/input.in view
@@ -0,0 +1,1 @@+:exec
− test/interpret003/run 
@@ -1,3 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ --quiet --port none --nocolour interpret003.idr < input-rm -f *.ibc
+ test/interpret003/run.sh view
@@ -0,0 +1,3 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ --quiet --port none --nocolour interpret003.idr < input.in+rm -f *.ibc
− test/interpret003/test 
binary file changed (128344 → absent bytes)
− test/io001/expected 
@@ -1,16 +0,0 @@-Reading testfile-Hello!-World!-...-3-4-Last line------Hello!-World!-...-3-4-Last line----
+ test/io001/expected.out view
@@ -0,0 +1,16 @@+Reading testfile+Hello!+World!+...+3+4+Last line++---+Hello!+World!+...+3+4+Last line+---
− test/io001/run 
@@ -1,4 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ test004.idr -o test004-./test004-rm -f test004 test004.ibc testfile
+ test/io001/run.sh view
@@ -0,0 +1,4 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ test004.idr -o test004+./test004+rm -f test004 test004.ibc testfile
− test/io002/expected 
@@ -1,3 +0,0 @@-First and second? 2-1-2
+ test/io002/expected.out view
@@ -0,0 +1,3 @@+First and second? 2+1+2
− test/io002/run 
@@ -1,4 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ test008.idr -o test008-./test008-rm -f test008 test008.ibc
+ test/io002/run.sh view
@@ -0,0 +1,4 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ test008.idr -o test008+./test008+rm -f test008 test008.ibc
− test/io003/expected 
@@ -1,15 +0,0 @@-Sending-Hello!-Received-Hello to you too!-Finished-Sending-Hello!-Received-Hello to you too!-Finished-Sending-Hello!-Received-Hello to you too!-Finished
+ test/io003/expected.out view
@@ -0,0 +1,15 @@+Sending+Hello!+Received+Hello to you too!+Finished+Sending+Hello!+Received+Hello to you too!+Finished+Sending+Hello!+Received+Hello to you too!+Finished
− test/io003/run 
@@ -1,6 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ test018.idr -p contrib -o test018-${IDRIS:-idris} $@ test018a.idr -p contrib -o test018a-./test018-#./test018a-rm -f test018 test018a *.ibc
+ test/io003/run.sh view
@@ -0,0 +1,6 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ test018.idr -p contrib -o test018+${IDRIS:-idris} $@ test018a.idr -p contrib -o test018a+./test018+#./test018a+rm -f test018 test018a *.ibc
− test/layout001/expected 
@@ -1,82 +0,0 @@-layout001a.idr:5:1:-  |-5 | y-  | ^-Wrong indention: should be greater than context indentation--layout001b.idr:5:3:-  |-5 | = y-  |   ^-Wrong indention: should be greater than context indentation--layout001c.idr:3:1:-  |-3 | 2-  | ^-Wrong indention: should be greater than context indentation--layout001e.idr:6:1:-  |-6 | 3-  | ^-Wrong indention: should be greater than context indentation--layout001f.idr:6:2:-  |-6 |  3-  |  ^-Wrong indention: should be greater than context indentation--layout001g.idr:6:3:-  |-6 |   3-  |   ^-Wrong indention: should be greater than context indentation--layout001h.idr:6:3:-  |-6 |   3-  |   ^-Wrong indention: should be greater than context indentation--layout001i.idr:6:4:-  |-6 |    3-  |    ^-Wrong indention: should be greater than context indentation--layout001j.idr:6:5:-  |-6 |     3-  |     ^-Wrong indention: should be greater than context indentation--layout001l.idr:6:1:-  |-6 | y-  | ^-Wrong indention: should be greater than context indentation--mplus1.idr:13:34-17:49:-   |-13 | term                          =  do f <- factor-   |                                  ~~~~~~~~~~~~~~ ...-When checking right hand side of term with expected type-        Maybe Int--When checking an application of function Prelude.Applicative.pure:-        No such variable f--mplus2.idr:17:37:-   |-17 |                                     `mplus` pure f-   |                                     ^-not end of block--mplus3.idr:11:1-16:-   |-11 | term = ?term_rhs-   | ~~~~~~~~~~~~~~~~-Unreachable case: term-
+ test/layout001/expected.out view
@@ -0,0 +1,82 @@+layout001a.idr:5:1:+  |+5 | y+  | ^+Wrong indention: should be greater than context indentation++layout001b.idr:5:3:+  |+5 | = y+  |   ^+Wrong indention: should be greater than context indentation++layout001c.idr:3:1:+  |+3 | 2+  | ^+Wrong indention: should be greater than context indentation++layout001e.idr:6:1:+  |+6 | 3+  | ^+Wrong indention: should be greater than context indentation++layout001f.idr:6:2:+  |+6 |  3+  |  ^+Wrong indention: should be greater than context indentation++layout001g.idr:6:3:+  |+6 |   3+  |   ^+Wrong indention: should be greater than context indentation++layout001h.idr:6:3:+  |+6 |   3+  |   ^+Wrong indention: should be greater than context indentation++layout001i.idr:6:4:+  |+6 |    3+  |    ^+Wrong indention: should be greater than context indentation++layout001j.idr:6:5:+  |+6 |     3+  |     ^+Wrong indention: should be greater than context indentation++layout001l.idr:6:1:+  |+6 | y+  | ^+Wrong indention: should be greater than context indentation++mplus1.idr:13:34-17:49:+   |+13 | term                          =  do f <- factor+   |                                  ~~~~~~~~~~~~~~ ...+When checking right hand side of term with expected type+        Maybe Int++When checking an application of function Prelude.Applicative.pure:+        No such variable f++mplus2.idr:17:37:+   |+17 |                                     `mplus` pure f+   |                                     ^+not end of block++mplus3.idr:11:1-16:+   |+11 | term = ?term_rhs+   | ~~~~~~~~~~~~~~~~+Unreachable case: term+
− test/layout001/run 
@@ -1,22 +0,0 @@-#!/usr/bin/env bash--${IDRIS:-idris} --nobanner --nocolour --quiet --port none <<!-:load layout001a.idr-:load layout001b.idr-:load layout001c.idr-:load layout001d.idr-:load layout001e.idr-:load layout001f.idr-:load layout001g.idr-:load layout001h.idr-:load layout001i.idr-:load layout001j.idr-:load layout001k.idr-:load layout001l.idr-:load layout001n.idr-:load mplus1.idr-:load mplus2.idr-:load mplus3.idr-!--rm -f *.ibc
+ test/layout001/run.sh view
@@ -0,0 +1,22 @@+#!/usr/bin/env bash++${IDRIS:-idris} --nobanner --nocolour --quiet --port none <<!+:load layout001a.idr+:load layout001b.idr+:load layout001c.idr+:load layout001d.idr+:load layout001e.idr+:load layout001f.idr+:load layout001g.idr+:load layout001h.idr+:load layout001i.idr+:load layout001j.idr+:load layout001k.idr+:load layout001l.idr+:load layout001n.idr+:load mplus1.idr+:load mplus2.idr+:load mplus3.idr+!++rm -f *.ibc
− test/literate001/expected 
@@ -1,12 +0,0 @@-./test003a.lidr:1:0:-  |-1 | Broken-  |^-Program line next to comment--'a'-'d'-zabcdefg-gfedcba-['g', 'f', 'e', 'd', 'c', 'b', 'a']-abcdefg
+ test/literate001/expected.out view
@@ -0,0 +1,12 @@+./test003a.lidr:1:0:+  |+1 | Broken+  |^+Program line next to comment++'a'+'d'+zabcdefg+gfedcba+['g', 'f', 'e', 'd', 'c', 'b', 'a']+abcdefg
− test/literate001/run 
@@ -1,5 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ test003a.lidr --check-${IDRIS:-idris} $@ test003.lidr -o test003-./test003-rm -f test003 test003.ibc Lit.ibc
+ test/literate001/run.sh view
@@ -0,0 +1,5 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ test003a.lidr --check+${IDRIS:-idris} $@ test003.lidr -o test003+./test003+rm -f test003 test003.ibc Lit.ibc
− test/meta001/expected 
+ test/meta001/expected.out view
− test/meta001/run 
@@ -1,3 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ --check --nocolour --consolewidth 70 Finite.idr-rm -f *.ibc
+ test/meta001/run.sh view
@@ -0,0 +1,3 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ --check --nocolour --consolewidth 70 Finite.idr+rm -f *.ibc
− test/meta002/expected 
@@ -1,25 +0,0 @@-DataDef.idr:74:1-8:-   |-74 | %runElab nope-   | ~~~~~~~~-While running an elaboration script, the following error occurred:-Prelude.Either.Either is already defined as a datatype.--Tacs.idr:299:17-300:78:-    |-299 |     testElab3 = %runElab (elaborateSTLC (App (Lam "x" (App (Var 0) (Var 0)))-    |                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ...-When checking right hand side of testElab3 with expected type-        DPair Ty (Tm [])--Unifying ty and ARR ty t would lead to infinite value--AgdaStyleReflection.idr:315:7-20:-    |-315 | baz = tactic trivial-    |       ~~~~~~~~~~~~~~-When checking right hand side of baz with expected type-        (Nat, Void)--PROOF SEARCH FAILURE is not defined.-
+ test/meta002/expected.out view
@@ -0,0 +1,25 @@+DataDef.idr:74:1-8:+   |+74 | %runElab nope+   | ~~~~~~~~+While running an elaboration script, the following error occurred:+Prelude.Either.Either is already defined as a datatype.++Tacs.idr:299:17-300:78:+    |+299 |     testElab3 = %runElab (elaborateSTLC (App (Lam "x" (App (Var 0) (Var 0)))+    |                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ...+When checking right hand side of testElab3 with expected type+        DPair Ty (Tm [])++Unifying ty and ARR ty t would lead to infinite value++AgdaStyleReflection.idr:315:7-20:+    |+315 | baz = tactic trivial+    |       ~~~~~~~~~~~~~~+When checking right hand side of baz with expected type+        (Nat, Void)++PROOF SEARCH FAILURE is not defined.+
− test/meta002/run 
@@ -1,7 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ -p pruviloj --nocolour --check --consolewidth 70 DataDef.idr-${IDRIS:-idris} $@ -p pruviloj --nocolour --check --consolewidth 70 Tacs.idr-${IDRIS:-idris} $@ -p pruviloj --nocolour --check --consolewidth 70 AgdaStyleReflection.idr-# Disabled due to excess memory consumption-# ${IDRIS:-idris} $@ -p pruviloj --nocolour --check --consolewidth 70 Deriving.idr-rm -f *.ibc
+ test/meta002/run.sh view
@@ -0,0 +1,7 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ -p pruviloj --nocolour --check --consolewidth 70 DataDef.idr+${IDRIS:-idris} $@ -p pruviloj --nocolour --check --consolewidth 70 Tacs.idr+${IDRIS:-idris} $@ -p pruviloj --nocolour --check --consolewidth 70 AgdaStyleReflection.idr+# Disabled due to excess memory consumption+# ${IDRIS:-idris} $@ -p pruviloj --nocolour --check --consolewidth 70 Deriving.idr+rm -f *.ibc
− test/meta003/expected 
@@ -1,12 +0,0 @@-BadDef.idr:14:1-8:-   |-14 | %runElab mkBadDef1-   | ~~~~~~~~-While running an elaboration script, the following error occurred:-Type mismatch between-        ()-and-        String--message error-unification error
+ test/meta003/expected.out view
@@ -0,0 +1,12 @@+BadDef.idr:14:1-8:+   |+14 | %runElab mkBadDef1+   | ~~~~~~~~+While running an elaboration script, the following error occurred:+Type mismatch between+        ()+and+        String++message error+unification error
− test/meta003/run 
@@ -1,5 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ --nocolour --check --consolewidth 70 BadDef.idr-${IDRIS:-idris} $@ --nocolour --consolewidth 70 -o meta003 Catch.idr-./meta003-rm -f meta003 *.ibc
+ test/meta003/run.sh view
@@ -0,0 +1,5 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ --nocolour --check --consolewidth 70 BadDef.idr+${IDRIS:-idris} $@ --nocolour --consolewidth 70 -o meta003 Catch.idr+./meta003+rm -f meta003 *.ibc
− test/meta004/expected 
@@ -1,7 +0,0 @@-meta004.idr:50:1-8:-   |-50 | %runElab domore-   | ~~~~~~~~-While running an elaboration script, the following error occurred:-Not an impossible case-
+ test/meta004/expected.out view
@@ -0,0 +1,7 @@+meta004.idr:50:1-8:+   |+50 | %runElab domore+   | ~~~~~~~~+While running an elaboration script, the following error occurred:+Not an impossible case+
− test/meta004/run 
@@ -1,3 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ -p pruviloj --nocolour --check --consolewidth 70 meta004.idr-rm -f *.ibc
+ test/meta004/run.sh view
@@ -0,0 +1,3 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ -p pruviloj --nocolour --check --consolewidth 70 meta004.idr+rm -f *.ibc
− test/mktest.pl 
@@ -1,21 +0,0 @@-#!/usr/bin/env perl--if ($#ARGV>=0) {-    $test=shift(@ARGV);-} else {-    print "What's its name?\n";-    exit;-}--mkdir($test);--chdir($test);-open(FOO,">run");--print FOO "#!/usr/bin/env bash\n";-print FOO "\${IDRIS:-idris} \$@ $test.idr -o $test\n";-print FOO "./$test\n";print FOO "rm -f $test *.ibc\n";--close(FOO);--system("chmod +x run");
− test/pkg001/expected 
@@ -1,23 +0,0 @@-Not all command line options can be used to override package options.--The only changeable options are:-	--log <lvl>, --total, --warnpartial, --warnreach, --warnipkg-	--ibcsubdir <path>, -i --idrispath <path>-	--logging-categories <cats>-	--highlight--The options need removing are:-	 Quiet ----Elaborating {__Infer_0}-builtin-Elaborating =-builtin-Elaborating type decl Main.main[]-Elaborating clause Main.main-Rechecking for positivity []-The presented iPKG file does not have a '.ipkg' extension: "malformed-package-name"-The presented iPKG file does not exist: "non-existent-package.ipkg"-The presented iPKG file does not have a '.ipkg' extension: "non-existent-package-with-malformed-name"
+ test/pkg001/expected.out view
@@ -0,0 +1,23 @@+Not all command line options can be used to override package options.++The only changeable options are:+	--log <lvl>, --total, --warnpartial, --warnreach, --warnipkg+	--ibcsubdir <path>, -i --idrispath <path>+	--logging-categories <cats>+	--highlight++The options need removing are:+	 Quiet ++++Elaborating {__Infer_0}+builtin+Elaborating =+builtin+Elaborating type decl Main.main[]+Elaborating clause Main.main+Rechecking for positivity []+The presented iPKG file does not have a '.ipkg' extension: "malformed-package-name"+The presented iPKG file does not exist: "non-existent-package.ipkg"+The presented iPKG file does not have a '.ipkg' extension: "non-existent-package-with-malformed-name"
− test/pkg001/run 
@@ -1,8 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ --build test-pkg.ipkg-rm -f  *.ibc-${IDRIS:-idris} $@ --build test-pkg.ipkg --quiet-${IDRIS:-idris} $@ --build test-pkg.ipkg --logging-categories "elab" --log 1-${IDRIS:-idris} $@ --build malformed-package-name-${IDRIS:-idris} $@ --build non-existent-package.ipkg-${IDRIS:-idris} $@ --build non-existent-package-with-malformed-name
+ test/pkg001/run.sh view
@@ -0,0 +1,8 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ --build test-pkg.ipkg+rm -f  *.ibc+${IDRIS:-idris} $@ --build test-pkg.ipkg --quiet+${IDRIS:-idris} $@ --build test-pkg.ipkg --logging-categories "elab" --log 1+${IDRIS:-idris} $@ --build malformed-package-name+${IDRIS:-idris} $@ --build non-existent-package.ipkg+${IDRIS:-idris} $@ --build non-existent-package-with-malformed-name
test/pkg001/test-pkg.ipkg view
@@ -12,6 +12,6 @@ brief = "This is a test package." readme = README.md version = 1234-homepage = http://www.idris-lang.org-sourceloc = http://ww.github.com/idris-lang/Idris-Dev-bugtracker = http://ww.github.com/idris-lang/Idris-Dev/issues+homepage = https://www.idris-lang.org+sourceloc = https://www.github.com/idris-lang/Idris-Dev+bugtracker = https://www.github.com/idris-lang/Idris-Dev/issues
− test/pkg002/expected 
+ test/pkg002/expected.out view
− test/pkg002/run 
@@ -1,5 +0,0 @@-#!/usr/bin/env bash-### Test: IPKG executable names can be any namespaced identifier.-${IDRIS:-idris} $@ --build test.ipkg-rm -f *.ibc-rm -f some.namespaced.identifier
+ test/pkg002/run.sh view
@@ -0,0 +1,5 @@+#!/usr/bin/env bash+### Test: IPKG executable names can be any namespaced identifier.+${IDRIS:-idris} $@ --build test.ipkg+rm -f *.ibc+rm -f some.namespaced.identifier
− test/pkg003/expected 
+ test/pkg003/expected.out view
− test/pkg003/run 
@@ -1,6 +0,0 @@-#!/usr/bin/env bash-### Test: IPKG executable names can be a quoted string-### containing a valid filename.-${IDRIS:-idris} $@ --build test.ipkg-rm -f *.ibc-rm -f 'quoting-allows-hyphens and spaces and fun stuff!'
+ test/pkg003/run.sh view
@@ -0,0 +1,6 @@+#!/usr/bin/env bash+### Test: IPKG executable names can be a quoted string+### containing a valid filename.+${IDRIS:-idris} $@ --build test.ipkg+rm -f *.ibc+rm -f 'quoting-allows-hyphens and spaces and fun stuff!'
− test/pkg004/expected 
@@ -1,6 +0,0 @@-Uncaught error: user error (test.ipkg:9:1:-  |-9 | <empty line>-  | ^-filename must contain no directory component-)
+ test/pkg004/expected.out view
@@ -0,0 +1,6 @@+Uncaught error: user error (test.ipkg:9:1:+  |+9 | <empty line>+  | ^+filename must contain no directory component+)
− test/pkg004/run 
@@ -1,6 +0,0 @@-#!/usr/bin/env bash-### Test: IPKG executable names CANNOT include a directory separator.-# TODO: Verify that a name like "a/b\c" is rejected by both *NIX and Windows-# (assuming these tests get run on Windows).-${IDRIS:-idris} $@ --build test.ipkg-rm -f *.ibc
+ test/pkg004/run.sh view
@@ -0,0 +1,6 @@+#!/usr/bin/env bash+### Test: IPKG executable names CANNOT include a directory separator.+# TODO: Verify that a name like "a/b\c" is rejected by both *NIX and Windows+# (assuming these tests get run on Windows).+${IDRIS:-idris} $@ --build test.ipkg+rm -f *.ibc
− test/pkg005/expected 
@@ -1,1 +0,0 @@-Can't build an executable: No main module given
+ test/pkg005/expected.out view
@@ -0,0 +1,1 @@+Can't build an executable: No main module given
− test/pkg005/run 
@@ -1,3 +0,0 @@-#!/usr/bin/env bash-### Test: Build IPKG, executable without main.-${IDRIS:-idris} $@ --build test.ipkg
+ test/pkg005/run.sh view
@@ -0,0 +1,3 @@+#!/usr/bin/env bash+### Test: Build IPKG, executable without main.+${IDRIS:-idris} $@ --build test.ipkg
− test/pkg006/expected 
@@ -1,1 +0,0 @@-Can't start REPL: no main module given
+ test/pkg006/expected.out view
@@ -0,0 +1,1 @@+Can't start REPL: no main module given
− test/pkg006/run 
@@ -1,3 +0,0 @@-#!/usr/bin/env bash-### Test: Launch REPL, IPKG executable without main.-${IDRIS:-idris} $@ --repl test.ipkg
+ test/pkg006/run.sh view
@@ -0,0 +1,3 @@+#!/usr/bin/env bash+### Test: Launch REPL, IPKG executable without main.+${IDRIS:-idris} $@ --repl test.ipkg
− test/pkg007/expected 
@@ -1,1 +0,0 @@-(True, "VROOOOM", Pedal) : (Bool, String, CarPart)
+ test/pkg007/expected.out view
@@ -0,0 +1,1 @@+(True, "VROOOOM", Pedal) : (Bool, String, CarPart)
− test/pkg007/input 
@@ -1,4 +0,0 @@-:module Toy-:module Toy.Vehicle-:module Toy.Vehicle.Car-(toysAreGreat, carNoise, Pedal)
+ test/pkg007/input.in view
@@ -0,0 +1,4 @@+:module Toy+:module Toy.Vehicle+:module Toy.Vehicle.Car+(toysAreGreat, carNoise, Pedal)
− test/pkg007/run 
@@ -1,7 +0,0 @@-#!/usr/bin/env bash-cd toy-${IDRIS:-idris} $@ --build toy.ipkg --ibcsubdir ../ibcout-cd ../ibcout-${IDRIS:-idris} $@ --quiet < ../input-cd ..-rm -rf ibcout
+ test/pkg007/run.sh view
@@ -0,0 +1,7 @@+#!/usr/bin/env bash+cd toy+${IDRIS:-idris} $@ --build toy.ipkg --ibcsubdir ../ibcout+cd ../ibcout+${IDRIS:-idris} $@ --quiet < ../input.in+cd ..+rm -rf ibcout
− test/pkg008/expected 
@@ -1,13 +0,0 @@-Entering directory `./src'-Leaving directory `./src'-Test Passed-Test Passed-Entering directory `./src'-Leaving directory `./src'-Entering directory `./src'-Removed: NumOps.ibc-Removed: Test.ibc-Removed: 00maths-idx.ibc-Leaving directory `./src'-The following packages were specified but cannot be found:-- maths
+ test/pkg008/expected.out view
@@ -0,0 +1,13 @@+Entering directory `./src'+Leaving directory `./src'+Test Passed+Test Passed+Entering directory `./src'+Leaving directory `./src'+Entering directory `./src'+Removed: NumOps.ibc+Removed: Test.ibc+Removed: 00maths-idx.ibc+Leaving directory `./src'+The following packages were specified but cannot be found:+- maths
− test/pkg008/run 
@@ -1,11 +0,0 @@-#!/usr/bin/env bash--${IDRIS:-idris} $@ --build maths.ipkg-${IDRIS:-idris} $@ --testpkg maths.ipkg | grep -v -e "idris"--# Idris only appears in the randomly generated name of test so we grep-# to remove it to make output consistent.--${IDRIS:-idris} $@ --clean maths.ipkg--${IDRIS:-idris} $@ -p maths
+ test/pkg008/run.sh view
@@ -0,0 +1,11 @@+#!/usr/bin/env bash++${IDRIS:-idris} $@ --build maths.ipkg+${IDRIS:-idris} $@ --testpkg maths.ipkg | grep -v -e "idris"++# Idris only appears in the randomly generated name of test so we grep+# to remove it to make output consistent.++${IDRIS:-idris} $@ --clean maths.ipkg++${IDRIS:-idris} $@ -p maths
− test/pkg009/expected 
@@ -1,9 +0,0 @@-Entering directory `./src'-Type checking ./Data/Type.idr-Leaving directory `./src'-Entering directory `./src'-Removed: Data/Type.ibc-Removed: 00datatypes-idx.ibc-Leaving directory `./src'-The following packages were specified but cannot be found:-- datatype.ipkg
+ test/pkg009/expected.out view
@@ -0,0 +1,9 @@+Entering directory `./src'+Type checking ./Data/Type.idr+Leaving directory `./src'+Entering directory `./src'+Removed: Data/Type.ibc+Removed: 00datatypes-idx.ibc+Leaving directory `./src'+The following packages were specified but cannot be found:+- datatype.ipkg
− test/pkg009/run 
@@ -1,7 +0,0 @@-#!/usr/bin/env bash--${IDRIS:-idris} $@ --build datatype.ipkg--${IDRIS:-idris} $@ --clean datatype.ipkg--${IDRIS:-idris} $@ -p datatype.ipkg
+ test/pkg009/run.sh view
@@ -0,0 +1,7 @@+#!/usr/bin/env bash++${IDRIS:-idris} $@ --build datatype.ipkg++${IDRIS:-idris} $@ --clean datatype.ipkg++${IDRIS:-idris} $@ -p datatype.ipkg
− test/pkg010/expected 
@@ -1,31 +0,0 @@-Uncaught error: user error (wrongopts.ipkg:4:1:-  |-4 | <empty line>-  | ^-Invalid option `-total'--Usage:  ([--nobanner] | [-q|--quiet] | [--ide-mode] | [--ide-mode-socket] |-        [--client ARG] | [--log LEVEL] | [--logging-categories CATS] |-        [--nobasepkgs] | [--noprelude] | [--nobuiltins] | [--check] |-        [-o|--output FILE] | [--interface] | [--typeintype] | [--total] |-        [--partial] | [--warnpartial] | [--warnreach] | [--warnipkg] |-        [--nocoverage] | [--errorcontext] | [--info] | [--listlogcats] |-        [--link] | [--listlibs] | [--libdir] | [--docdir] | [--include] | [--V2]-        | [--V1] | [-V|--V0|--verbose] | [--ibcsubdir FILE] |-        [-i|--idrispath ARG] | [--sourcepath ARG] | [--warn] |-        [-p|--package ARG] | [--port PORT] | [--build IPKG] | [--install IPKG] |-        [--repl IPKG] | [--clean IPKG] | [--mkdoc IPKG] | [--installdoc IPKG] |-        [--checkpkg IPKG] | [--testpkg IPKG] | [--indent-with INDENT] |-        [--indent-clause INDENT] | [--bytecode ARG] | [-S|--codegenonly] |-        [-c|--compileonly] | [--dumpdefuns ARG] | [--dumpcases ARG] |-        [--codegen TARGET] | [--portable-codegen TARGET] | [--cg-opt ARG] |-        [-e|--eval EXPR] | [--execute] | [--exec EXPR] | [-X|--extension EXT] |-        [--O3] | [--O2] | [--O1] | [--O0] | [--partial-eval] |-        [--no-partial-eval] |-        [--optimise-nat-like-types|--optimize-nat-like-types] |-        [--no-optimise-nat-like-types|--no-optimize-nat-like-types] |-        [-O|--level ARG] | [--target TRIPLE] | [--cpu CPU] | [--color|--colour]-        | [--nocolor|--nocolour] | [--consolewidth WIDTH] | [--highlight] |-        [--no-tactic-deprecation-warnings] |-        [--allow-capitalized-pattern-variables]) [FILES] [-v|--version]-)
+ test/pkg010/expected.out view
@@ -0,0 +1,29 @@+Uncaught error: user error (wrongopts.ipkg:4:1:+  |+4 | <empty line>+  | ^+Invalid option `-total'++Usage:  [--nobanner | (-q|--quiet) | --ide-mode | --ide-mode-socket | +          --client ARG | --log LEVEL | --logging-categories CATS | +          --nobasepkgs | --noprelude | --nobuiltins | --check | +          (-o|--output FILE) | --interface | --typeintype | --total | +          --partial | --warnpartial | --warnreach | --warnipkg | --nocoverage | +          --errorcontext | --info | --listlogcats | --link | --listlibs | +          --libdir | --docdir | --include | --V2 | --V1 | (-V|--V0|--verbose) | +          --ibcsubdir FILE | (-i|--idrispath ARG) | --sourcepath ARG | --warn | +          (-p|--package ARG) | --port PORT | --build IPKG | --install IPKG | +          --repl IPKG | --clean IPKG | --mkdoc IPKG | --installdoc IPKG | +          --checkpkg IPKG | --testpkg IPKG | --indent-with INDENT | +          --indent-clause INDENT | --bytecode ARG | (-S|--codegenonly) | +          (-c|--compileonly) | --dumpdefuns ARG | --dumpcases ARG | +          --codegen TARGET | --portable-codegen TARGET | --cg-opt ARG | +          (-e|--eval EXPR) | --execute | --exec EXPR | (-X|--extension EXT) | +          --O3 | --O2 | --O1 | --O0 | --partial-eval | --no-partial-eval | +          (--optimise-nat-like-types|--optimize-nat-like-types) | +          (--no-optimise-nat-like-types|--no-optimize-nat-like-types) | +          (-O|--level ARG) | --target TRIPLE | --cpu CPU | (--color|--colour) | +          (--nocolor|--nocolour) | --consolewidth WIDTH | --highlight | +          --no-tactic-deprecation-warnings | +          --allow-capitalized-pattern-variables] [FILES] [-v|--version]+)
− test/pkg010/run 
@@ -1,2 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ --build wrongopts.ipkg
+ test/pkg010/run.sh view
@@ -0,0 +1,2 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ --build wrongopts.ipkg
− test/prelude001/expected 
@@ -1,10 +0,0 @@-True-True-True-True-True-True-True-True-True-True
+ test/prelude001/expected.out view
@@ -0,0 +1,10 @@+True+True+True+True+True+True+True+True+True+True
− test/prelude001/run 
@@ -1,4 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ prelude001.idr -o prelude001-./prelude001-rm -f prelude001 *.ibc
+ test/prelude001/run.sh view
@@ -0,0 +1,4 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ prelude001.idr -o prelude001+./prelude001+rm -f prelude001 *.ibc
− test/primitives001/expected 
@@ -1,27 +0,0 @@-8-("abc", "123")-("abc", "123")-([1, 2], [3, 4, 5])-([1, 2], [3, 4, 5])-ello! here's the thing-22-0-用的依赖类-Idris-[]-is 是一个通用-8-is 是一个通用的依赖类型纯函数式编程语言，其类型系统与 Agda 以及 Epigram 相似。-48-Idris 是一个通用的依赖类型纯函-18--0-is is a -8-is is a general-purpose purely functional programming language with dependent types. -85-Idris is a general-18--0
+ test/primitives001/expected.out view
@@ -0,0 +1,27 @@+8+("abc", "123")+("abc", "123")+([1, 2], [3, 4, 5])+([1, 2], [3, 4, 5])+ello! here's the thing+22+0+用的依赖类+Idris+[]+is 是一个通用+8+is 是一个通用的依赖类型纯函数式编程语言，其类型系统与 Agda 以及 Epigram 相似。+48+Idris 是一个通用的依赖类型纯函+18++0+is is a +8+is is a general-purpose purely functional programming language with dependent types. +85+Idris is a general+18++0
− test/primitives001/input 
@@ -1,2 +0,0 @@-Idris 是一个通用的依赖类型纯函数式编程语言，其类型系统与 Agda 以及 Epigram 相似。-Idris is a general-purpose purely functional programming language with dependent types. 
+ test/primitives001/input.in view
@@ -0,0 +1,2 @@+Idris 是一个通用的依赖类型纯函数式编程语言，其类型系统与 Agda 以及 Epigram 相似。+Idris is a general-purpose purely functional programming language with dependent types. 
− test/primitives001/run 
@@ -1,6 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ test005.idr -o test005-./test005-${IDRIS:-idris} $@ substring.idr -o substring-./substring < input-rm -f test005 substring *.ibc
+ test/primitives001/run.sh view
@@ -0,0 +1,6 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ test005.idr -o test005+./test005+${IDRIS:-idris} $@ substring.idr -o substring+./substring < input.in+rm -f test005 substring *.ibc
− test/primitives002/expected 
@@ -1,46 +0,0 @@-prim__floatToStr 0.0-"0"-prim__strToFloat 0.0-0-prim__addFloat 1.0 1.0-2-prim__subFloat 1.0 1.0-0-prim__mulFloat 1.0 1.0-1-prim__divFloat 1.0 1.0-1-prim__slteFloat 1.0 1.0-1-prim__sltFloat 1.0 1.0-0-prim__sgteFloat 1.0 1.0-1-prim__sgtFloat 1.0 1.0-0-prim__eqFloat 1.0 1.0-1-prim__floatACos 1.0-0-prim__floatATan 1.0-0.78539816-prim__floatCos 1.0-0.54030230-prim__floatFloor 1.0-1-prim__floatSin 1.0-0.84147098-prim__floatTan 1.0-1.55740772-prim__floatASin 1.0-1.57079632-prim__floatCeil 1.0-1-prim__floatExp 1.0-2.71828182-prim__floatLog 1.0-0-prim__floatSqrt 1.0-1-prim__negFloat 1.0--1
+ test/primitives002/expected.out view
@@ -0,0 +1,46 @@+prim__floatToStr 0.0+"0"+prim__strToFloat 0.0+0+prim__addFloat 1.0 1.0+2+prim__subFloat 1.0 1.0+0+prim__mulFloat 1.0 1.0+1+prim__divFloat 1.0 1.0+1+prim__slteFloat 1.0 1.0+1+prim__sltFloat 1.0 1.0+0+prim__sgteFloat 1.0 1.0+1+prim__sgtFloat 1.0 1.0+0+prim__eqFloat 1.0 1.0+1+prim__floatACos 1.0+0+prim__floatATan 1.0+0.78539816+prim__floatCos 1.0+0.54030230+prim__floatFloor 1.0+1+prim__floatSin 1.0+0.84147098+prim__floatTan 1.0+1.55740772+prim__floatASin 1.0+1.57079632+prim__floatCeil 1.0+1+prim__floatExp 1.0+2.71828182+prim__floatLog 1.0+0+prim__floatSqrt 1.0+1+prim__negFloat 1.0+-1
− test/primitives002/run 
@@ -1,54 +0,0 @@-#!/usr/bin/env bash--HEAD='module Main--strtake : Nat -> String -> String-strtake n str = pack (take n (unpack str))--getf : IO Double-getf = map cast getLine--main : IO ()'--# code separated from input with '#'-TESTS=('prim__floatToStr !getf#0.0'- 'prim__strToFloat !getLine#0.0'-$'prim__addFloat !getf !getf#1.0\n1.0'-$'prim__subFloat !getf !getf#1.0\n1.0'-$'prim__mulFloat !getf !getf#1.0\n1.0'-$'prim__divFloat !getf !getf#1.0\n1.0'-$'prim__slteFloat !getf !getf#1.0\n1.0'-$'prim__sltFloat !getf !getf#1.0\n1.0'-$'prim__sgteFloat !getf !getf#1.0\n1.0'-$'prim__sgtFloat !getf !getf#1.0\n1.0'-$'prim__eqFloat !getf !getf#1.0\n1.0'- 'prim__floatACos !getf#1.0'- 'prim__floatATan !getf#1.0'- 'prim__floatCos !getf#1.0'- 'prim__floatFloor !getf#1.0'- 'prim__floatSin !getf#1.0'- 'prim__floatTan !getf#1.0'- 'prim__floatASin !getf#1.0'- 'prim__floatCeil !getf#1.0'- 'prim__floatExp !getf#1.0'- 'prim__floatLog !getf#1.0'- 'prim__floatSqrt !getf#1.0'- 'prim__negFloat !getf#1.0'-)--generate_testfile()-{-cat <<EOF > $1-${HEAD}-main = putStrLn $ strtake 10 (show $ $2)-EOF-}--for T in "${TESTS[@]}"-do-    echo ${T%% *} ${T##*#}-    generate_testfile "tmptest.idr" "${T%%#*}"-    ${IDRIS:-idris} $@ --quiet --port none tmptest.idr -o tmptest || echo "missing primitive in ${CG}"-    ./tmptest <<<"${T##*#}"-    rm tmptest.idr tmptest.ibc tmptest-done
+ test/primitives002/run.sh view
@@ -0,0 +1,54 @@+#!/usr/bin/env bash++HEAD='module Main++strtake : Nat -> String -> String+strtake n str = pack (take n (unpack str))++getf : IO Double+getf = map cast getLine++main : IO ()'++# code separated from input with '#'+TESTS=('prim__floatToStr !getf#0.0'+ 'prim__strToFloat !getLine#0.0'+$'prim__addFloat !getf !getf#1.0\n1.0'+$'prim__subFloat !getf !getf#1.0\n1.0'+$'prim__mulFloat !getf !getf#1.0\n1.0'+$'prim__divFloat !getf !getf#1.0\n1.0'+$'prim__slteFloat !getf !getf#1.0\n1.0'+$'prim__sltFloat !getf !getf#1.0\n1.0'+$'prim__sgteFloat !getf !getf#1.0\n1.0'+$'prim__sgtFloat !getf !getf#1.0\n1.0'+$'prim__eqFloat !getf !getf#1.0\n1.0'+ 'prim__floatACos !getf#1.0'+ 'prim__floatATan !getf#1.0'+ 'prim__floatCos !getf#1.0'+ 'prim__floatFloor !getf#1.0'+ 'prim__floatSin !getf#1.0'+ 'prim__floatTan !getf#1.0'+ 'prim__floatASin !getf#1.0'+ 'prim__floatCeil !getf#1.0'+ 'prim__floatExp !getf#1.0'+ 'prim__floatLog !getf#1.0'+ 'prim__floatSqrt !getf#1.0'+ 'prim__negFloat !getf#1.0'+)++generate_testfile()+{+cat <<EOF > $1+${HEAD}+main = putStrLn $ strtake 10 (show $ $2)+EOF+}++for T in "${TESTS[@]}"+do+    echo ${T%% *} ${T##*#}+    generate_testfile "tmptest.idr" "${T%%#*}"+    ${IDRIS:-idris} $@ --quiet --port none tmptest.idr -o tmptest || echo "missing primitive in ${CG}"+    ./tmptest <<<"${T##*#}"+    rm tmptest.idr tmptest.ibc tmptest+done
− test/primitives003/expected 
@@ -1,31 +0,0 @@-True-False-True-False-True-False-True-True-True-True-True-False-True-False-False-True-False-True-True-False-True-False-False-True-False-False-False-True-False-True-False
+ test/primitives003/expected.out view
@@ -0,0 +1,31 @@+True+False+True+False+True+False+True+True+True+True+True+False+True+False+False+True+False+True+True+False+True+False+False+True+False+False+False+True+False+True+False
− test/primitives003/run 
@@ -1,5 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ -o test038 test038.idr --nocolour-./test038-rm -f test038 *.ibc-
+ test/primitives003/run.sh view
@@ -0,0 +1,5 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ -o test038 test038.idr --nocolour+./test038+rm -f test038 *.ibc+
− test/primitives004-disabled/expected 
@@ -1,4 +0,0 @@-<3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3>-<3, 3, 3, 3, 3, 3, 3, 3>-<3, 3, 3, 3>-<3, 3>
+ test/primitives004-disabled/expected.out view
@@ -0,0 +1,4 @@+<3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3>+<3, 3, 3, 3, 3, 3, 3, 3>+<3, 3, 3, 3>+<3, 3>
− test/primitives004-disabled/run 
@@ -1,4 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ -o primitives004 primitives004.idr --nocolour-./primitives004-rm -f primitives004 *.ibc
+ test/primitives004-disabled/run.sh view
@@ -0,0 +1,4 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ -o primitives004 primitives004.idr --nocolour+./primitives004+rm -f primitives004 *.ibc
− test/primitives005/expected 
@@ -1,2 +0,0 @@-04030201-000000000000FFFF
+ test/primitives005/expected.out view
@@ -0,0 +1,2 @@+04030201+000000000000FFFF
− test/primitives005/run 
@@ -1,5 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ -o p005 primitives005.idr --nocolour-./p005-rm -f p005 *.ibc-
+ test/primitives005/run.sh view
@@ -0,0 +1,5 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ -o p005 primitives005.idr --nocolour+./p005+rm -f p005 *.ibc+
− test/primitives006/expected 
@@ -1,9 +0,0 @@-1024-("01/8", (145536, 897))-("02/8", (145536, 897))-("03/8", (145536, 897))-("04/8", (145536, 897))-("05/8", (145536, 897))-("06/8", (145536, 897))-("07/8", (145536, 897))-("08/8", (145536, 897))
+ test/primitives006/expected.out view
@@ -0,0 +1,9 @@+1024+("01/8", (145536, 897))+("02/8", (145536, 897))+("03/8", (145536, 897))+("04/8", (145536, 897))+("05/8", (145536, 897))+("06/8", (145536, 897))+("07/8", (145536, 897))+("08/8", (145536, 897))
− test/primitives006/run 
@@ -1,6 +0,0 @@-#!/usr/bin/env bash-${CC:-cc} -c -O2 -o array.o array.c $(${IDRIS:-idris} --include)-${IDRIS:-idris} $@ -o load-test load-test.idr --nocolour --warnreach-./load-test-rm -f load-test *.o *.ibc-rm -f Data/*.ibc
+ test/primitives006/run.sh view
@@ -0,0 +1,6 @@+#!/usr/bin/env bash+${CC:-cc} -c -O2 -o array.o array.c $(${IDRIS:-idris} --include)+${IDRIS:-idris} $@ -o load-test load-test.idr --nocolour --warnreach+./load-test+rm -f load-test *.o *.ibc+rm -f Data/*.ibc
− test/proof001/expected 
@@ -1,12 +0,0 @@-test029.idr:29:25-29:-   |-29 | simple.append_lemma_2 = proof {-   |                         ~~~~~-This style of tactic proof is deprecated. See %runElab for the replacement.--test029.idr:36:25-29:-   |-36 | simple.append_lemma_1 = proof {-   |                         ~~~~~-This style of tactic proof is deprecated. See %runElab for the replacement.-
+ test/proof001/expected.out view
@@ -0,0 +1,12 @@+test029.idr:29:25-29:+   |+29 | simple.append_lemma_2 = proof {+   |                         ~~~~~+This style of tactic proof is deprecated. See %runElab for the replacement.++test029.idr:36:25-29:+   |+36 | simple.append_lemma_1 = proof {+   |                         ~~~~~+This style of tactic proof is deprecated. See %runElab for the replacement.+
− test/proof001/run 
@@ -1,3 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ test029.idr --nocolour --check test029-rm -f *.ibc
+ test/proof001/run.sh view
@@ -0,0 +1,3 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ test029.idr --nocolour --check test029+rm -f *.ibc
− test/proof002/expected 
@@ -1,37 +0,0 @@-Reflect.idr:175:21-25:-    |-175 | Reflect.appRExpr1 = proof {-    |                     ~~~~~-This style of tactic proof is deprecated. See %runElab for the replacement.--Reflect.idr:184:21-25:-    |-184 | Reflect.appRExpr2 = proof {-    |                     ~~~~~-This style of tactic proof is deprecated. See %runElab for the replacement.--Reflect.idr:192:15-19:-    |-192 | Reflect.bp1 = proof {-    |               ~~~~~-This style of tactic proof is deprecated. See %runElab for the replacement.--test030a.idr:12:26-37:-   |-12 | testReflect1 {a} xs ys = AssocProof a-   |                          ~~~~~~~~~~~~-When checking right hand side of testReflect1 with expected type-        ys ++ x :: ys ++ xs = (xs ++ [x]) ++ ys ++ xs--When checking an application of function Reflect.getJust:-        Type mismatch between-                IsJust (Just x1) (Type of ItIsJust)-        and-                IsJust (prove (snd x)) (Expected type)-        -        Specifically:-                Type mismatch between-                        Just x-                and-                        Nothing-
+ test/proof002/expected.out view
@@ -0,0 +1,37 @@+Reflect.idr:175:21-25:+    |+175 | Reflect.appRExpr1 = proof {+    |                     ~~~~~+This style of tactic proof is deprecated. See %runElab for the replacement.++Reflect.idr:184:21-25:+    |+184 | Reflect.appRExpr2 = proof {+    |                     ~~~~~+This style of tactic proof is deprecated. See %runElab for the replacement.++Reflect.idr:192:15-19:+    |+192 | Reflect.bp1 = proof {+    |               ~~~~~+This style of tactic proof is deprecated. See %runElab for the replacement.++test030a.idr:12:26-37:+   |+12 | testReflect1 {a} xs ys = AssocProof a+   |                          ~~~~~~~~~~~~+When checking right hand side of testReflect1 with expected type+        ys ++ x :: ys ++ xs = (xs ++ [x]) ++ ys ++ xs++When checking an application of function Reflect.getJust:+        Type mismatch between+                IsJust (Just x1) (Type of ItIsJust)+        and+                IsJust (prove (snd x)) (Expected type)+        +        Specifically:+                Type mismatch between+                        Just x+                and+                        Nothing+
− test/proof002/run 
@@ -1,4 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ test030.idr --check --nocolour-${IDRIS:-idris} $@ test030a.idr --check --nocolour-rm -f *.ibc
+ test/proof002/run.sh view
@@ -0,0 +1,4 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ test030.idr --check --nocolour+${IDRIS:-idris} $@ test030a.idr --check --nocolour+rm -f *.ibc
− test/proof003/expected 
@@ -1,39 +0,0 @@-Parity.idr:17:18-22:-   |-17 | parity_lemma_2 = proof {-   |                  ~~~~~-This style of tactic proof is deprecated. See %runElab for the replacement.--Parity.idr:24:18-22:-   |-24 | parity_lemma_1 = proof {-   |                  ~~~~~-This style of tactic proof is deprecated. See %runElab for the replacement.--test015.idr:88:15-19:-   |-88 | Main.ntbOdd = proof {-   |               ~~~~~-This style of tactic proof is deprecated. See %runElab for the replacement.--test015.idr:97:16-20:-   |-97 | Main.ntbEven = proof {-   |                ~~~~~-This style of tactic proof is deprecated. See %runElab for the replacement.--test015.idr:107:20-24:-    |-107 | Main.adc_lemma_2 = proof {-    |                    ~~~~~-This style of tactic proof is deprecated. See %runElab for the replacement.--test015.idr:142:20-24:-    |-142 | Main.adc_lemma_1 = proof {-    |                    ~~~~~-This style of tactic proof is deprecated. See %runElab for the replacement.--00101010-01011001-010000011
+ test/proof003/expected.out view
@@ -0,0 +1,39 @@+Parity.idr:17:18-22:+   |+17 | parity_lemma_2 = proof {+   |                  ~~~~~+This style of tactic proof is deprecated. See %runElab for the replacement.++Parity.idr:24:18-22:+   |+24 | parity_lemma_1 = proof {+   |                  ~~~~~+This style of tactic proof is deprecated. See %runElab for the replacement.++test015.idr:88:15-19:+   |+88 | Main.ntbOdd = proof {+   |               ~~~~~+This style of tactic proof is deprecated. See %runElab for the replacement.++test015.idr:97:16-20:+   |+97 | Main.ntbEven = proof {+   |                ~~~~~+This style of tactic proof is deprecated. See %runElab for the replacement.++test015.idr:107:20-24:+    |+107 | Main.adc_lemma_2 = proof {+    |                    ~~~~~+This style of tactic proof is deprecated. See %runElab for the replacement.++test015.idr:142:20-24:+    |+142 | Main.adc_lemma_1 = proof {+    |                    ~~~~~+This style of tactic proof is deprecated. See %runElab for the replacement.++00101010+01011001+010000011
− test/proof003/run 
@@ -1,4 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ test015.idr --nocolour -o test015-./test015-rm -f test015 Parity.ibc test015.ibc
+ test/proof003/run.sh view
@@ -0,0 +1,4 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ test015.idr --nocolour -o test015+./test015+rm -f test015 Parity.ibc test015.ibc
− test/proof004/expected 
+ test/proof004/expected.out view
− test/proof004/run 
@@ -1,3 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ --check test035.idr-rm -f *.ibc
+ test/proof004/run.sh view
@@ -0,0 +1,3 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ --check test035.idr+rm -f *.ibc
− test/proof005/expected 
+ test/proof005/expected.out view
− test/proof005/run 
@@ -1,3 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ --check DefaultArgSubstitutionSuccess.idr-rm -f *.ibc
+ test/proof005/run.sh view
@@ -0,0 +1,3 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ --check DefaultArgSubstitutionSuccess.idr+rm -f *.ibc
− test/proof006/expected 
+ test/proof006/expected.out view
− test/proof006/run 
@@ -1,3 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ --check DefaultArgSubstitutionSyntax.idr-rm -f *.ibc
+ test/proof006/run.sh view
@@ -0,0 +1,3 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ --check DefaultArgSubstitutionSyntax.idr+rm -f *.ibc
− test/proof007/expected 
@@ -1,10 +0,0 @@-DefaultArgUnknownName.idr:9:8-23:-  |-9 | test = funWithBadDefArg-  |        ~~~~~~~~~~~~~~~~-When checking right hand side of test with expected type-        ()--When checking argument arg to function DefaultArgUnknownName.funWithBadDefArg:-        No such variable sadgjhsag-
+ test/proof007/expected.out view
@@ -0,0 +1,10 @@+DefaultArgUnknownName.idr:9:8-23:+  |+9 | test = funWithBadDefArg+  |        ~~~~~~~~~~~~~~~~+When checking right hand side of test with expected type+        ()++When checking argument arg to function DefaultArgUnknownName.funWithBadDefArg:+        No such variable sadgjhsag+
− test/proof007/run 
@@ -1,3 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ --nocolour --check DefaultArgUnknownName.idr-rm -f *.ibc
+ test/proof007/run.sh view
@@ -0,0 +1,3 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ --nocolour --check DefaultArgUnknownName.idr+rm -f *.ibc
− test/proof008/expected 
@@ -1,6 +0,0 @@-ClaimAndUnfocus.idr:8:27-31:-  |-8 | ClaimAndUnfocus.foo_rhs = proof-  |                           ~~~~~-This style of tactic proof is deprecated. See %runElab for the replacement.-
+ test/proof008/expected.out view
@@ -0,0 +1,6 @@+ClaimAndUnfocus.idr:8:27-31:+  |+8 | ClaimAndUnfocus.foo_rhs = proof+  |                           ~~~~~+This style of tactic proof is deprecated. See %runElab for the replacement.+
− test/proof008/run 
@@ -1,3 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ --nocolour --check ClaimAndUnfocus.idr-rm -f *.ibc
+ test/proof008/run.sh view
@@ -0,0 +1,3 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ --nocolour --check ClaimAndUnfocus.idr+rm -f *.ibc
− test/proof009/expected 
@@ -1,26 +0,0 @@-Warning: this interactive prover is deprecated and will be removed in a future release. Please see :elab for a similar feature that will replace it.-------------                 Goal:                  -----------{hole_0} : Int -> Int -> Int--Main.arhs> ----------              Other goals:              -----------{hole_0}-----------              Assumptions:              ----------- x : Int-----------                 Goal:                  -----------{hole_1} : Int -> Int--Main.arhs> ----------              Other goals:              -----------{hole_1},{hole_0}-----------              Assumptions:              ----------- x : Int- y : Int-----------                 Goal:                  -----------{hole_2} : Int--Main.arhs> arhs: No more goals.--Main.arhs> Proof completed!-Main.arhs = proof-  intro x-  intros-  trivial--
+ test/proof009/expected.out view
@@ -0,0 +1,26 @@+Warning: this interactive prover is deprecated and will be removed in a future release. Please see :elab for a similar feature that will replace it.+++----------                 Goal:                  ----------+{hole_0} : Int -> Int -> Int+-Main.arhs> ----------              Other goals:              ----------+{hole_0}+----------              Assumptions:              ----------+ x : Int+----------                 Goal:                  ----------+{hole_1} : Int -> Int+-Main.arhs> ----------              Other goals:              ----------+{hole_1},{hole_0}+----------              Assumptions:              ----------+ x : Int+ y : Int+----------                 Goal:                  ----------+{hole_2} : Int+-Main.arhs> arhs: No more goals.+-Main.arhs> Proof completed!+Main.arhs = proof+  intro x+  intros+  trivial++
− test/proof009/input 
@@ -1,6 +0,0 @@-:p arhs-intro x-intros-trivial-qed-:q
+ test/proof009/input.in view
@@ -0,0 +1,6 @@+:p arhs+intro x+intros+trivial+qed+:q
− test/proof009/run 
@@ -1,3 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ --consolewidth 70 --quiet --port none proof009.idr < input-rm -f *.ibc
+ test/proof009/run.sh view
@@ -0,0 +1,3 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ --consolewidth 70 --quiet --port none proof009.idr < input.in+rm -f *.ibc
− test/proof010/expected 
@@ -1,6 +0,0 @@-2, << function >>-3, << function >>--some bools-some bools-
+ test/proof010/expected.out view
@@ -0,0 +1,6 @@+2, << function >>+3, << function >>++some bools+some bools+
− test/proof010/run 
@@ -1,4 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ proof010.idr -o proof010-./proof010-rm -f proof010 *.ibc
+ test/proof010/run.sh view
@@ -0,0 +1,4 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ proof010.idr -o proof010+./proof010+rm -f proof010 *.ibc
− test/proof011/expected 
@@ -1,28 +0,0 @@-proof011.idr:20:7-21:18:-   |-20 |     = rewrite vassoc xs ys xs using vreplace in -   |       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ...-When checking right hand side of vassoc' with expected type-        (x :: xs) ++ ys ++ zs = ((x :: xs) ++ ys) ++ zs--rewriting xs ++ ys ++ xs to (xs ++ ys) ++ xs did not change type x ::-                                                                 xs ++-                                                                 ys ++ zs =-                                                                 x ::-                                                                 (xs ++ ys) ++-                                                                 zs--proof011a.idr:14:7-37:-   |-14 |     = rewrite vassoc xs ys xs in Refl-   |       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~-When checking right hand side of vassoc' with expected type-        (x :: xs) ++ ys ++ zs = ((x :: xs) ++ ys) ++ zs--rewriting xs ++ ys ++ xs to (xs ++ ys) ++ xs did not change type x ::-                                                                 xs ++-                                                                 ys ++ zs =-                                                                 x ::-                                                                 (xs ++ ys) ++-                                                                 zs-
+ test/proof011/expected.out view
@@ -0,0 +1,28 @@+proof011.idr:20:7-21:18:+   |+20 |     = rewrite vassoc xs ys xs using vreplace in +   |       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ...+When checking right hand side of vassoc' with expected type+        (x :: xs) ++ ys ++ zs = ((x :: xs) ++ ys) ++ zs++rewriting xs ++ ys ++ xs to (xs ++ ys) ++ xs did not change type x ::+                                                                 xs +++                                                                 ys ++ zs =+                                                                 x ::+                                                                 (xs ++ ys) +++                                                                 zs++proof011a.idr:14:7-37:+   |+14 |     = rewrite vassoc xs ys xs in Refl+   |       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+When checking right hand side of vassoc' with expected type+        (x :: xs) ++ ys ++ zs = ((x :: xs) ++ ys) ++ zs++rewriting xs ++ ys ++ xs to (xs ++ ys) ++ xs did not change type x ::+                                                                 xs +++                                                                 ys ++ zs =+                                                                 x ::+                                                                 (xs ++ ys) +++                                                                 zs+
− test/proof011/run 
@@ -1,4 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ proof011.idr --nocolour --check-${IDRIS:-idris} $@ proof011a.idr --nocolour --check-rm -f *.ibc
+ test/proof011/run.sh view
@@ -0,0 +1,4 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ proof011.idr --nocolour --check+${IDRIS:-idris} $@ proof011a.idr --nocolour --check+rm -f *.ibc
− test/proofsearch001/expected 
+ test/proofsearch001/expected.out view
− test/proofsearch001/run 
@@ -1,3 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ --check proofsearch001.idr-rm -f *.ibc
+ test/proofsearch001/run.sh view
@@ -0,0 +1,3 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ --check proofsearch001.idr+rm -f *.ibc
− test/proofsearch002/expected 
+ test/proofsearch002/expected.out view
− test/proofsearch002/run 
@@ -1,3 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ --check proofsearch002.idr-rm -f *.ibc
+ test/proofsearch002/run.sh view
@@ -0,0 +1,3 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ --check proofsearch002.idr+rm -f *.ibc
− test/proofsearch003/expected 
+ test/proofsearch003/expected.out view
− test/proofsearch003/run 
@@ -1,3 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ --check proofsearch003.idr -rm -f *.ibc
+ test/proofsearch003/run.sh view
@@ -0,0 +1,3 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ --check proofsearch003.idr +rm -f *.ibc
− test/pruviloj001/expected 
+ test/pruviloj001/expected.out view
− test/pruviloj001/run 
@@ -1,3 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ -p pruviloj --check --nocolour --consolewidth 70 pruviloj001.idr-rm -f *.ibc
+ test/pruviloj001/run.sh view
@@ -0,0 +1,3 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ -p pruviloj --check --nocolour --consolewidth 70 pruviloj001.idr+rm -f *.ibc
− test/quasiquote001/expected 
@@ -1,5 +0,0 @@-App (App (App (P (DCon 1 3) (NS (UN "::") ["List", "Prelude"]) (Bind (UN "elem") (Pi (TType (UVar "./Prelude/List.idr" 28)) (TType (UVar "./Prelude/List.idr" 30))) (Bind (UN "x") (Pi (V 0) (TType (UVar "./Prelude/List.idr" 31))) (Bind (UN "xs") (Pi (App (P (TCon 0 0) (NS (UN "List") ["List", "Prelude"]) Erased) (V 1)) (TType (UVar "./Prelude/List.idr" 32))) (App (P (TCon 0 0) (NS (UN "List") ["List", "Prelude"]) Erased) (V 2)))))) (P (TCon 8 0) (UN "Unit") (TType (UVar "./Builtins.idr" 20)))) (P (DCon 0 0) (UN "MkUnit") (P (TCon 0 0) (UN "Unit") Erased))) (App (App (App (P (DCon 1 3) (NS (UN "::") ["List", "Prelude"]) (Bind (UN "elem") (Pi (TType (UVar "./Prelude/List.idr" 28)) (TType (UVar "./Prelude/List.idr" 30))) (Bind (UN "x") (Pi (V 0) (TType (UVar "./Prelude/List.idr" 31))) (Bind (UN "xs") (Pi (App (P (TCon 0 0) (NS (UN "List") ["List", "Prelude"]) Erased) (V 1)) (TType (UVar "./Prelude/List.idr" 32))) (App (P (TCon 0 0) (NS (UN "List") ["List", "Prelude"]) Erased) (V 2)))))) (P (TCon 8 0) (UN "Unit") (TType (UVar "./Builtins.idr" 20)))) (P (DCon 0 0) (UN "MkUnit") (P (TCon 0 0) (UN "Unit") Erased))) (App (P (DCon 0 1) (NS (UN "Nil") ["List", "Prelude"]) (Bind (UN "elem") (Pi (TType (UVar "./Prelude/List.idr" 25)) (TType (UVar "./Prelude/List.idr" 27))) (App (P (TCon 0 0) (NS (UN "List") ["List", "Prelude"]) Erased) (V 0)))) (P (TCon 8 0) (UN "Unit") (TType (UVar "./Builtins.idr" 20)))))----------------App (App (App (P (DCon 1 3) (NS (UN "::") ["List", "Prelude"]) (Bind (UN "elem") (Pi (TType (UVar "./Prelude/List.idr" 28)) (TType (UVar "./Prelude/List.idr" 30))) (Bind (UN "x") (Pi (V 0) (TType (UVar "./Prelude/List.idr" 31))) (Bind (UN "xs") (Pi (App (P (TCon 0 0) (NS (UN "List") ["List", "Prelude"]) Erased) (V 1)) (TType (UVar "./Prelude/List.idr" 32))) (App (P (TCon 0 0) (NS (UN "List") ["List", "Prelude"]) Erased) (V 2)))))) (TType (UVar "./QuasiquoteBasics.idr" 27))) (TType (UVar "./QuasiquoteBasics.idr" 28))) (App (App (App (P (DCon 1 3) (NS (UN "::") ["List", "Prelude"]) (Bind (UN "elem") (Pi (TType (UVar "./Prelude/List.idr" 28)) (TType (UVar "./Prelude/List.idr" 30))) (Bind (UN "x") (Pi (V 0) (TType (UVar "./Prelude/List.idr" 31))) (Bind (UN "xs") (Pi (App (P (TCon 0 0) (NS (UN "List") ["List", "Prelude"]) Erased) (V 1)) (TType (UVar "./Prelude/List.idr" 32))) (App (P (TCon 0 0) (NS (UN "List") ["List", "Prelude"]) Erased) (V 2)))))) (TType (UVar "./QuasiquoteBasics.idr" 29))) (App (App (App (App (P (DCon 0 4) (NS (UN "MkPair") ["Builtins"]) (Bind (UN "A") (Pi (TType (UVar "./Builtins.idr" 30)) (TType (UVar "./Builtins.idr" 32))) (Bind (UN "B") (Pi (TType (UVar "./Builtins.idr" 33)) (TType (UVar "./Builtins.idr" 35))) (Bind (UN "a") (Pi (V 1) (TType (UVar "./Builtins.idr" 36))) (Bind (UN "b") (Pi (V 1) (TType (UVar "./Builtins.idr" 37))) (App (App (P (TCon 0 0) (NS (UN "Pair") ["Builtins"]) Erased) (V 3)) (V 2))))))) (TType (UVar "./QuasiquoteBasics.idr" 23))) (TType (UVar "./QuasiquoteBasics.idr" 24))) (P (TCon 8 0) (NS (UN "Nat") ["Nat", "Prelude"]) (TType (UVar "./Prelude/Nat.idr" 20)))) (P (TCon 8 0) (NS (UN "Nat") ["Nat", "Prelude"]) (TType (UVar "./Prelude/Nat.idr" 20))))) (App (P (DCon 0 1) (NS (UN "Nil") ["List", "Prelude"]) (Bind (UN "elem") (Pi (TType (UVar "./Prelude/List.idr" 25)) (TType (UVar "./Prelude/List.idr" 27))) (App (P (TCon 0 0) (NS (UN "List") ["List", "Prelude"]) Erased) (V 0)))) (TType (UVar "./QuasiquoteBasics.idr" 30))))----------------App (App (App (App (P (DCon 0 4) (NS (UN "MkPair") ["Builtins"]) (Bind (UN "A") (Pi (TType (UVar "./Builtins.idr" 30)) (TType (UVar "./Builtins.idr" 32))) (Bind (UN "B") (Pi (TType (UVar "./Builtins.idr" 33)) (TType (UVar "./Builtins.idr" 35))) (Bind (UN "a") (Pi (V 1) (TType (UVar "./Builtins.idr" 36))) (Bind (UN "b") (Pi (V 1) (TType (UVar "./Builtins.idr" 37))) (App (App (P (TCon 0 0) (NS (UN "Pair") ["Builtins"]) Erased) (V 3)) (V 2))))))) (TType (UVar "./QuasiquoteBasics.idr" 23))) (TType (UVar "./QuasiquoteBasics.idr" 24))) (App (App (App (App (P (DCon 0 4) (NS (UN "MkPair") ["Builtins"]) (Bind (UN "A") (Pi (TType (UVar "./Builtins.idr" 30)) (TType (UVar "./Builtins.idr" 32))) (Bind (UN "B") (Pi (TType (UVar "./Builtins.idr" 33)) (TType (UVar "./Builtins.idr" 35))) (Bind (UN "a") (Pi (V 1) (TType (UVar "./Builtins.idr" 36))) (Bind (UN "b") (Pi (V 1) (TType (UVar "./Builtins.idr" 37))) (App (App (P (TCon 0 0) (NS (UN "Pair") ["Builtins"]) Erased) (V 3)) (V 2))))))) (TType (UVar "./QuasiquoteBasics.idr" 23))) (TType (UVar "./QuasiquoteBasics.idr" 24))) (TType (UVar "./QuasiquoteBasics.idr" 28))) (TType (UVar "./QuasiquoteBasics.idr" 28)))) (App (App (App (App (P (DCon 0 4) (NS (UN "MkPair") ["Builtins"]) (Bind (UN "A") (Pi (TType (UVar "./Builtins.idr" 30)) (TType (UVar "./Builtins.idr" 32))) (Bind (UN "B") (Pi (TType (UVar "./Builtins.idr" 33)) (TType (UVar "./Builtins.idr" 35))) (Bind (UN "a") (Pi (V 1) (TType (UVar "./Builtins.idr" 36))) (Bind (UN "b") (Pi (V 1) (TType (UVar "./Builtins.idr" 37))) (App (App (P (TCon 0 0) (NS (UN "Pair") ["Builtins"]) Erased) (V 3)) (V 2))))))) (TType (UVar "./QuasiquoteBasics.idr" 23))) (TType (UVar "./QuasiquoteBasics.idr" 24))) (TType (UVar "./QuasiquoteBasics.idr" 28))) (TType (UVar "./QuasiquoteBasics.idr" 28)))
+ test/quasiquote001/expected.out view
@@ -0,0 +1,5 @@+App (App (App (P (DCon 1 3) (NS (UN "::") ["List", "Prelude"]) (Bind (UN "elem") (Pi (TType (UVar "./Prelude/List.idr" 28)) (TType (UVar "./Prelude/List.idr" 30))) (Bind (UN "x") (Pi (V 0) (TType (UVar "./Prelude/List.idr" 31))) (Bind (UN "xs") (Pi (App (P (TCon 0 0) (NS (UN "List") ["List", "Prelude"]) Erased) (V 1)) (TType (UVar "./Prelude/List.idr" 32))) (App (P (TCon 0 0) (NS (UN "List") ["List", "Prelude"]) Erased) (V 2)))))) (P (TCon 8 0) (UN "Unit") (TType (UVar "./Builtins.idr" 20)))) (P (DCon 0 0) (UN "MkUnit") (P (TCon 0 0) (UN "Unit") Erased))) (App (App (App (P (DCon 1 3) (NS (UN "::") ["List", "Prelude"]) (Bind (UN "elem") (Pi (TType (UVar "./Prelude/List.idr" 28)) (TType (UVar "./Prelude/List.idr" 30))) (Bind (UN "x") (Pi (V 0) (TType (UVar "./Prelude/List.idr" 31))) (Bind (UN "xs") (Pi (App (P (TCon 0 0) (NS (UN "List") ["List", "Prelude"]) Erased) (V 1)) (TType (UVar "./Prelude/List.idr" 32))) (App (P (TCon 0 0) (NS (UN "List") ["List", "Prelude"]) Erased) (V 2)))))) (P (TCon 8 0) (UN "Unit") (TType (UVar "./Builtins.idr" 20)))) (P (DCon 0 0) (UN "MkUnit") (P (TCon 0 0) (UN "Unit") Erased))) (App (P (DCon 0 1) (NS (UN "Nil") ["List", "Prelude"]) (Bind (UN "elem") (Pi (TType (UVar "./Prelude/List.idr" 25)) (TType (UVar "./Prelude/List.idr" 27))) (App (P (TCon 0 0) (NS (UN "List") ["List", "Prelude"]) Erased) (V 0)))) (P (TCon 8 0) (UN "Unit") (TType (UVar "./Builtins.idr" 20)))))+--------------+App (App (App (P (DCon 1 3) (NS (UN "::") ["List", "Prelude"]) (Bind (UN "elem") (Pi (TType (UVar "./Prelude/List.idr" 28)) (TType (UVar "./Prelude/List.idr" 30))) (Bind (UN "x") (Pi (V 0) (TType (UVar "./Prelude/List.idr" 31))) (Bind (UN "xs") (Pi (App (P (TCon 0 0) (NS (UN "List") ["List", "Prelude"]) Erased) (V 1)) (TType (UVar "./Prelude/List.idr" 32))) (App (P (TCon 0 0) (NS (UN "List") ["List", "Prelude"]) Erased) (V 2)))))) (TType (UVar "./QuasiquoteBasics.idr" 27))) (TType (UVar "./QuasiquoteBasics.idr" 28))) (App (App (App (P (DCon 1 3) (NS (UN "::") ["List", "Prelude"]) (Bind (UN "elem") (Pi (TType (UVar "./Prelude/List.idr" 28)) (TType (UVar "./Prelude/List.idr" 30))) (Bind (UN "x") (Pi (V 0) (TType (UVar "./Prelude/List.idr" 31))) (Bind (UN "xs") (Pi (App (P (TCon 0 0) (NS (UN "List") ["List", "Prelude"]) Erased) (V 1)) (TType (UVar "./Prelude/List.idr" 32))) (App (P (TCon 0 0) (NS (UN "List") ["List", "Prelude"]) Erased) (V 2)))))) (TType (UVar "./QuasiquoteBasics.idr" 29))) (App (App (App (App (P (DCon 0 4) (NS (UN "MkPair") ["Builtins"]) (Bind (UN "A") (Pi (TType (UVar "./Builtins.idr" 30)) (TType (UVar "./Builtins.idr" 32))) (Bind (UN "B") (Pi (TType (UVar "./Builtins.idr" 33)) (TType (UVar "./Builtins.idr" 35))) (Bind (UN "a") (Pi (V 1) (TType (UVar "./Builtins.idr" 36))) (Bind (UN "b") (Pi (V 1) (TType (UVar "./Builtins.idr" 37))) (App (App (P (TCon 0 0) (NS (UN "Pair") ["Builtins"]) Erased) (V 3)) (V 2))))))) (TType (UVar "./QuasiquoteBasics.idr" 23))) (TType (UVar "./QuasiquoteBasics.idr" 24))) (P (TCon 8 0) (NS (UN "Nat") ["Nat", "Prelude"]) (TType (UVar "./Prelude/Nat.idr" 20)))) (P (TCon 8 0) (NS (UN "Nat") ["Nat", "Prelude"]) (TType (UVar "./Prelude/Nat.idr" 20))))) (App (P (DCon 0 1) (NS (UN "Nil") ["List", "Prelude"]) (Bind (UN "elem") (Pi (TType (UVar "./Prelude/List.idr" 25)) (TType (UVar "./Prelude/List.idr" 27))) (App (P (TCon 0 0) (NS (UN "List") ["List", "Prelude"]) Erased) (V 0)))) (TType (UVar "./QuasiquoteBasics.idr" 30))))+--------------+App (App (App (App (P (DCon 0 4) (NS (UN "MkPair") ["Builtins"]) (Bind (UN "A") (Pi (TType (UVar "./Builtins.idr" 30)) (TType (UVar "./Builtins.idr" 32))) (Bind (UN "B") (Pi (TType (UVar "./Builtins.idr" 33)) (TType (UVar "./Builtins.idr" 35))) (Bind (UN "a") (Pi (V 1) (TType (UVar "./Builtins.idr" 36))) (Bind (UN "b") (Pi (V 1) (TType (UVar "./Builtins.idr" 37))) (App (App (P (TCon 0 0) (NS (UN "Pair") ["Builtins"]) Erased) (V 3)) (V 2))))))) (TType (UVar "./QuasiquoteBasics.idr" 23))) (TType (UVar "./QuasiquoteBasics.idr" 24))) (App (App (App (App (P (DCon 0 4) (NS (UN "MkPair") ["Builtins"]) (Bind (UN "A") (Pi (TType (UVar "./Builtins.idr" 30)) (TType (UVar "./Builtins.idr" 32))) (Bind (UN "B") (Pi (TType (UVar "./Builtins.idr" 33)) (TType (UVar "./Builtins.idr" 35))) (Bind (UN "a") (Pi (V 1) (TType (UVar "./Builtins.idr" 36))) (Bind (UN "b") (Pi (V 1) (TType (UVar "./Builtins.idr" 37))) (App (App (P (TCon 0 0) (NS (UN "Pair") ["Builtins"]) Erased) (V 3)) (V 2))))))) (TType (UVar "./QuasiquoteBasics.idr" 23))) (TType (UVar "./QuasiquoteBasics.idr" 24))) (TType (UVar "./QuasiquoteBasics.idr" 28))) (TType (UVar "./QuasiquoteBasics.idr" 28)))) (App (App (App (App (P (DCon 0 4) (NS (UN "MkPair") ["Builtins"]) (Bind (UN "A") (Pi (TType (UVar "./Builtins.idr" 30)) (TType (UVar "./Builtins.idr" 32))) (Bind (UN "B") (Pi (TType (UVar "./Builtins.idr" 33)) (TType (UVar "./Builtins.idr" 35))) (Bind (UN "a") (Pi (V 1) (TType (UVar "./Builtins.idr" 36))) (Bind (UN "b") (Pi (V 1) (TType (UVar "./Builtins.idr" 37))) (App (App (P (TCon 0 0) (NS (UN "Pair") ["Builtins"]) Erased) (V 3)) (V 2))))))) (TType (UVar "./QuasiquoteBasics.idr" 23))) (TType (UVar "./QuasiquoteBasics.idr" 24))) (TType (UVar "./QuasiquoteBasics.idr" 28))) (TType (UVar "./QuasiquoteBasics.idr" 28)))
− test/quasiquote001/run 
@@ -1,4 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ QuasiquoteBasics.idr -o quasiquote001-./quasiquote001-rm -f quasiquote001 *.ibc
+ test/quasiquote001/run.sh view
@@ -0,0 +1,4 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ QuasiquoteBasics.idr -o quasiquote001+./quasiquote001+rm -f quasiquote001 *.ibc
− test/quasiquote002/expected 
@@ -1,1 +0,0 @@-con
+ test/quasiquote002/expected.out view
@@ -0,0 +1,1 @@+con
− test/quasiquote002/run 
@@ -1,4 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ GoalQQuote.idr -o quasiquote002-./quasiquote002-rm -f quasiquote002 *.ibc
+ test/quasiquote002/run.sh view
@@ -0,0 +1,4 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ GoalQQuote.idr -o quasiquote002+./quasiquote002+rm -f quasiquote002 *.ibc
− test/quasiquote003/expected 
@@ -1,9 +0,0 @@-NoInfer.idr:11:7-11:-   |-11 | zzz = `(FZ)-   |       ~~~~~-When checking right hand side of zzz with expected type-        TT--No such variable k-
+ test/quasiquote003/expected.out view
@@ -0,0 +1,9 @@+NoInfer.idr:11:7-11:+   |+11 | zzz = `(FZ)+   |       ~~~~~+When checking right hand side of zzz with expected type+        TT++No such variable k+
− test/quasiquote003/run 
@@ -1,3 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ --check NoInfer.idr-rm -f *.ibc
+ test/quasiquote003/run.sh view
@@ -0,0 +1,3 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ --check NoInfer.idr+rm -f *.ibc
− test/quasiquote004/expected 
@@ -1,27 +0,0 @@-Quasiquote004.idr:39:26-30:-   |-39 | Quasiquote004.getMeNat = proof-   |                          ~~~~~-This style of tactic proof is deprecated. See %runElab for the replacement.--Quasiquote004.idr:42:28-32:-   |-42 | Quasiquote004.fizzyIsAOK = proof-   |                            ~~~~~-This style of tactic proof is deprecated. See %runElab for the replacement.--Quasiquote004.idr:50:27-31:-   |-50 | Quasiquote004.getMeNat' = proof-   |                           ~~~~~-This style of tactic proof is deprecated. See %runElab for the replacement.--Quasiquote004.idr:50:27-51:18:-   |-50 | Quasiquote004.getMeNat' = proof-   |                           ~~~~~ ...-When checking right hand side of Quasiquote004.getMeNat' with expected type-        String--Not a Nat goal-
+ test/quasiquote004/expected.out view
@@ -0,0 +1,27 @@+Quasiquote004.idr:39:26-30:+   |+39 | Quasiquote004.getMeNat = proof+   |                          ~~~~~+This style of tactic proof is deprecated. See %runElab for the replacement.++Quasiquote004.idr:42:28-32:+   |+42 | Quasiquote004.fizzyIsAOK = proof+   |                            ~~~~~+This style of tactic proof is deprecated. See %runElab for the replacement.++Quasiquote004.idr:50:27-31:+   |+50 | Quasiquote004.getMeNat' = proof+   |                           ~~~~~+This style of tactic proof is deprecated. See %runElab for the replacement.++Quasiquote004.idr:50:27-51:18:+   |+50 | Quasiquote004.getMeNat' = proof+   |                           ~~~~~ ...+When checking right hand side of Quasiquote004.getMeNat' with expected type+        String++Not a Nat goal+
− test/quasiquote004/run 
@@ -1,3 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ --check --nocolour Quasiquote004.idr-rm -f *.ibc
+ test/quasiquote004/run.sh view
@@ -0,0 +1,3 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ --check --nocolour Quasiquote004.idr+rm -f *.ibc
− test/quasiquote005/expected 
+ test/quasiquote005/expected.out view
− test/quasiquote005/run 
@@ -1,3 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ --check --nocolour Quasiquote005.idr-rm -f *.ibc
+ test/quasiquote005/run.sh view
@@ -0,0 +1,3 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ --check --nocolour Quasiquote005.idr+rm -f *.ibc
− test/quasiquote006/expected 
@@ -1,31 +0,0 @@-quasiquote006.idr:9:5-10:-  |-9 | b = `{Nil}-  |     ~~~~~~-When checking right hand side of b with expected type-        TTName--Can't disambiguate name: ForeignEnv.Nil, -                         Prelude.List.Nil--quasiquote006.idr:12:5-17:-   |-12 | c = `{alsdkjflkj}-   |     ~~~~~~~~~~~~~-When checking right hand side of c with expected type-        TTName--No such variable alsdkjflkj--quasiquote006.idr:15:5-11:-   |-15 | d = `{(::)}-   |     ~~~~~~~-When checking right hand side of d with expected type-        TTName--Can't disambiguate name: ForeignEnv.::, -                         Prelude.List.::, -                         Prelude.Stream.::-- quasiquote006.idr:17:3:Main.d already defined
+ test/quasiquote006/expected.out view
@@ -0,0 +1,31 @@+quasiquote006.idr:9:5-10:+  |+9 | b = `{Nil}+  |     ~~~~~~+When checking right hand side of b with expected type+        TTName++Can't disambiguate name: ForeignEnv.Nil, +                         Prelude.List.Nil++quasiquote006.idr:12:5-17:+   |+12 | c = `{alsdkjflkj}+   |     ~~~~~~~~~~~~~+When checking right hand side of c with expected type+        TTName++No such variable alsdkjflkj++quasiquote006.idr:15:5-11:+   |+15 | d = `{(::)}+   |     ~~~~~~~+When checking right hand side of d with expected type+        TTName++Can't disambiguate name: ForeignEnv.::, +                         Prelude.List.::, +                         Prelude.Stream.::++ quasiquote006.idr:17:3:Main.d already defined
− test/quasiquote006/run 
@@ -1,3 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ --check --nocolour --quiet --port none --consolewidth 70 quasiquote006.idr-rm -f *.ibc
+ test/quasiquote006/run.sh view
@@ -0,0 +1,3 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ --check --nocolour --quiet --port none --consolewidth 70 quasiquote006.idr+rm -f *.ibc
− test/records001/expected 
@@ -1,5 +0,0 @@-"foo"-"Fred"-[1, 2, 3]-["b", "a"]-25
+ test/records001/expected.out view
@@ -0,0 +1,5 @@+"foo"+"Fred"+[1, 2, 3]+["b", "a"]+25
− test/records001/run 
@@ -1,4 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ test011.idr -o test011-./test011-rm -f test011 test011.ibc
+ test/records001/run.sh view
@@ -0,0 +1,4 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ test011.idr -o test011+./test011+rm -f test011 test011.ibc
− test/records002/expected 
@@ -1,2 +0,0 @@-42, 20-10, 42
+ test/records002/expected.out view
@@ -0,0 +1,2 @@+42, 20+10, 42
− test/records002/run 
@@ -1,4 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ record002.idr -o record002-./record002-rm -f record002 *.ibc
+ test/records002/run.sh view
@@ -0,0 +1,4 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ record002.idr -o record002+./record002+rm -f record002 *.ibc
− test/records003/expected 
@@ -1,6 +0,0 @@-"Fred"-21-20-30-29-2014
+ test/records003/expected.out view
@@ -0,0 +1,6 @@+"Fred"+21+20+30+29+2014
− test/records003/run 
@@ -1,4 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ records003.idr -o records003-./records003-rm -f records003 *.ibc
+ test/records003/run.sh view
@@ -0,0 +1,4 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ records003.idr -o records003+./records003+rm -f records003 *.ibc
− test/records004/expected 
@@ -1,3 +0,0 @@-"Fred"-"Joe"-"Bloggs"
+ test/records004/expected.out view
@@ -0,0 +1,3 @@+"Fred"+"Joe"+"Bloggs"
− test/records004/run 
@@ -1,4 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ records004.idr -o records004-./records004-rm -f records004 *.ibc
+ test/records004/run.sh view
@@ -0,0 +1,4 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ records004.idr -o records004+./records004+rm -f records004 *.ibc
− test/records005/expected 
@@ -1,4 +0,0 @@-1/2-Difficulty: 12-0/0-Difficulty: 12
+ test/records005/expected.out view
@@ -0,0 +1,4 @@+1/2+Difficulty: 12+0/0+Difficulty: 12
− test/records005/run 
@@ -1,4 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ records005.idr -o records005-./records005-rm -f records005 *.ibc
+ test/records005/run.sh view
@@ -0,0 +1,4 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ records005.idr -o records005+./records005+rm -f records005 *.ibc
− test/reg001/expected 
@@ -1,3 +0,0 @@-6-3-3.141592653589793
+ test/reg001/expected.out view
@@ -0,0 +1,3 @@+6+3+3.141592653589793
− test/reg001/run 
@@ -1,4 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ Area.idr -o reg001-./reg001-rm -f reg001 *.ibc
+ test/reg001/run.sh view
@@ -0,0 +1,4 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ Area.idr -o reg001+./reg001+rm -f reg001 *.ibc
− test/reg002/expected 
@@ -1,1 +0,0 @@-[2, 1, 4, 3, 5]
+ test/reg002/expected.out view
@@ -0,0 +1,1 @@+[2, 1, 4, 3, 5]
− test/reg002/run 
@@ -1,4 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ reg012.idr -o reg012-./reg012-rm -f reg012 *.ibc
+ test/reg002/run.sh view
@@ -0,0 +1,4 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ reg012.idr -o reg012+./reg012+rm -f reg012 *.ibc
− test/reg004/expected 
@@ -1,2 +0,0 @@-0-1
+ test/reg004/expected.out view
@@ -0,0 +1,2 @@+0+1
− test/reg004/run 
@@ -1,4 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ reg004.idr -o reg004-./reg004-rm -f reg004 *.ibc
+ test/reg004/run.sh view
@@ -0,0 +1,4 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ reg004.idr -o reg004+./reg004+rm -f reg004 *.ibc
− test/reg005/expected 
@@ -1,3 +0,0 @@-hey-you-[(), ()]
+ test/reg005/expected.out view
@@ -0,0 +1,3 @@+hey+you+[(), ()]
− test/reg005/run 
@@ -1,4 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ reg005.idr -o reg005-./reg005-rm -f reg005 *.ibc
+ test/reg005/run.sh view
@@ -0,0 +1,4 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ reg005.idr -o reg005+./reg005+rm -f reg005 *.ibc
− test/reg007/expected 
@@ -1,14 +0,0 @@-reg007.lidr:8:1:A.n is already defined-reg007.lidr:12:11-17:When checking right hand side of hurrah with expected type-        0 = 1--Type mismatch between-        n = lala (Type of isSame)-and-        0 = 1 (Expected type)--Specifically:-        Type mismatch between-                1-        and-                0
+ test/reg007/expected.out view
@@ -0,0 +1,14 @@+reg007.lidr:8:1:A.n is already defined+reg007.lidr:12:11-17:When checking right hand side of hurrah with expected type+        0 = 1++Type mismatch between+        n = lala (Type of isSame)+and+        0 = 1 (Expected type)++Specifically:+        Type mismatch between+                1+        and+                0
− test/reg007/run 
@@ -1,3 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ --nocolour --check reg007.lidr-rm -f *.ibc
+ test/reg007/run.sh view
@@ -0,0 +1,3 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ --nocolour --check reg007.lidr+rm -f *.ibc
− test/reg013/expected 
@@ -1,3 +0,0 @@-5-1-0
+ test/reg013/expected.out view
@@ -0,0 +1,3 @@+5+1+0
− test/reg013/run 
@@ -1,4 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ reg013.idr -o reg013-./reg013-rm -f reg013 *.ibc
+ test/reg013/run.sh view
@@ -0,0 +1,4 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ reg013.idr -o reg013+./reg013+rm -f reg013 *.ibc
− test/reg016/expected 
@@ -1,1 +0,0 @@-429496729500000000000000
+ test/reg016/expected.out view
@@ -0,0 +1,1 @@+429496729500000000000000
− test/reg016/run 
@@ -1,4 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ reg016.idr -o reg016-./reg016-rm -f reg016 *.ibc
+ test/reg016/run.sh view
@@ -0,0 +1,4 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ reg016.idr -o reg016+./reg016+rm -f reg016 *.ibc
− test/reg017/expected 
@@ -1,13 +0,0 @@-reg017.idr:5:17-23:-  |-5 |       { default tactics { refine Refl; solve; } prfA : a = a } ->-  |                 ~~~~~~~-This style of tactic proof is deprecated. See %runElab for the replacement.--reg017.idr:8:17-23:-  |-8 |       { default tactics { refine Refl; solve; } prfBC : b = c } ->-  |                 ~~~~~~~-This style of tactic proof is deprecated. See %runElab for the replacement.--4
+ test/reg017/expected.out view
@@ -0,0 +1,13 @@+reg017.idr:5:17-23:+  |+5 |       { default tactics { refine Refl; solve; } prfA : a = a } ->+  |                 ~~~~~~~+This style of tactic proof is deprecated. See %runElab for the replacement.++reg017.idr:8:17-23:+  |+8 |       { default tactics { refine Refl; solve; } prfBC : b = c } ->+  |                 ~~~~~~~+This style of tactic proof is deprecated. See %runElab for the replacement.++4
− test/reg017/run 
@@ -1,4 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ --nocolour reg017.idr -o reg017-./reg017-rm -f reg017 *.ibc
+ test/reg017/run.sh view
@@ -0,0 +1,4 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ --nocolour reg017.idr -o reg017+./reg017+rm -f reg017 *.ibc
− test/reg020/expected 
@@ -1,7 +0,0 @@-length of: '' is: 0-length of: 'hello world!' is: 12-length of: ' ' is: 1-length of: '	' is: 1-length of: '-' is: 1-length of all matches sum of all lengths: True
+ test/reg020/expected.out view
@@ -0,0 +1,7 @@+length of: '' is: 0+length of: 'hello world!' is: 12+length of: ' ' is: 1+length of: '	' is: 1+length of: '+' is: 1+length of all matches sum of all lengths: True
− test/reg020/run 
@@ -1,4 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ reg020.idr -o reg020-./reg020-rm -f reg020 *.ibc
+ test/reg020/run.sh view
@@ -0,0 +1,4 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ reg020.idr -o reg020+./reg020+rm -f reg020 *.ibc
− test/reg024/expected 
@@ -1,1 +0,0 @@-The answer is 42
+ test/reg024/expected.out view
@@ -0,0 +1,1 @@+The answer is 42
− test/reg024/run 
@@ -1,4 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ reg024.idr -o reg024-./reg024-rm -f reg024 *.ibc
+ test/reg024/run.sh view
@@ -0,0 +1,4 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ reg024.idr -o reg024+./reg024+rm -f reg024 *.ibc
− test/reg025/expected 
@@ -1,1 +0,0 @@-l
+ test/reg025/expected.out view
@@ -0,0 +1,1 @@+l
− test/reg025/run 
@@ -1,4 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ reg025.idr -o reg025-./reg025-rm -f reg025 *.ibc
+ test/reg025/run.sh view
@@ -0,0 +1,4 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ reg025.idr -o reg025+./reg025+rm -f reg025 *.ibc
− test/reg027/expected 
@@ -1,7 +0,0 @@-<<int fn>>-reg027a.idr:9:16-30:-  |-9 | implementation Show (Int -> b) where-  |                ~~~~~~~~~~~~~~~-Overlapping implementation: Show (Int -> a) already defined-
+ test/reg027/expected.out view
@@ -0,0 +1,7 @@+<<int fn>>+reg027a.idr:9:16-30:+  |+9 | implementation Show (Int -> b) where+  |                ~~~~~~~~~~~~~~~+Overlapping implementation: Show (Int -> a) already defined+
− test/reg027/run 
@@ -1,5 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ reg027.idr -o reg027-./reg027-${IDRIS:-idris} $@ reg027a.idr --check-rm -f reg027 *.ibc
+ test/reg027/run.sh view
@@ -0,0 +1,5 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ reg027.idr -o reg027+./reg027+${IDRIS:-idris} $@ reg027a.idr --check+rm -f reg027 *.ibc
− test/reg029/Reg029Wrapper.java 
@@ -1,17 +0,0 @@-import java.util.Map;--/**- * The Java back end uses properties- * instead of environment variables.- * This wrapper loads the env variables- * into the standard set of properties.- */-public class Reg029Wrapper {-  public static void main(String args[]) {-    Map<String, String> env = System.getenv();-    for (String key : env.keySet()) {-      System.setProperty(key, env.get(key));-    }-    reg029.main(args);-  }-}
− test/reg029/expected 
@@ -1,4 +0,0 @@-Nothing-Just "exists!"-Nothing-Just "exists!"
+ test/reg029/expected.out view
@@ -0,0 +1,4 @@+Nothing+Just "exists!"+Nothing+Just "exists!"
− test/reg029/run 
@@ -1,17 +0,0 @@-#!/usr/bin/env bash--${IDRIS:-idris} $@ reg029.idr -o reg029-unset IDRIS_REG029_NONEXISTENT_VAR-export IDRIS_REG029_EXISTENT_VAR='exists!'--IsJava=`echo "$@" | grep -E "\-\-codegen([[:space:]]+)Java\>"`-if [ -z "$IsJava" ]-then-  ./reg029-else-  javac -cp reg029:. Reg029Wrapper.java-  java -cp reg029:. Reg029Wrapper-fi-${IDRIS:-idris} $@ reg029.idr --execute-rm -f reg029 *.ibc *.class-
+ test/reg029/run.sh view
@@ -0,0 +1,17 @@+#!/usr/bin/env bash++${IDRIS:-idris} $@ reg029.idr -o reg029+unset IDRIS_REG029_NONEXISTENT_VAR+export IDRIS_REG029_EXISTENT_VAR='exists!'++IsJava=`echo "$@" | grep -E "\-\-codegen([[:space:]]+)Java\>"`+if [ -z "$IsJava" ]+then+  ./reg029+else+  javac -cp reg029:. Reg029Wrapper.java+  java -cp reg029:. Reg029Wrapper+fi+${IDRIS:-idris} $@ reg029.idr --execute+rm -f reg029 *.ibc *.class+
− test/reg031/expected 
@@ -1,1 +0,0 @@-[10, 128, 201, 255, 10, 51, 10, 52]
+ test/reg031/expected.out view
@@ -0,0 +1,1 @@+[10, 128, 201, 255, 10, 51, 10, 52]
− test/reg031/run 
@@ -1,4 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ reg031.idr -o reg031-./reg031-rm -f *.ibc reg031
+ test/reg031/run.sh view
@@ -0,0 +1,4 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ reg031.idr -o reg031+./reg031+rm -f *.ibc reg031
− test/reg032/expected 
@@ -1,1 +0,0 @@-hello, world!
+ test/reg032/expected.out view
@@ -0,0 +1,1 @@+hello, world!
− test/reg032/run 
@@ -1,4 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ test028.idr -o test028-./test028-rm -f test028 test028.ibc
+ test/reg032/run.sh view
@@ -0,0 +1,4 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ test028.idr -o test028+./test028+rm -f test028 test028.ibc
− test/reg039/expected 
@@ -1,1 +0,0 @@-[3, 2, 1]
+ test/reg039/expected.out view
@@ -0,0 +1,1 @@+[3, 2, 1]
− test/reg039/run 
@@ -1,8 +0,0 @@-#!/usr/bin/env bash--set -eu--TIMEOUT=../scripts/timeout--$TIMEOUT 60 "${IDRIS:-idris}" "$@" --nocolour reg039.idr --exec go-rm -f *.ibc
+ test/reg039/run.sh view
@@ -0,0 +1,8 @@+#!/usr/bin/env bash++set -eu++TIMEOUT=../scripts/timeout++$TIMEOUT 60 "${IDRIS:-idris}" "$@" --nocolour reg039.idr --exec go+rm -f *.ibc
− test/reg040/expected 
@@ -1,1 +0,0 @@-42
+ test/reg040/expected.out view
@@ -0,0 +1,1 @@+42
− test/reg040/run 
@@ -1,6 +0,0 @@-#!/usr/bin/env bash--${IDRIS:-idris} $@ --warnreach reg040.idr -o reg040-./reg040--rm -f reg040 *.ibc
+ test/reg040/run.sh view
@@ -0,0 +1,6 @@+#!/usr/bin/env bash++${IDRIS:-idris} $@ --warnreach reg040.idr -o reg040+./reg040++rm -f reg040 *.ibc
− test/reg041/expected 
@@ -1,2 +0,0 @@-?prf : (x : Bool) -> (x1 : Bool) -> El (EQ Two x Two x1) -> El (EQ Two x Two x1)-Z
+ test/reg041/expected.out view
@@ -0,0 +1,2 @@+?prf : (x : Bool) -> (x1 : Bool) -> El (EQ Two x Two x1) -> El (EQ Two x Two x1)+Z
− test/reg041/run 
@@ -1,5 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ --quiet --port none ott.idr -e example-${IDRIS:-idris} $@ showu.idr -o reg040-./reg040-rm -f reg040 *.ibc
+ test/reg041/run.sh view
@@ -0,0 +1,5 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ --quiet --port none ott.idr -e example+${IDRIS:-idris} $@ showu.idr -o reg040+./reg040+rm -f reg040 *.ibc
− test/reg042/expected 
@@ -1,1 +0,0 @@-7
+ test/reg042/expected.out view
@@ -0,0 +1,1 @@+7
− test/reg042/run 
@@ -1,4 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ reg042 -o reg042 --warnreach-./reg042-rm -f reg042 *.ibc
+ test/reg042/run.sh view
@@ -0,0 +1,4 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ reg042 -o reg042 --warnreach+./reg042+rm -f reg042 *.ibc
− test/reg045/expected 
@@ -1,1 +0,0 @@-[1, 2, 3]
+ test/reg045/expected.out view
@@ -0,0 +1,1 @@+[1, 2, 3]
− test/reg045/run 
@@ -1,4 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ reg045.idr -o reg045-./reg045-rm -f reg045 *.ibc
+ test/reg045/run.sh view
@@ -0,0 +1,4 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ reg045.idr -o reg045+./reg045+rm -f reg045 *.ibc
− test/reg048/expected 
+ test/reg048/expected.out view
− test/reg048/run 
@@ -1,4 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ reg048.idr -p contrib -o reg048-./reg048-rm -f reg048 *.ibc
+ test/reg048/run.sh view
@@ -0,0 +1,4 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ reg048.idr -p contrib -o reg048+./reg048+rm -f reg048 *.ibc
− test/reg051-disabled/expected 
+ test/reg051-disabled/expected.out view
− test/reg051-disabled/run 
@@ -1,3 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ reg051.idr --check-rm -f *.ibc
+ test/reg051-disabled/run.sh view
@@ -0,0 +1,3 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ reg051.idr --check+rm -f *.ibc
− test/reg052/expected 
@@ -1,1 +0,0 @@-000000000000002A
+ test/reg052/expected.out view
@@ -0,0 +1,1 @@+000000000000002A
− test/reg052/run 
@@ -1,4 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ -o reg052 reg052.idr-./reg052-rm -f reg052 *.ibc
+ test/reg052/run.sh view
@@ -0,0 +1,4 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ -o reg052 reg052.idr+./reg052+rm -f reg052 *.ibc
− test/reg067/expected 
@@ -1,1 +0,0 @@-tst2["as"]
+ test/reg067/expected.out view
@@ -0,0 +1,1 @@+tst2["as"]
− test/reg067/run 
@@ -1,5 +0,0 @@-#!/usr/bin/env bash-rm -f *.ibc reg067-${IDRIS:-idris} $@ reg067.idr -o reg067 --warnreach-./reg067-rm -f *.ibc reg067
+ test/reg067/run.sh view
@@ -0,0 +1,5 @@+#!/usr/bin/env bash+rm -f *.ibc reg067+${IDRIS:-idris} $@ reg067.idr -o reg067 --warnreach+./reg067+rm -f *.ibc reg067
− test/reg075/expected 
@@ -1,6 +0,0 @@-data Foo : Bar m BMODEL -> Model ty -> FTy -> Type where-  FElem : (name : String) -> Foo p (MElem name) FELEM-  FLink : Foo p x FELEM ->-          (c : Common) ->-          (f : Bar g BELEM) ->-          {auto prf : isValid f p = Yes prf'} -> Foo p (MLink c x g) FLINK
+ test/reg075/expected.out view
@@ -0,0 +1,6 @@+data Foo : Bar m BMODEL -> Model ty -> FTy -> Type where+  FElem : (name : String) -> Foo p (MElem name) FELEM+  FLink : Foo p x FELEM ->+          (c : Common) ->+          (f : Bar g BELEM) ->+          {auto prf : isValid f p = Yes prf'} -> Foo p (MLink c x g) FLINK
− test/reg075/input 
@@ -1,1 +0,0 @@-:printdef Foo
+ test/reg075/input.in view
@@ -0,0 +1,1 @@+:printdef Foo
− test/reg075/run 
@@ -1,3 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ --quiet --port none reg075.idr < input-rm -f *.ibc
+ test/reg075/run.sh view
@@ -0,0 +1,3 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ --quiet --port none reg075.idr < input.in+rm -f *.ibc
− test/reg076/expected 
@@ -1,1 +0,0 @@-3
+ test/reg076/expected.out view
@@ -0,0 +1,1 @@+3
− test/reg076/input 
+ test/reg076/input.in view
− test/reg076/run 
@@ -1,4 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ --port none reg076.idr -o reg076-./reg076-rm -f *.ibc reg076
+ test/reg076/run.sh view
@@ -0,0 +1,4 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ --port none reg076.idr -o reg076+./reg076+rm -f *.ibc reg076
− test/reg077/expected 
+ test/reg077/expected.out view
− test/reg077/run 
@@ -1,3 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ --check reg077.idr-rm -f reg077 *.ibc
+ test/reg077/run.sh view
@@ -0,0 +1,3 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ --check reg077.idr+rm -f reg077 *.ibc
− test/regression001/expected 
+ test/regression001/expected.out view
− test/regression001/run 
@@ -1,18 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ --check \-    reg001.idr reg002.idr reg003.idr reg004.lidr reg005.idr \-    reg006.idr reg007.idr reg036.idr reg037.idr reg038.idr reg046.idr \-    reg047a.idr reg053.idr reg057.idr reg058.idr reg058a.idr \-    reg059.idr reg060.idr  reg061.idr reg062.idr reg063.idr \-    reg064.idr reg065.idr  reg066.idr reg071.idr reg074.idr \-    coverage001.idr--${IDRIS:-idris} $@ --check \-    eff001.idr -p effects--${IDRIS:-idris} $@ --check --nobuiltins reg047.idr--${IDRIS:-idris} $@ --check --nocolour \-     reg073.lidr--rm -f *.ibc
+ test/regression001/run.sh view
@@ -0,0 +1,18 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ --check \+    reg001.idr reg002.idr reg003.idr reg004.lidr reg005.idr \+    reg006.idr reg007.idr reg036.idr reg037.idr reg038.idr reg046.idr \+    reg047a.idr reg053.idr reg057.idr reg058.idr reg058a.idr \+    reg059.idr reg060.idr  reg061.idr reg062.idr reg063.idr \+    reg064.idr reg065.idr  reg066.idr reg071.idr reg074.idr \+    coverage001.idr++${IDRIS:-idris} $@ --check \+    eff001.idr -p effects++${IDRIS:-idris} $@ --check --nobuiltins reg047.idr++${IDRIS:-idris} $@ --check --nocolour \+     reg073.lidr++rm -f *.ibc
− test/regression002/expected 
@@ -1,368 +0,0 @@-reg001.idr:2:1-9:-  |-2 | foo a a x = x-  | ~~~~~~~~~-When checking left hand side of foo:-Can't match on foo a a x--reg002.idr:3:1-19:-  |-3 | append (X :: XS) ys = X :: append XS ys-  | ~~~~~~~~~~~~~~~~~~~-When checking left hand side of append:-When checking argument x to constructor Prelude.List.:::-        X is not a valid name for a pattern variable--reg003a.idr:4:13-38:-  |-4 |     ECons : Nat -> OddList -> EvenList-  |             ~~~~~~~~~~~~~~~~~~~~~~~~~~-When checking type of Main.ECons:-No such variable OddList--reg003a.idr:7:13-38:-  |-7 |     OCons : Nat -> EvenList -> OddList-  |             ~~~~~~~~~~~~~~~~~~~~~~~~~~-When checking type of Main.OCons:-No such variable EvenList--reg003a.idr:9:6:-  |-9 | test : EvenList-  |      ^-When checking type of Main.test:-No such variable EvenList--reg006.idr:17:1-23:-   |-17 | lookup k Leaf = Nothing-   | ~~~~~~~~~~~~~~~~~~~~~~~-RBTree.lookup is possibly not total due to recursive path RBTree.lookup --> RBTree.lookup--reg007.lidr:8:3-13:-  |-8 | > A.n     = Z    -- This is where it's at!-  |   ~~~~~~~~~~~-A.n is already defined--reg007.lidr:12:13-18:-   |-12 | > hurrah  = isSame-   |             ~~~~~~-When checking right hand side of hurrah with expected type-        0 = 1--Type mismatch between-        n = lala (Type of isSame)-and-        0 = 1 (Expected type)--Specifically:-        Type mismatch between-                1-        and-                0--reg010.idr:5:3-26:-  |-5 |   unsafeSubst P x x px | _ = px-  |   ~~~~~~~~~~~~~~~~~~~~~~~~-When checking left hand side of with block in usubst.unsafeSubst:-Can't match on with block in usubst.unsafeSubst warg a P x x px--reg018a.idr:16:1-18:-   |-16 | minusCoNat Z n = Z-   | ~~~~~~~~~~~~~~~~~~-conat.minusCoNat is possibly not total due to recursive path conat.minusCoNat --> conat.minusCoNat--reg018a.idr:21:1-42:-   |-21 | loopForever = minusCoNat infinity infinity-   | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~-conat.loopForever is possibly not total due to: conat.minusCoNat--reg018b.idr:8:1-28:-  |-8 | showB (I x) = "I" ++ showB x-  | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~-A.showB is possibly not total due to recursive path A.showB --> A.showB--reg018b.idr:11:1-6:-   |-11 | Show B where show = showB-   | ~~~~~~-A.B implementation of Prelude.Show.Show is possibly not total due to: A.showB--reg018c.idr:21:1-22:21:-   |-21 | inf (x :: xs) with (hdtl xs)-   | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ...-CodataTest.inf is possibly not total due to: with block in CodataTest.inf--reg018d.idr:8:1-39:-  |-8 | pull {n=Z}   _      (x :: xs) = (x, xs)-  | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~-Main.pull is not total as there are missing cases--reg023.idr:7:7:-  |-7 | bad = Z-  |       ^-When checking right hand side of bad with expected type-        f Nat--Type mismatch between-        Nat (Type of 0)-and-        f Nat (Expected type)--reg028.idr:5:1-9:-  |-5 | bad Z = Z-  | ~~~~~~~~~-tbad.bad is possibly not total due to: with block in tbad.bad--reg028a.idr:17:14-18:-   |-17 | qsortLemma = proof-   |              ~~~~~-This style of tactic proof is deprecated. See %runElab for the replacement.--reg028a.idr:11:1-14:-   |-11 | qsort' [] = []-   | ~~~~~~~~~~~~~~-tbad.qsort' is possibly not total due to: with block in tbad.qsort'--reg034.idr:6:1-14:-  |-6 | bar xs xs Refl = Refl-  | ~~~~~~~~~~~~~~-When checking left hand side of bar:-Can't match on bar xs xs Refl--reg034.idr:9:1-14:-  |-9 | foo f x x Refl = Refl-  | ~~~~~~~~~~~~~~-When checking left hand side of foo:-Can't match on foo f x x Refl--reg035b.idr:8:14-38:-  |-8 | fins Z     = ([] ** (finZEmpty {a=_}))-  |              ~~~~~~~~~~~~~~~~~~~~~~~~~-No such variable __pi_arg--reg044.idr:4:6-10:-  |-4 | pf = proof-  |      ~~~~~-This style of tactic proof is deprecated. See %runElab for the replacement.--reg044.idr:4:6-6:13:-  |-4 | pf = proof-  |      ~~~~~ ...-When checking right hand side of Main.pf with expected type-        (b : Nat) -> (a : Nat) -> (S a = S b) -> a = b--Type mismatch between-        b = b (Type of Refl)-and-        a = b (Expected type)--Specifically:-        Type mismatch between-                b-        and-                a--reg049.idr:2:11-14:-  |-2 |   Bogus : Void-  |           ~~~~-When checking constructor Main.Bogus:-Void is not Main.Foo--reg049.idr:5:8-12:-  |-5 | uhOh = Bogus-  |        ~~~~~-When checking right hand side of uhOh with expected type-        Void--No such variable Bogus--badbangop.idr:7:1:-  |-7 | (!) : List a -> Nat -> Maybe a-  | ^-! is not a valid operator--baddoublebang.idr:6:28:-  |-6 | doubleBang mmn = do pure !!mmn-  |                            ^-unexpected Operator without known fixity: !!--reg054.idr:18:1-17:-   |-18 | inf (MkInfer _ Z) = True-   | ~~~~~~~~~~~~~~~~~-When checking left hand side of inf:-When checking an application of constructor Main.MkInfer:-        Attempting concrete match on polymorphic argument: 0--reg054.idr:34:1-18:-   |-34 | weird {x = Char} y = '5'-   | ~~~~~~~~~~~~~~~~~~-When checking left hand side of weird:-No explicit types on left hand side: Char--reg054.idr:37:1-30:-   |-37 | weird' {x = Prelude.Nat.Nat} y = Z-   | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~-When checking left hand side of weird':-No explicit types on left hand side: Nat--reg054.idr:40:1-7:-   |-40 | tctrick (Just x) = x-   | ~~~~~~~-When checking left hand side of tctrick:-When checking an application of Main.tctrick:-        Type mismatch between-                Maybe a1 (Type of Just x)-        and-                a (Expected type)--reg055.idr:5:1-7:-  |-5 | g (f Z) = 1    -  | ~~~~~~~-When checking left hand side of g:-Can't match on g (f 0)--reg055.idr:8:1-5:-  |-8 | h x x = x-  | ~~~~~-When checking left hand side of h:-Can't match on h x x--reg055a.idr:8:1-18:-  |-8 | foo (CAny Nothing) = 42 -  | ~~~~~~~~~~~~~~~~~~-When checking left hand side of foo:-When checking an application of constructor Foo.CAny:-        Attempting concrete match on polymorphic argument: Nothing--reg055a.idr:13:1-23:-   |-13 | apply (\x => \y => x) a = a-   | ~~~~~~~~~~~~~~~~~~~~~~~-When checking left hand side of Foo.apply:-Can't match on apply (\x, y => x) a--reg056.idr:7:16-25:-  |-7 | dodgy n m Refl impossible-  |                ~~~~~~~~~~-dodgy n m Refl is a valid case--reg056.idr:10:11-20:-   |-10 | nonk Refl impossible-   |           ~~~~~~~~~~-nonk Refl is a valid case--reg068.idr:1:6-8:-  |-1 | data nat : Type where --error-  |      ~~~-Main.nat has a name which may be implicitly bound.-This is likely to lead to problems!--reg068.idr:2:8-10:-  |-2 |   ze : nat --hello.idr:10:6:When checking constructor Main.ze: !!V 0!! is not Main.nat-  |        ~~~-Main.ze has a name which may be implicitly bound.-This is likely to lead to problems!--reg068.idr:2:8-10:-  |-2 |   ze : nat --hello.idr:10:6:When checking constructor Main.ze: !!V 0!! is not Main.nat-  |        ~~~-nat is bound as an implicit-	Did you mean to refer to Main.nat?--reg068.idr:2:8-10:-  |-2 |   ze : nat --hello.idr:10:6:When checking constructor Main.ze: !!V 0!! is not Main.nat-  |        ~~~-When checking constructor Main.ze:-Type level variable nat is not Main.nat--Mod.idr:11:1-22:-   |-11 | natexp k = S (natfn k)-   | ~~~~~~~~~~~~~~~~~~~~~~-public export Mod.natexp can't refer to export Mod.natfn--reg070.idr:7:1-7:-  |-7 | Show Te where-  | ~~~~~~~-Test_show.Te implementation of Prelude.Show.Show is possibly not total due to: Prelude.Show.Test_show.Te implementation of Prelude.Show.Show, method show--reg076.idr:8:1:-  |-8 | <end of file>-  | ^-Missing fixity declaration for Main.:>--reg077.idr:3:1:-  |-3 | <end of file>-  | ^-Missing fixity declaration for Main.:>>--DoubleEquality.idr:4:83-103:-  |-4 | oops = the ((False = True) -> Void) (\Refl impossible) $ cong {f = (>0) . (1/)} $ the (-0.0 = 0.0) Refl-  |                                                                                   ~~~~~~~~~~~~~~~~~~~~~-When checking right hand side of oops with expected type-        Void--When checking argument value to function Prelude.Basics.the:-        Type mismatch between-                x = x (Type of Refl)-        and-                -0.0 = 0.0 (Expected type)-        -        Specifically:-                Type mismatch between-                        -0.0-                and-                        0.0--Canonicity.idr:9:1-9:-  |-9 | f Nil = 0-  | ~~~~~~~~~-Canonicity.f is not total as there are missing cases--Canonicity.idr:12:1-20:-   |-12 | NaN = f (Cons 0 Nil)-   | ~~~~~~~~~~~~~~~~~~~~-Canonicity.NaN is possibly not total due to: Canonicity.f-
+ test/regression002/expected.out view
@@ -0,0 +1,368 @@+reg001.idr:2:1-9:+  |+2 | foo a a x = x+  | ~~~~~~~~~+When checking left hand side of foo:+Can't match on foo a a x++reg002.idr:3:1-19:+  |+3 | append (X :: XS) ys = X :: append XS ys+  | ~~~~~~~~~~~~~~~~~~~+When checking left hand side of append:+When checking argument x to constructor Prelude.List.:::+        X is not a valid name for a pattern variable++reg003a.idr:4:13-38:+  |+4 |     ECons : Nat -> OddList -> EvenList+  |             ~~~~~~~~~~~~~~~~~~~~~~~~~~+When checking type of Main.ECons:+No such variable OddList++reg003a.idr:7:13-38:+  |+7 |     OCons : Nat -> EvenList -> OddList+  |             ~~~~~~~~~~~~~~~~~~~~~~~~~~+When checking type of Main.OCons:+No such variable EvenList++reg003a.idr:9:6:+  |+9 | test : EvenList+  |      ^+When checking type of Main.test:+No such variable EvenList++reg006.idr:17:1-23:+   |+17 | lookup k Leaf = Nothing+   | ~~~~~~~~~~~~~~~~~~~~~~~+RBTree.lookup is possibly not total due to recursive path RBTree.lookup --> RBTree.lookup++reg007.lidr:8:3-13:+  |+8 | > A.n     = Z    -- This is where it's at!+  |   ~~~~~~~~~~~+A.n is already defined++reg007.lidr:12:13-18:+   |+12 | > hurrah  = isSame+   |             ~~~~~~+When checking right hand side of hurrah with expected type+        0 = 1++Type mismatch between+        n = lala (Type of isSame)+and+        0 = 1 (Expected type)++Specifically:+        Type mismatch between+                1+        and+                0++reg010.idr:5:3-26:+  |+5 |   unsafeSubst P x x px | _ = px+  |   ~~~~~~~~~~~~~~~~~~~~~~~~+When checking left hand side of with block in usubst.unsafeSubst:+Can't match on with block in usubst.unsafeSubst warg a P x x px++reg018a.idr:16:1-18:+   |+16 | minusCoNat Z n = Z+   | ~~~~~~~~~~~~~~~~~~+conat.minusCoNat is possibly not total due to recursive path conat.minusCoNat --> conat.minusCoNat++reg018a.idr:21:1-42:+   |+21 | loopForever = minusCoNat infinity infinity+   | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+conat.loopForever is possibly not total due to: conat.minusCoNat++reg018b.idr:8:1-28:+  |+8 | showB (I x) = "I" ++ showB x+  | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~+A.showB is possibly not total due to recursive path A.showB --> A.showB++reg018b.idr:11:1-6:+   |+11 | Show B where show = showB+   | ~~~~~~+A.B implementation of Prelude.Show.Show is possibly not total due to: A.showB++reg018c.idr:21:1-22:21:+   |+21 | inf (x :: xs) with (hdtl xs)+   | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ...+CodataTest.inf is possibly not total due to: with block in CodataTest.inf++reg018d.idr:8:1-39:+  |+8 | pull {n=Z}   _      (x :: xs) = (x, xs)+  | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+Main.pull is not total as there are missing cases++reg023.idr:7:7:+  |+7 | bad = Z+  |       ^+When checking right hand side of bad with expected type+        f Nat++Type mismatch between+        Nat (Type of 0)+and+        f Nat (Expected type)++reg028.idr:5:1-9:+  |+5 | bad Z = Z+  | ~~~~~~~~~+tbad.bad is possibly not total due to: with block in tbad.bad++reg028a.idr:17:14-18:+   |+17 | qsortLemma = proof+   |              ~~~~~+This style of tactic proof is deprecated. See %runElab for the replacement.++reg028a.idr:11:1-14:+   |+11 | qsort' [] = []+   | ~~~~~~~~~~~~~~+tbad.qsort' is possibly not total due to: with block in tbad.qsort'++reg034.idr:6:1-14:+  |+6 | bar xs xs Refl = Refl+  | ~~~~~~~~~~~~~~+When checking left hand side of bar:+Can't match on bar xs xs Refl++reg034.idr:9:1-14:+  |+9 | foo f x x Refl = Refl+  | ~~~~~~~~~~~~~~+When checking left hand side of foo:+Can't match on foo f x x Refl++reg035b.idr:8:14-38:+  |+8 | fins Z     = ([] ** (finZEmpty {a=_}))+  |              ~~~~~~~~~~~~~~~~~~~~~~~~~+No such variable __pi_arg++reg044.idr:4:6-10:+  |+4 | pf = proof+  |      ~~~~~+This style of tactic proof is deprecated. See %runElab for the replacement.++reg044.idr:4:6-6:13:+  |+4 | pf = proof+  |      ~~~~~ ...+When checking right hand side of Main.pf with expected type+        (b : Nat) -> (a : Nat) -> (S a = S b) -> a = b++Type mismatch between+        b = b (Type of Refl)+and+        a = b (Expected type)++Specifically:+        Type mismatch between+                b+        and+                a++reg049.idr:2:11-14:+  |+2 |   Bogus : Void+  |           ~~~~+When checking constructor Main.Bogus:+Void is not Main.Foo++reg049.idr:5:8-12:+  |+5 | uhOh = Bogus+  |        ~~~~~+When checking right hand side of uhOh with expected type+        Void++No such variable Bogus++badbangop.idr:7:1:+  |+7 | (!) : List a -> Nat -> Maybe a+  | ^+! is not a valid operator++baddoublebang.idr:6:28:+  |+6 | doubleBang mmn = do pure !!mmn+  |                            ^+unexpected Operator without known fixity: !!++reg054.idr:18:1-17:+   |+18 | inf (MkInfer _ Z) = True+   | ~~~~~~~~~~~~~~~~~+When checking left hand side of inf:+When checking an application of constructor Main.MkInfer:+        Attempting concrete match on polymorphic argument: 0++reg054.idr:34:1-18:+   |+34 | weird {x = Char} y = '5'+   | ~~~~~~~~~~~~~~~~~~+When checking left hand side of weird:+No explicit types on left hand side: Char++reg054.idr:37:1-30:+   |+37 | weird' {x = Prelude.Nat.Nat} y = Z+   | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+When checking left hand side of weird':+No explicit types on left hand side: Nat++reg054.idr:40:1-7:+   |+40 | tctrick (Just x) = x+   | ~~~~~~~+When checking left hand side of tctrick:+When checking an application of Main.tctrick:+        Type mismatch between+                Maybe a1 (Type of Just x)+        and+                a (Expected type)++reg055.idr:5:1-7:+  |+5 | g (f Z) = 1    +  | ~~~~~~~+When checking left hand side of g:+Can't match on g (f 0)++reg055.idr:8:1-5:+  |+8 | h x x = x+  | ~~~~~+When checking left hand side of h:+Can't match on h x x++reg055a.idr:8:1-18:+  |+8 | foo (CAny Nothing) = 42 +  | ~~~~~~~~~~~~~~~~~~+When checking left hand side of foo:+When checking an application of constructor Foo.CAny:+        Attempting concrete match on polymorphic argument: Nothing++reg055a.idr:13:1-23:+   |+13 | apply (\x => \y => x) a = a+   | ~~~~~~~~~~~~~~~~~~~~~~~+When checking left hand side of Foo.apply:+Can't match on apply (\x, y => x) a++reg056.idr:7:16-25:+  |+7 | dodgy n m Refl impossible+  |                ~~~~~~~~~~+dodgy n m Refl is a valid case++reg056.idr:10:11-20:+   |+10 | nonk Refl impossible+   |           ~~~~~~~~~~+nonk Refl is a valid case++reg068.idr:1:6-8:+  |+1 | data nat : Type where --error+  |      ~~~+Main.nat has a name which may be implicitly bound.+This is likely to lead to problems!++reg068.idr:2:8-10:+  |+2 |   ze : nat --hello.idr:10:6:When checking constructor Main.ze: !!V 0!! is not Main.nat+  |        ~~~+Main.ze has a name which may be implicitly bound.+This is likely to lead to problems!++reg068.idr:2:8-10:+  |+2 |   ze : nat --hello.idr:10:6:When checking constructor Main.ze: !!V 0!! is not Main.nat+  |        ~~~+nat is bound as an implicit+	Did you mean to refer to Main.nat?++reg068.idr:2:8-10:+  |+2 |   ze : nat --hello.idr:10:6:When checking constructor Main.ze: !!V 0!! is not Main.nat+  |        ~~~+When checking constructor Main.ze:+Type level variable nat is not Main.nat++Mod.idr:11:1-22:+   |+11 | natexp k = S (natfn k)+   | ~~~~~~~~~~~~~~~~~~~~~~+public export Mod.natexp can't refer to export Mod.natfn++reg070.idr:7:1-7:+  |+7 | Show Te where+  | ~~~~~~~+Test_show.Te implementation of Prelude.Show.Show is possibly not total due to: Prelude.Show.Test_show.Te implementation of Prelude.Show.Show, method show++reg076.idr:8:1:+  |+8 | <end of file>+  | ^+Missing fixity declaration for Main.:>++reg077.idr:3:1:+  |+3 | <end of file>+  | ^+Missing fixity declaration for Main.:>>++DoubleEquality.idr:4:83-103:+  |+4 | oops = the ((False = True) -> Void) (\Refl impossible) $ cong {f = (>0) . (1/)} $ the (-0.0 = 0.0) Refl+  |                                                                                   ~~~~~~~~~~~~~~~~~~~~~+When checking right hand side of oops with expected type+        Void++When checking argument value to function Prelude.Basics.the:+        Type mismatch between+                x = x (Type of Refl)+        and+                -0.0 = 0.0 (Expected type)+        +        Specifically:+                Type mismatch between+                        -0.0+                and+                        0.0++Canonicity.idr:9:1-9:+  |+9 | f Nil = 0+  | ~~~~~~~~~+Canonicity.f is not total as there are missing cases++Canonicity.idr:12:1-20:+   |+12 | NaN = f (Cons 0 Nil)+   | ~~~~~~~~~~~~~~~~~~~~+Canonicity.NaN is possibly not total due to: Canonicity.f+
− test/regression002/run 
@@ -1,41 +0,0 @@-#!/usr/bin/env bash--${IDRIS:-idris} $@ --nobanner --nocolour --quiet --port none <<!-:load reg001.idr-:load reg002.idr-:load reg003.idr-:load reg003a.idr-:load reg006.idr-:load reg007.lidr-:load reg010.idr-:load reg018a.idr-:load reg018b.idr-:load reg018c.idr-:load reg018d.idr-:load reg023.idr-:load reg028.idr-:load reg028a.idr-:load reg034.idr-:load reg035.idr-:load reg035a.lidr-:load reg035b.idr-:load reg044.idr-:load reg049.idr-:load working.idr-:load badbangop.idr-:load baddoublebang.idr-:load reg054.idr-:load reg055.idr-:load reg055a.idr-:load reg056.idr-:load reg068.idr-:load reg069.idr-:load reg070.idr-:load reg076.idr-:load reg077.idr-:load DoubleEquality.idr-:load Canonicity.idr-:load Negation.idr-!--rm -f *.ibc
+ test/regression002/run.sh view
@@ -0,0 +1,41 @@+#!/usr/bin/env bash++${IDRIS:-idris} $@ --nobanner --nocolour --quiet --port none <<!+:load reg001.idr+:load reg002.idr+:load reg003.idr+:load reg003a.idr+:load reg006.idr+:load reg007.lidr+:load reg010.idr+:load reg018a.idr+:load reg018b.idr+:load reg018c.idr+:load reg018d.idr+:load reg023.idr+:load reg028.idr+:load reg028a.idr+:load reg034.idr+:load reg035.idr+:load reg035a.lidr+:load reg035b.idr+:load reg044.idr+:load reg049.idr+:load working.idr+:load badbangop.idr+:load baddoublebang.idr+:load reg054.idr+:load reg055.idr+:load reg055a.idr+:load reg056.idr+:load reg068.idr+:load reg069.idr+:load reg070.idr+:load reg076.idr+:load reg077.idr+:load DoubleEquality.idr+:load Canonicity.idr+:load Negation.idr+!++rm -f *.ibc
− test/regression003/expected 
@@ -1,1 +0,0 @@-ola
+ test/regression003/expected.out view
@@ -0,0 +1,1 @@+ola
− test/regression003/run 
@@ -1,4 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ regression003.idr -o regression003-./regression003-rm -f regression003 *.ibc
+ test/regression003/run.sh view
@@ -0,0 +1,4 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ regression003.idr -o regression003+./regression003+rm -f regression003 *.ibc
− test/sourceLocation001/expected 
@@ -1,35 +0,0 @@-SourceLoc.idr:12:19-25:-   |-12 | getLoc : {default tactics { sourceLocation } x : SourceLocation} -> SourceLocation-   |                   ~~~~~~~-This style of tactic proof is deprecated. See %runElab for the replacement.--SourceLoc.idr:21:19-23:-   |-21 | fromProofScript = proof sourceLocation-   |                   ~~~~~-This style of tactic proof is deprecated. See %runElab for the replacement.--SourceLoc.idr:41:20-26:-   |-41 |     Die : {default tactics { sourceLocation } loc : SourceLocation} -> Tm ctxt t-   |                    ~~~~~~~-This style of tactic proof is deprecated. See %runElab for the replacement.--SourceLoc.idr:99:18-22:-   |-99 | SourceLoc.meta = proof-   |                  ~~~~~-This style of tactic proof is deprecated. See %runElab for the replacement.--Testing using definition-FileLoc "SourceLoc.idr" (17, 11) (17, 16)-Testing using inline tactics-FileLoc "SourceLoc.idr" (21, 19) (21, 38)-Testing using metavariable with later definition-FileLoc "SourceLoc.idr" (99, 18) (100, 16)-------------------------Success!-Error at FileLoc "SourceLoc.idr" (73, 23) (73, 25)-Success!-Success!
+ test/sourceLocation001/expected.out view
@@ -0,0 +1,35 @@+SourceLoc.idr:12:19-25:+   |+12 | getLoc : {default tactics { sourceLocation } x : SourceLocation} -> SourceLocation+   |                   ~~~~~~~+This style of tactic proof is deprecated. See %runElab for the replacement.++SourceLoc.idr:21:19-23:+   |+21 | fromProofScript = proof sourceLocation+   |                   ~~~~~+This style of tactic proof is deprecated. See %runElab for the replacement.++SourceLoc.idr:41:20-26:+   |+41 |     Die : {default tactics { sourceLocation } loc : SourceLocation} -> Tm ctxt t+   |                    ~~~~~~~+This style of tactic proof is deprecated. See %runElab for the replacement.++SourceLoc.idr:99:18-22:+   |+99 | SourceLoc.meta = proof+   |                  ~~~~~+This style of tactic proof is deprecated. See %runElab for the replacement.++Testing using definition+FileLoc "SourceLoc.idr" (17, 11) (17, 16)+Testing using inline tactics+FileLoc "SourceLoc.idr" (21, 19) (21, 38)+Testing using metavariable with later definition+FileLoc "SourceLoc.idr" (99, 18) (100, 16)+-----------------------+Success!+Error at FileLoc "SourceLoc.idr" (73, 23) (73, 25)+Success!+Success!
− test/sourceLocation001/run 
@@ -1,4 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ --nocolour SourceLoc.idr -o sourceLocation001-./sourceLocation001-rm -f sourceLocation001 *.ibc
+ test/sourceLocation001/run.sh view
@@ -0,0 +1,4 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ --nocolour SourceLoc.idr -o sourceLocation001+./sourceLocation001+rm -f sourceLocation001 *.ibc
− test/st001/expected 
@@ -1,8 +0,0 @@-# test001:---test IO:-["HELLO!!\n", "WORLD!!"]-2---test IOExcept:-["HELLO!!\n", "WORLD!!"]-2-()
+ test/st001/expected.out view
@@ -0,0 +1,8 @@+# test001:+--test IO:+["HELLO!!\n", "WORLD!!"]+2+--test IOExcept:+["HELLO!!\n", "WORLD!!"]+2+()
− test/st001/run 
@@ -1,6 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ -p contrib test001.idr -o test001-echo "# test001:"-./test001-rm -f test001 *.ibc-
+ test/st001/run.sh view
@@ -0,0 +1,6 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ -p contrib test001.idr -o test001+echo "# test001:"+./test001+rm -f test001 *.ibc+
test/st001/test001.idr view
@@ -40,7 +40,7 @@  testFile : (ConsoleIO m, File m) => ST m () [] testFile = with ST do -              Right fileHandle <- open "testFile" Read +              Right fileHandle <- open "testFile.in" Read                     | Left ferr => do putStrLn (show ferr)                                       pure ()               count <- new 0
− test/st001/testFile 
@@ -1,2 +0,0 @@-HELLO!!-WORLD!!
+ test/st001/testFile.in view
@@ -0,0 +1,2 @@+HELLO!!+WORLD!!
− test/st002/expected 
@@ -1,8 +0,0 @@-# test002:---test IO:-['H', 'E', 'L', 'L', 'O', '!', '!', '\n', 'W', 'O', 'R', 'L', 'D', '!', '!', '\NUL']-16---test IOExcept:-['H', 'E', 'L', 'L', 'O', '!', '!', '\n', 'W', 'O', 'R', 'L', 'D', '!', '!', '\NUL']-16-()
+ test/st002/expected.out view
@@ -0,0 +1,8 @@+# test002:+--test IO:+['H', 'E', 'L', 'L', 'O', '!', '!', '\n', 'W', 'O', 'R', 'L', 'D', '!', '!', '\NUL']+16+--test IOExcept:+['H', 'E', 'L', 'L', 'O', '!', '!', '\n', 'W', 'O', 'R', 'L', 'D', '!', '!', '\NUL']+16+()
− test/st002/run 
@@ -1,6 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ -p contrib test002.idr -o test002-echo "# test002:"-./test002-rm -f test002 *.ibc-
+ test/st002/run.sh view
@@ -0,0 +1,6 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ -p contrib test002.idr -o test002+echo "# test002:"+./test002+rm -f test002 *.ibc+
test/st002/test002.idr view
@@ -40,7 +40,7 @@  testFile : (ConsoleIO m, File m) => ST m () [] testFile = with ST do-              Right fileHandle <- open "testFile" Read +              Right fileHandle <- open "testFile.in" Read                     | Left ferr => do putStrLn (show ferr)                                       pure ()               count <- new 0
− test/st002/testFile 
@@ -1,2 +0,0 @@-HELLO!!-WORLD!!
+ test/st002/testFile.in view
@@ -0,0 +1,2 @@+HELLO!!+WORLD!!
− test/st003/expected 
@@ -1,8 +0,0 @@-# test003:---test IO:-HELLO!!-WORLD!!---test IOExcept:-HELLO!!-WORLD!!-()
+ test/st003/expected.out view
@@ -0,0 +1,8 @@+# test003:+--test IO:+HELLO!!+WORLD!!+--test IOExcept:+HELLO!!+WORLD!!+()
− test/st003/run 
@@ -1,6 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ -p contrib test003.idr -o test003-echo "# test003:"-./test003-rm -f test003 *.ibc-
+ test/st003/run.sh view
@@ -0,0 +1,6 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ -p contrib test003.idr -o test003+echo "# test003:"+./test003+rm -f test003 *.ibc+
test/st003/test003.idr view
@@ -7,7 +7,7 @@  testFile : (ConsoleIO m, File m) => ST m () [] testFile = with ST do-              Right str <- readFile "testFile" +              Right str <- readFile "testFile.in"                   | Left ferr => do putStrLn (show ferr)                                     pure ()               putStrLn str 
− test/st003/testFile 
@@ -1,2 +0,0 @@-HELLO!!-WORLD!!
+ test/st003/testFile.in view
@@ -0,0 +1,2 @@+HELLO!!+WORLD!!
− test/st004/expected 
@@ -1,6 +0,0 @@-# test004:---test IO:-File Not Found---test IOExcept:-File Not Found-()
+ test/st004/expected.out view
@@ -0,0 +1,6 @@+# test004:+--test IO:+File Not Found+--test IOExcept:+File Not Found+()
− test/st004/run 
@@ -1,6 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ -p contrib test004.idr -o test004-echo "# test004:"-./test004-rm -f test004 *.ibc-
+ test/st004/run.sh view
@@ -0,0 +1,6 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ -p contrib test004.idr -o test004+echo "# test004:"+./test004+rm -f test004 *.ibc+
− test/st005/expected 
@@ -1,6 +0,0 @@-# test005:---test IO:---test IOExcept:-()-HELLO!!-WORLD!!
+ test/st005/expected.out view
@@ -0,0 +1,6 @@+# test005:+--test IO:+--test IOExcept:+()+HELLO!!+WORLD!!
− test/st005/run 
@@ -1,7 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ -p contrib test005.idr -o test005-echo "# test005:"-./test005-cat writeTestFile-rm -f test005 writeTestFile *.ibc-
+ test/st005/run.sh view
@@ -0,0 +1,7 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ -p contrib test005.idr -o test005+echo "# test005:"+./test005+cat writeTestFile+rm -f test005 writeTestFile *.ibc+
− test/st006/expected 
@@ -1,5 +0,0 @@-# test006:---test IO:---test IOExcept:-()-HELLO!!WORLD!!
+ test/st006/expected.out view
@@ -0,0 +1,5 @@+# test006:+--test IO:+--test IOExcept:+()+HELLO!!WORLD!!
− test/st006/run 
@@ -1,6 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ -p contrib test006.idr -o test006-echo "# test006:"-./test006-cat writeStringTestFile-rm -f test006 writeStringTestFile *.ibc
+ test/st006/run.sh view
@@ -0,0 +1,6 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ -p contrib test006.idr -o test006+echo "# test006:"+./test006+cat writeStringTestFile+rm -f test006 writeStringTestFile *.ibc
− test/st007/expected 
@@ -1,6 +0,0 @@-# test007:---test IO:---test IOExcept:-()-HELLO!!-WORLD!!
+ test/st007/expected.out view
@@ -0,0 +1,6 @@+# test007:+--test IO:+--test IOExcept:+()+HELLO!!+WORLD!!
− test/st007/run 
@@ -1,6 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ -p contrib test007.idr -o test007-echo "# test007:"-./test007-cat writeFileTestFile-rm -f test007 writeFileTestFile *.ibc
+ test/st007/run.sh view
@@ -0,0 +1,6 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ -p contrib test007.idr -o test007+echo "# test007:"+./test007+cat writeFileTestFile+rm -f test007 writeFileTestFile *.ibc
− test/sugar001/expected 
@@ -1,4 +0,0 @@-Just 8-Just 9-Just 42-Nothing
+ test/sugar001/expected.out view
@@ -0,0 +1,4 @@+Just 8+Just 9+Just 42+Nothing
− test/sugar001/run 
@@ -1,4 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ test007.idr -o test007-./test007-rm -f test007 test007.ibc
+ test/sugar001/run.sh view
@@ -0,0 +1,4 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ test007.idr -o test007+./test007+rm -f test007 test007.ibc
− test/sugar002/expected 
@@ -1,1 +0,0 @@-[(3, (4, 5)), (6, (8, 10)), (5, (12, 13)), (9, (12, 15)), (8, (15, 17)), (12, (16, 20)), (15, (20, 25)), (7, (24, 25)), (10, (24, 26)), (20, (21, 29)), (18, (24, 30)), (16, (30, 34)), (21, (28, 35)), (12, (35, 37)), (15, (36, 39)), (24, (32, 40)), (9, (40, 41)), (27, (36, 45)), (30, (40, 50)), (14, (48, 50))]
+ test/sugar002/expected.out view
@@ -0,0 +1,1 @@+[(3, (4, 5)), (6, (8, 10)), (5, (12, 13)), (9, (12, 15)), (8, (15, 17)), (12, (16, 20)), (15, (20, 25)), (7, (24, 25)), (10, (24, 26)), (20, (21, 29)), (18, (24, 30)), (16, (30, 34)), (21, (28, 35)), (12, (35, 37)), (15, (36, 39)), (24, (32, 40)), (9, (40, 41)), (27, (36, 45)), (30, (40, 50)), (14, (48, 50))]
− test/sugar002/run 
@@ -1,4 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ test009.idr -o test009-./test009-rm -f test009 test009.ibc
+ test/sugar002/run.sh view
@@ -0,0 +1,4 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ test009.idr -o test009+./test009+rm -f test009 test009.ibc
− test/sugar003/expected 
@@ -1,12 +0,0 @@-Counting:-Number 1-Number 2-Number 3-Number 4-Number 5-Number 6-Number 7-Number 8-Number 9-Number 10-Done!
+ test/sugar003/expected.out view
@@ -0,0 +1,12 @@+Counting:+Number 1+Number 2+Number 3+Number 4+Number 5+Number 6+Number 7+Number 8+Number 9+Number 10+Done!
− test/sugar003/run 
@@ -1,4 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ test013.idr -o test013-./test013-rm -f test013 test013.ibc
+ test/sugar003/run.sh view
@@ -0,0 +1,4 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ test013.idr -o test013+./test013+rm -f test013 test013.ibc
− test/sugar004/expected 
@@ -1,4 +0,0 @@-No arguments!-Not an integer!-42-Too many arguments!
+ test/sugar004/expected.out view
@@ -0,0 +1,4 @@+No arguments!+Not an integer!+42+Too many arguments!
− test/sugar004/run 
@@ -1,7 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ sugar004.idr -o sugar004-./sugar004-./sugar004 foo-./sugar004 42-./sugar004 42 100-rm -f sugar004 *.ibc
+ test/sugar004/run.sh view
@@ -0,0 +1,7 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ sugar004.idr -o sugar004+./sugar004+./sugar004 foo+./sugar004 42+./sugar004 42 100+rm -f sugar004 *.ibc
− test/sugar005/expected 
@@ -1,9 +0,0 @@-Nothing-Just 1-Nothing-Just 1-Just (5, 4)-Nothing-Just 2-Just 42-Nothing
+ test/sugar005/expected.out view
@@ -0,0 +1,9 @@+Nothing+Just 1+Nothing+Just 1+Just (5, 4)+Nothing+Just 2+Just 42+Nothing
− test/sugar005/run 
@@ -1,4 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ As.idr -o sugar005-./sugar005-rm -f sugar005 *.ibc
+ test/sugar005/run.sh view
@@ -0,0 +1,4 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ As.idr -o sugar005+./sugar005+rm -f sugar005 *.ibc
− test/syntax001/expected 
@@ -1,26 +0,0 @@-Syntax.idr:6:7-18:-  |-6 | foo = fnord "argh"-  |       ~~~~~~~~~~~~-When checking right hand side of foo with expected type-        Nat--When checking an application of function Prelude.Interfaces.+:-        Type mismatch between-                String (Type of "argh")-        and-                Nat (Expected type)--SyntaxTest.idr:5:7-18:-  |-5 | foo = fnord "argh"-  |       ~~~~~~~~~~~~-When checking right hand side of foo with expected type-        Nat--When checking an application of function Prelude.Interfaces.+:-        Type mismatch between-                String (Type of "argh")-        and-                Nat (Expected type)-
+ test/syntax001/expected.out view
@@ -0,0 +1,26 @@+Syntax.idr:6:7-18:+  |+6 | foo = fnord "argh"+  |       ~~~~~~~~~~~~+When checking right hand side of foo with expected type+        Nat++When checking an application of function Prelude.Interfaces.+:+        Type mismatch between+                String (Type of "argh")+        and+                Nat (Expected type)++SyntaxTest.idr:5:7-18:+  |+5 | foo = fnord "argh"+  |       ~~~~~~~~~~~~+When checking right hand side of foo with expected type+        Nat++When checking an application of function Prelude.Interfaces.+:+        Type mismatch between+                String (Type of "argh")+        and+                Nat (Expected type)+
− test/syntax001/run 
@@ -1,4 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ Syntax.idr --nocolour --check-${IDRIS:-idris} $@ SyntaxTest.idr --nocolour --check-rm -f *.ibc
+ test/syntax001/run.sh view
@@ -0,0 +1,4 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ Syntax.idr --nocolour --check+${IDRIS:-idris} $@ SyntaxTest.idr --nocolour --check+rm -f *.ibc
− test/syntax002/expected 
@@ -1,2 +0,0 @@-Nothing-7
+ test/syntax002/expected.out view
@@ -0,0 +1,2 @@+Nothing+7
− test/syntax002/run 
@@ -1,4 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ syntax002.idr -o syntax002-./syntax002-rm -f syntax002 *.ibc
+ test/syntax002/run.sh view
@@ -0,0 +1,4 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ syntax002.idr -o syntax002+./syntax002+rm -f syntax002 *.ibc
− test/tactics001/expected 
+ test/tactics001/expected.out view
− test/tactics001/run 
@@ -1,3 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ --check Tactics.idr-rm -f *.ibc
+ test/tactics001/run.sh view
@@ -0,0 +1,3 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ --check Tactics.idr+rm -f *.ibc
− test/totality001/expected 
@@ -1,18 +0,0 @@-test010.idr:15:1-30:-   |-15 | foo (MkBad f i) = f (MkBad' i)-   | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~-Main.foo is possibly not total due to: Main.MkBad--test010a.idr:9:1-23:-  |-9 | bar = MkBad (\x => 3) 3-  | ~~~~~~~~~~~~~~~~~~~~~~~-main.bar is possibly not total due to: main.MkBad--test010b.idr:9:1-23:-  |-9 | bar = MkBad (\x => 3) 3-  | ~~~~~~~~~~~~~~~~~~~~~~~-main.bar is possibly not total due to: main.MkBad-
+ test/totality001/expected.out view
@@ -0,0 +1,18 @@+test010.idr:15:1-30:+   |+15 | foo (MkBad f i) = f (MkBad' i)+   | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+Main.foo is possibly not total due to: Main.MkBad++test010a.idr:9:1-23:+  |+9 | bar = MkBad (\x => 3) 3+  | ~~~~~~~~~~~~~~~~~~~~~~~+main.bar is possibly not total due to: main.MkBad++test010b.idr:9:1-23:+  |+9 | bar = MkBad (\x => 3) 3+  | ~~~~~~~~~~~~~~~~~~~~~~~+main.bar is possibly not total due to: main.MkBad+
− test/totality001/run 
@@ -1,6 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ --check test010.idr-${IDRIS:-idris} $@ --check test010a.idr-${IDRIS:-idris} $@ --check test010b.idr--rm -f *.ibc
+ test/totality001/run.sh view
@@ -0,0 +1,6 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ --check test010.idr+${IDRIS:-idris} $@ --check test010a.idr+${IDRIS:-idris} $@ --check test010b.idr++rm -f *.ibc
− test/totality002/expected 
@@ -1,18 +0,0 @@-test017.idr:94:26-30:-   |-94 | maxCommutativeStepCase = proof {-   |                          ~~~~~-This style of tactic proof is deprecated. See %runElab for the replacement.--test017a.idr:7:1-24:-  |-7 | vtrans [] _         = []-  | ~~~~~~~~~~~~~~~~~~~~~~~~-scg.vtrans is possibly not total due to recursive path scg.vtrans --> scg.vtrans--test017b.idr:4:1-9:-  |-4 | foo = foo-  | ~~~~~~~~~-foo.foo is possibly not total due to recursive path foo.foo-
+ test/totality002/expected.out view
@@ -0,0 +1,18 @@+test017.idr:94:26-30:+   |+94 | maxCommutativeStepCase = proof {+   |                          ~~~~~+This style of tactic proof is deprecated. See %runElab for the replacement.++test017a.idr:7:1-24:+  |+7 | vtrans [] _         = []+  | ~~~~~~~~~~~~~~~~~~~~~~~~+scg.vtrans is possibly not total due to recursive path scg.vtrans --> scg.vtrans++test017b.idr:4:1-9:+  |+4 | foo = foo+  | ~~~~~~~~~+foo.foo is possibly not total due to recursive path foo.foo+
− test/totality002/run 
@@ -1,5 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ --check test017.idr-${IDRIS:-idris} $@ --check test017a.idr-${IDRIS:-idris} $@ --check test017b.idr-rm -f *.ibc
+ test/totality002/run.sh view
@@ -0,0 +1,5 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ --check test017.idr+${IDRIS:-idris} $@ --check test017a.idr+${IDRIS:-idris} $@ --check test017b.idr+rm -f *.ibc
− test/totality003/expected 
@@ -1,6 +0,0 @@-totality003a.idr:5:1-13:-  |-5 | qsort [] = []-  | ~~~~~~~~~~~~~-smaller.qsort is possibly not total due to recursive path smaller.qsort --> smaller.qsort --> smaller.qsort-
+ test/totality003/expected.out view
@@ -0,0 +1,6 @@+totality003a.idr:5:1-13:+  |+5 | qsort [] = []+  | ~~~~~~~~~~~~~+smaller.qsort is possibly not total due to recursive path smaller.qsort --> smaller.qsort --> smaller.qsort+
− test/totality003/run 
@@ -1,4 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ --nocolour totality003.idr --check-${IDRIS:-idris} $@ --nocolour totality003a.idr --check-rm -f *.ibc
+ test/totality003/run.sh view
@@ -0,0 +1,4 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ --nocolour totality003.idr --check+${IDRIS:-idris} $@ --nocolour totality003a.idr --check+rm -f *.ibc
− test/totality004/expected 
@@ -1,13 +0,0 @@-[1, 2, 2, 4, 3, 6, 4, 8, 5, 10]-totality004a.idr:13:1-44:-   |-13 | process (Get f) (x :: xs) = process (f x) xs-   | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~-Main.process is possibly not total due to recursive path Main.process --> Main.process --> Main.process--totality004a.idr:24:1-60:-   |-24 | main = printLn (take 10 (process doubleInt (countStream 1)))-   | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~-Main.main is possibly not total due to: Main.process-
+ test/totality004/expected.out view
@@ -0,0 +1,13 @@+[1, 2, 2, 4, 3, 6, 4, 8, 5, 10]+totality004a.idr:13:1-44:+   |+13 | process (Get f) (x :: xs) = process (f x) xs+   | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+Main.process is possibly not total due to recursive path Main.process --> Main.process --> Main.process++totality004a.idr:24:1-60:+   |+24 | main = printLn (take 10 (process doubleInt (countStream 1)))+   | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+Main.main is possibly not total due to: Main.process+
− test/totality004/run 
@@ -1,5 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ totality004.idr -o totality004-./totality004-${IDRIS:-idris} $@ --check totality004a.idr -rm -f totality004 *.ibc
+ test/totality004/run.sh view
@@ -0,0 +1,5 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ totality004.idr -o totality004+./totality004+${IDRIS:-idris} $@ --check totality004a.idr +rm -f totality004 *.ibc
− test/totality005/expected 
@@ -1,1 +0,0 @@-[0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, 233, 377]
+ test/totality005/expected.out view
@@ -0,0 +1,1 @@+[0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, 233, 377]
− test/totality005/run 
@@ -1,5 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ totality005.idr --total --check-${IDRIS:-idris} $@ totality005.idr -o totality005-./totality005-rm -f totality005 *.ibc
+ test/totality005/run.sh view
@@ -0,0 +1,5 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ totality005.idr --total --check+${IDRIS:-idris} $@ totality005.idr -o totality005+./totality005+rm -f totality005 *.ibc
− test/totality006/expected 
@@ -1,18 +0,0 @@-totality006.idr:8:1-29:-  |-8 | prf Z     Z     Oh impossible-  | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~-Main.prf is not total as there are missing cases--totality006a.idr:11:21-30:-   |-11 | prf' (S _) (S _) Oh impossible-   |                     ~~~~~~~~~~-prf' (S _) (S _) Oh is a valid case--totality006b.idr:10:1-34:-   |-10 | blargh [] (y :: xs) so = absurd so-   | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~-totality006b.blargh is not total as there are missing cases-
+ test/totality006/expected.out view
@@ -0,0 +1,18 @@+totality006.idr:8:1-29:+  |+8 | prf Z     Z     Oh impossible+  | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+Main.prf is not total as there are missing cases++totality006a.idr:11:21-30:+   |+11 | prf' (S _) (S _) Oh impossible+   |                     ~~~~~~~~~~+prf' (S _) (S _) Oh is a valid case++totality006b.idr:10:1-34:+   |+10 | blargh [] (y :: xs) so = absurd so+   | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+totality006b.blargh is not total as there are missing cases+
− test/totality006/run 
@@ -1,5 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ totality006.idr --check-${IDRIS:-idris} $@ totality006a.idr --check-${IDRIS:-idris} $@ totality006b.idr --check-rm -f *.ibc
+ test/totality006/run.sh view
@@ -0,0 +1,5 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ totality006.idr --check+${IDRIS:-idris} $@ totality006a.idr --check+${IDRIS:-idris} $@ totality006b.idr --check+rm -f *.ibc
− test/totality007/expected 
@@ -1,9 +0,0 @@-Entering directory `./src'-Totality.idr:4:1-9:-  |-4 | foo Z = Z-  | ~~~~~~~~~-Totality.foo is not total as there are missing cases--Totality.idr:4:1-9:Could not build: Totality.foo is not total as there are missing cases-Leaving directory `./src'
− test/totality007/expected.msys 
@@ -1,5 +0,0 @@-Entering directory `.\src'-Totality.idr:4:1:-Totality.foo is not total as there are missing cases-Totality.idr:4:1:Could not build: Totality.foo is not total as there are missing cases-Leaving directory `.\src'
+ test/totality007/expected.out view
@@ -0,0 +1,9 @@+Entering directory `./src'+Totality.idr:4:1-9:+  |+4 | foo Z = Z+  | ~~~~~~~~~+Totality.foo is not total as there are missing cases++Totality.idr:4:1-9:Could not build: Totality.foo is not total as there are missing cases+Leaving directory `./src'
− test/totality007/run 
@@ -1,3 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ --build totality.ipkg-rm -f src/*.ibc
+ test/totality007/run.sh view
@@ -0,0 +1,3 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ --build totality.ipkg+rm -f src/*.ibc
− test/totality008/expected 
@@ -1,6 +0,0 @@-totality008.idr:7:1-14:-  |-7 | ElimT _ C1 = 3-  | ~~~~~~~~~~~~~~-Main.ElimT is possibly not total due to: Main.C2-
+ test/totality008/expected.out view
@@ -0,0 +1,6 @@+totality008.idr:7:1-14:+  |+7 | ElimT _ C1 = 3+  | ~~~~~~~~~~~~~~+Main.ElimT is possibly not total due to: Main.C2+
− test/totality008/run 
@@ -1,3 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ totality008.idr --check-rm -f *.ibc
+ test/totality008/run.sh view
@@ -0,0 +1,3 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ totality008.idr --check+rm -f *.ibc
− test/totality009/expected 
@@ -1,60 +0,0 @@-TestLambdaPossible.idr:9:25-34:-  |-9 | wrongPossible = (\Flase impossible)-  |                         ~~~~~~~~~~-Warning - TestLambdaPossible.case block in wrongPossible at TestLambdaPossible.idr:9:25-34 is not total as there are missing cases--TestLambdaPossible.idr:9:1-35:-  |-9 | wrongPossible = (\Flase impossible)-  | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~-Warning - TestLambdaPossible.wrongPossible is possibly not total due to: TestLambdaPossible.case block in wrongPossible at TestLambdaPossible.idr:9:25-34--TestLambdaPossible.idr:12:25:-   |-12 | wrongPossible' x = case x of-   |                         ^-Warning - TestLambdaPossible.case block in wrongPossible' at TestLambdaPossible.idr:12:25 is not total as there are missing cases--TestLambdaPossible.idr:12:1-13:40:-   |-12 | wrongPossible' x = case x of-   | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ...-Warning - TestLambdaPossible.wrongPossible' is possibly not total due to: TestLambdaPossible.case block in wrongPossible' at TestLambdaPossible.idr:12:25--TestLambdaPossible.idr:9:17-35:-  |-9 | wrongPossible = (\Flase impossible)-  |                 ~~~~~~~~~~~~~~~~~~~-Warning - TestLambdaPossible.case block in wrongPossible at TestLambdaPossible.idr:9:25-34 is not total as there are missing cases--TestLambdaPossible.idr:9:1-35:-  |-9 | wrongPossible = (\Flase impossible)-  | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~-Warning - TestLambdaPossible.wrongPossible is possibly not total due to: TestLambdaPossible.case block in wrongPossible at TestLambdaPossible.idr:9:25-34--TestLambdaPossible.idr:12:20-13:40:-   |-12 | wrongPossible' x = case x of-   |                    ~~~~~~~~~ ...-Warning - TestLambdaPossible.case block in wrongPossible' at TestLambdaPossible.idr:12:25 is not total as there are missing cases--TestLambdaPossible.idr:12:1-13:40:-   |-12 | wrongPossible' x = case x of-   | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ...-Warning - TestLambdaPossible.wrongPossible' is possibly not total due to: TestLambdaPossible.case block in wrongPossible' at TestLambdaPossible.idr:12:25--TestLambdaPossible2.idr:10:1-35:-   |-10 | wrongPossible = (\Flase impossible)-   | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~-TestLambdaPossible.wrongPossible is possibly not total due to: TestLambdaPossible.case block in wrongPossible at TestLambdaPossible2.idr:10:25-34--TestLambdaPossible2.idr:14:1-15:40:-   |-14 | wrongPossible' x = case x of-   | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ...-TestLambdaPossible.wrongPossible' is possibly not total due to: TestLambdaPossible.case block in wrongPossible' at TestLambdaPossible2.idr:14:25-
+ test/totality009/expected.out view
@@ -0,0 +1,60 @@+TestLambdaPossible.idr:9:25-34:+  |+9 | wrongPossible = (\Flase impossible)+  |                         ~~~~~~~~~~+Warning - TestLambdaPossible.case block in wrongPossible at TestLambdaPossible.idr:9:25-34 is not total as there are missing cases++TestLambdaPossible.idr:9:1-35:+  |+9 | wrongPossible = (\Flase impossible)+  | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+Warning - TestLambdaPossible.wrongPossible is possibly not total due to: TestLambdaPossible.case block in wrongPossible at TestLambdaPossible.idr:9:25-34++TestLambdaPossible.idr:12:25:+   |+12 | wrongPossible' x = case x of+   |                         ^+Warning - TestLambdaPossible.case block in wrongPossible' at TestLambdaPossible.idr:12:25 is not total as there are missing cases++TestLambdaPossible.idr:12:1-13:40:+   |+12 | wrongPossible' x = case x of+   | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ...+Warning - TestLambdaPossible.wrongPossible' is possibly not total due to: TestLambdaPossible.case block in wrongPossible' at TestLambdaPossible.idr:12:25++TestLambdaPossible.idr:9:17-35:+  |+9 | wrongPossible = (\Flase impossible)+  |                 ~~~~~~~~~~~~~~~~~~~+Warning - TestLambdaPossible.case block in wrongPossible at TestLambdaPossible.idr:9:25-34 is not total as there are missing cases++TestLambdaPossible.idr:9:1-35:+  |+9 | wrongPossible = (\Flase impossible)+  | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+Warning - TestLambdaPossible.wrongPossible is possibly not total due to: TestLambdaPossible.case block in wrongPossible at TestLambdaPossible.idr:9:25-34++TestLambdaPossible.idr:12:20-13:40:+   |+12 | wrongPossible' x = case x of+   |                    ~~~~~~~~~ ...+Warning - TestLambdaPossible.case block in wrongPossible' at TestLambdaPossible.idr:12:25 is not total as there are missing cases++TestLambdaPossible.idr:12:1-13:40:+   |+12 | wrongPossible' x = case x of+   | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ...+Warning - TestLambdaPossible.wrongPossible' is possibly not total due to: TestLambdaPossible.case block in wrongPossible' at TestLambdaPossible.idr:12:25++TestLambdaPossible2.idr:10:1-35:+   |+10 | wrongPossible = (\Flase impossible)+   | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+TestLambdaPossible.wrongPossible is possibly not total due to: TestLambdaPossible.case block in wrongPossible at TestLambdaPossible2.idr:10:25-34++TestLambdaPossible2.idr:14:1-15:40:+   |+14 | wrongPossible' x = case x of+   | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ...+TestLambdaPossible.wrongPossible' is possibly not total due to: TestLambdaPossible.case block in wrongPossible' at TestLambdaPossible2.idr:14:25+
− test/totality009/run 
@@ -1,6 +0,0 @@-#!/usr/bin/env bash-OPTS="--consolewidth infinite --nocolour"-${IDRIS:-idris} $@ $OPTS --check TestLambdaImpossible-${IDRIS:-idris} $@ $OPTS --check --warnpartial TestLambdaPossible-${IDRIS:-idris} $@ $OPTS --check TestLambdaPossible2-rm -f *.ibc
+ test/totality009/run.sh view
@@ -0,0 +1,6 @@+#!/usr/bin/env bash+OPTS="--consolewidth infinite --nocolour"+${IDRIS:-idris} $@ $OPTS --check TestLambdaImpossible+${IDRIS:-idris} $@ $OPTS --check --warnpartial TestLambdaPossible+${IDRIS:-idris} $@ $OPTS --check TestLambdaPossible2+rm -f *.ibc
− test/totality010/expected 
@@ -1,12 +0,0 @@-totality010.idr:27:1-35:-   |-27 | evenNotS MkEven ZeroEven impossible-   | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~-Main.evenNotS is not total as there are missing cases--totality010.idr:30:1-40:-   |-30 | bad = evenNotS ZeroEven $ MkBad ZeroEven-   | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~-Main.bad is possibly not total due to: Main.evenNotS-
+ test/totality010/expected.out view
@@ -0,0 +1,12 @@+totality010.idr:27:1-35:+   |+27 | evenNotS MkEven ZeroEven impossible+   | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+Main.evenNotS is not total as there are missing cases++totality010.idr:30:1-40:+   |+30 | bad = evenNotS ZeroEven $ MkBad ZeroEven+   | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+Main.bad is possibly not total due to: Main.evenNotS+
− test/totality010/run 
@@ -1,3 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ totality010.idr --nocolour --check-rm -f *.ibc
+ test/totality010/run.sh view
@@ -0,0 +1,3 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ totality010.idr --nocolour --check+rm -f *.ibc
− test/totality011/expected 
@@ -1,6 +0,0 @@-totality011.lidr:22:3-57:-   |-22 | > weCanOnlyGetOlder {t'' = Z} {t = Z}   _ _ _  =  LTEZero-   |   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~-Main.weCanOnlyGetOlder is not total as there are missing cases-
+ test/totality011/expected.out view
@@ -0,0 +1,6 @@+totality011.lidr:22:3-57:+   |+22 | > weCanOnlyGetOlder {t'' = Z} {t = Z}   _ _ _  =  LTEZero+   |   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+Main.weCanOnlyGetOlder is not total as there are missing cases+
− test/totality011/run 
@@ -1,3 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ totality011.lidr --check-rm -f *.ibc
+ test/totality011/run.sh view
@@ -0,0 +1,3 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ totality011.lidr --check+rm -f *.ibc
− test/totality012/expected 
@@ -1,12 +0,0 @@-totality012a.idr:9:1-10:27:-  |-9 | echo2 x = if (x == "quit") then PutStr "Bye!\n"-  | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ...-Main.echo2 is possibly not total due to recursive path Main.echo2 --> Main.echo2--totality012b.idr:11:1-17:33:-   |-11 | echo = do PutStr "$ "-   | ~~~~~~~~~~~~~~~~~~~~~ ...-Main.echo is possibly not total due to recursive path Main.echo-
+ test/totality012/expected.out view
@@ -0,0 +1,12 @@+totality012a.idr:9:1-10:27:+  |+9 | echo2 x = if (x == "quit") then PutStr "Bye!\n"+  | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ...+Main.echo2 is possibly not total due to recursive path Main.echo2 --> Main.echo2++totality012b.idr:11:1-17:33:+   |+11 | echo = do PutStr "$ "+   | ~~~~~~~~~~~~~~~~~~~~~ ...+Main.echo is possibly not total due to recursive path Main.echo+
− test/totality012/run 
@@ -1,5 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ totality012.idr --check-${IDRIS:-idris} $@ totality012a.idr --check-${IDRIS:-idris} $@ totality012b.idr --check-rm -f *.ibc
+ test/totality012/run.sh view
@@ -0,0 +1,5 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ totality012.idr --check+${IDRIS:-idris} $@ totality012a.idr --check+${IDRIS:-idris} $@ totality012b.idr --check+rm -f *.ibc
− test/totality013/expected 
@@ -1,12 +0,0 @@-totality013a.idr:5:3-49:-  |-5 |   foo order x xs y ys _ = mtot order (x :: xs) ys-  |   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~-Main.foo is possibly not total due to recursive path Main.foo --> Main.mtot --> Main.mtot --> Main.mtot--totality013a.idr:9:3-36:-  |-9 |   mtot order []      right   = right-  |   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~-Main.mtot is possibly not total due to: Main.foo-
+ test/totality013/expected.out view
@@ -0,0 +1,12 @@+totality013a.idr:5:3-49:+  |+5 |   foo order x xs y ys _ = mtot order (x :: xs) ys+  |   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+Main.foo is possibly not total due to recursive path Main.foo --> Main.mtot --> Main.mtot --> Main.mtot++totality013a.idr:9:3-36:+  |+9 |   mtot order []      right   = right+  |   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+Main.mtot is possibly not total due to: Main.foo+
− test/totality013/run 
@@ -1,4 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ totality013.idr --check-${IDRIS:-idris} $@ totality013a.idr --check-rm -f *.ibc
+ test/totality013/run.sh view
@@ -0,0 +1,4 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ totality013.idr --check+${IDRIS:-idris} $@ totality013a.idr --check+rm -f *.ibc
− test/totality014/expected 
@@ -1,13 +0,0 @@-totality014.idr:1:6-9:-  |-1 | data Con2 : Type where-  |      ~~~~-Universe inconsistency.-        Working on: ./totality014.idr.w-        Old domain: (5,5)-        New domain: (5,4)-        Involved constraints: -                ConstraintFC {uconstraint = ./totality014.idr.w < ./totality014.idr.u, ufc = totality014.idr:1:6-9}-                ConstraintFC {uconstraint = ./totality014.idr.w < ./totality014.idr.u, ufc = totality014.idr:1:6-9}-                ConstraintFC {uconstraint = ./totality014.idr.u <= ./totality014.idr.w, ufc = totality014.idr:6:29}-
+ test/totality014/expected.out view
@@ -0,0 +1,13 @@+totality014.idr:1:6-9:+  |+1 | data Con2 : Type where+  |      ~~~~+Universe inconsistency.+        Working on: ./totality014.idr.w+        Old domain: (5,5)+        New domain: (5,4)+        Involved constraints: +                ConstraintFC {uconstraint = ./totality014.idr.w < ./totality014.idr.u, ufc = totality014.idr:1:6-9}+                ConstraintFC {uconstraint = ./totality014.idr.w < ./totality014.idr.u, ufc = totality014.idr:1:6-9}+                ConstraintFC {uconstraint = ./totality014.idr.u <= ./totality014.idr.w, ufc = totality014.idr:6:29}+
− test/totality014/run 
@@ -1,3 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ totality014.idr --check-rm -f *.ibc
+ test/totality014/run.sh view
@@ -0,0 +1,3 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ totality014.idr --check+rm -f *.ibc
− test/totality015/expected 
@@ -1,18 +0,0 @@-totality015a.idr:52:3-53:-   |-52 |   quiz (num1 :: num2 :: nums) score = quiz nums score-   |   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~-Main.quiz is possibly not total due to recursive path Main.quiz --> Main.quiz--totality015a.idr:42:3-44:36:-   |-42 |   correct nums score-   |   ~~~~~~~~~~~~~~~~~~ ...-Main.correct is possibly not total due to: Main.quiz--totality015a.idr:47:3-49:28:-   |-47 |   wrong nums ans score-   |   ~~~~~~~~~~~~~~~~~~~~ ...-Main.wrong is possibly not total due to: Main.quiz-
+ test/totality015/expected.out view
@@ -0,0 +1,18 @@+totality015a.idr:52:3-53:+   |+52 |   quiz (num1 :: num2 :: nums) score = quiz nums score+   |   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+Main.quiz is possibly not total due to recursive path Main.quiz --> Main.quiz++totality015a.idr:42:3-44:36:+   |+42 |   correct nums score+   |   ~~~~~~~~~~~~~~~~~~ ...+Main.correct is possibly not total due to: Main.quiz++totality015a.idr:47:3-49:28:+   |+47 |   wrong nums ans score+   |   ~~~~~~~~~~~~~~~~~~~~ ...+Main.wrong is possibly not total due to: Main.quiz+
− test/totality015/run 
@@ -1,4 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ totality015.idr --check-${IDRIS:-idris} $@ totality015a.idr --check-rm -f *.ibc
+ test/totality015/run.sh view
@@ -0,0 +1,4 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ totality015.idr --check+${IDRIS:-idris} $@ totality015a.idr --check+rm -f *.ibc
− test/totality016/expected 
@@ -1,54 +0,0 @@-totality016.idr:15:1-21:-   |-15 | f1 (MkTP T1 x) = True-   | ~~~~~~~~~~~~~~~~~~~~~-Main.f1 is not total as there are missing cases--totality016.idr:19:1-24:-   |-19 | f2 (MkTP T1 x, _) = True-   | ~~~~~~~~~~~~~~~~~~~~~~~~-Main.f2 is not total as there are missing cases--totality016.idr:23:1-29:-   |-23 | f3 ((MkTP T1 x, _), _) = True-   | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~-Main.f3 is not total as there are missing cases--totality016.idr:27:1-14:-   |-27 | g1 T1 x = True-   | ~~~~~~~~~~~~~~-Main.g1 is not total as there are missing cases--totality016.idr:31:1-17:-   |-31 | g2 (T1, x) = True-   | ~~~~~~~~~~~~~~~~~-Main.g2 is not total as there are missing cases--totality016.idr:35:1-16:-   |-35 | h1 True x = True-   | ~~~~~~~~~~~~~~~~-Main.h1 is not total as there are missing cases--totality016.idr:39:1-19:-   |-39 | h2 (True, x) = True-   | ~~~~~~~~~~~~~~~~~~~-Main.h2 is not total as there are missing cases--totality016.idr:43:1-25:-   |-43 | h3 (MkTP2 (T1, x)) = True-   | ~~~~~~~~~~~~~~~~~~~~~~~~~-Main.h3 is not total as there are missing cases--totality016.idr:47:1-30:-   |-47 | h4 (MkTP2 (T1, x), _) _ = True-   | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~-Main.h4 is not total as there are missing cases-
+ test/totality016/expected.out view
@@ -0,0 +1,54 @@+totality016.idr:15:1-21:+   |+15 | f1 (MkTP T1 x) = True+   | ~~~~~~~~~~~~~~~~~~~~~+Main.f1 is not total as there are missing cases++totality016.idr:19:1-24:+   |+19 | f2 (MkTP T1 x, _) = True+   | ~~~~~~~~~~~~~~~~~~~~~~~~+Main.f2 is not total as there are missing cases++totality016.idr:23:1-29:+   |+23 | f3 ((MkTP T1 x, _), _) = True+   | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+Main.f3 is not total as there are missing cases++totality016.idr:27:1-14:+   |+27 | g1 T1 x = True+   | ~~~~~~~~~~~~~~+Main.g1 is not total as there are missing cases++totality016.idr:31:1-17:+   |+31 | g2 (T1, x) = True+   | ~~~~~~~~~~~~~~~~~+Main.g2 is not total as there are missing cases++totality016.idr:35:1-16:+   |+35 | h1 True x = True+   | ~~~~~~~~~~~~~~~~+Main.h1 is not total as there are missing cases++totality016.idr:39:1-19:+   |+39 | h2 (True, x) = True+   | ~~~~~~~~~~~~~~~~~~~+Main.h2 is not total as there are missing cases++totality016.idr:43:1-25:+   |+43 | h3 (MkTP2 (T1, x)) = True+   | ~~~~~~~~~~~~~~~~~~~~~~~~~+Main.h3 is not total as there are missing cases++totality016.idr:47:1-30:+   |+47 | h4 (MkTP2 (T1, x), _) _ = True+   | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+Main.h4 is not total as there are missing cases+
− test/totality016/run 
@@ -1,3 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ totality016.idr --check-rm -f *.ibc
+ test/totality016/run.sh view
@@ -0,0 +1,3 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ totality016.idr --check+rm -f *.ibc
− test/totality017/expected 
@@ -1,36 +0,0 @@-totality017.idr:19:1-15:-   |-19 | g1 T1 T1 = True-   | ~~~~~~~~~~~~~~~-Main.g1 is not total as there are missing cases--totality017.idr:25:1-17:-   |-25 | g2 T1' T1' = True-   | ~~~~~~~~~~~~~~~~~-Main.g2 is not total as there are missing cases--totality017.idr:31:1-13:-   |-31 | g3 T1' = True-   | ~~~~~~~~~~~~~-Main.g3 is not total as there are missing cases--totality017.idr:37:1-36:-   |-37 | g4 (MkTTPP (MkPP 0) (MkPP 0)) = True-   | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~-Main.g4 is not total as there are missing cases--totality017.idr:42:1-11:-   |-42 | f' 0 = True-   | ~~~~~~~~~~~-Main.f' is not total as there are missing cases--totality017.idr:47:1-17:-   |-47 | f (MkPP 0) = True-   | ~~~~~~~~~~~~~~~~~-Main.f is not total as there are missing cases-
+ test/totality017/expected.out view
@@ -0,0 +1,36 @@+totality017.idr:19:1-15:+   |+19 | g1 T1 T1 = True+   | ~~~~~~~~~~~~~~~+Main.g1 is not total as there are missing cases++totality017.idr:25:1-17:+   |+25 | g2 T1' T1' = True+   | ~~~~~~~~~~~~~~~~~+Main.g2 is not total as there are missing cases++totality017.idr:31:1-13:+   |+31 | g3 T1' = True+   | ~~~~~~~~~~~~~+Main.g3 is not total as there are missing cases++totality017.idr:37:1-36:+   |+37 | g4 (MkTTPP (MkPP 0) (MkPP 0)) = True+   | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+Main.g4 is not total as there are missing cases++totality017.idr:42:1-11:+   |+42 | f' 0 = True+   | ~~~~~~~~~~~+Main.f' is not total as there are missing cases++totality017.idr:47:1-17:+   |+47 | f (MkPP 0) = True+   | ~~~~~~~~~~~~~~~~~+Main.f is not total as there are missing cases+
− test/totality017/run 
@@ -1,3 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ totality017.idr --check-rm -f *.ibc
+ test/totality017/run.sh view
@@ -0,0 +1,3 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ totality017.idr --check+rm -f *.ibc
− test/totality018/expected 
@@ -1,6 +0,0 @@-totality018.idr:12:1-10:-   |-12 | bar FZ = 0-   | ~~~~~~~~~~-Main.bar is not total as there are missing cases-
+ test/totality018/expected.out view
@@ -0,0 +1,6 @@+totality018.idr:12:1-10:+   |+12 | bar FZ = 0+   | ~~~~~~~~~~+Main.bar is not total as there are missing cases+
− test/totality018/run 
@@ -1,3 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ totality018.idr --check-rm -f *.ibc
+ test/totality018/run.sh view
@@ -0,0 +1,3 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ totality018.idr --check+rm -f *.ibc
− test/totality019/expected 
@@ -1,12 +0,0 @@-totality019.idr:8:1-36:-  |-8 | testCov False False = ?testCov_rhs_3-  | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~-Main.testCov is not total as there are missing cases--totality019.idr:12:1-42:-   |-12 | testCov' (False ** False) = ?testCov_rhs_3-   | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~-Main.testCov' is not total as there are missing cases-
+ test/totality019/expected.out view
@@ -0,0 +1,12 @@+totality019.idr:8:1-36:+  |+8 | testCov False False = ?testCov_rhs_3+  | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+Main.testCov is not total as there are missing cases++totality019.idr:12:1-42:+   |+12 | testCov' (False ** False) = ?testCov_rhs_3+   | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+Main.testCov' is not total as there are missing cases+
− test/totality019/run 
@@ -1,4 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ totality019.idr --check-${IDRIS:-idris} $@ totality019a.idr --check-rm -f *.ibc
+ test/totality019/run.sh view
@@ -0,0 +1,4 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ totality019.idr --check+${IDRIS:-idris} $@ totality019a.idr --check+rm -f *.ibc
− test/totality020/expected 
@@ -1,12 +0,0 @@-totality020.idr:4:14-23:-  |-4 | bug _ _ Refl impossible-  |              ~~~~~~~~~~-bug _ _ Refl is a valid case--totality020.idr:7:14-23:-  |-7 | foo a b Refl impossible-  |              ~~~~~~~~~~-foo a b Refl is a valid case-
+ test/totality020/expected.out view
@@ -0,0 +1,12 @@+totality020.idr:4:14-23:+  |+4 | bug _ _ Refl impossible+  |              ~~~~~~~~~~+bug _ _ Refl is a valid case++totality020.idr:7:14-23:+  |+7 | foo a b Refl impossible+  |              ~~~~~~~~~~+foo a b Refl is a valid case+
− test/totality020/run 
@@ -1,3 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ totality020.idr --check-rm -f *.ibc
+ test/totality020/run.sh view
@@ -0,0 +1,3 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ totality020.idr --check+rm -f *.ibc
− test/totality021/expected 
@@ -1,30 +0,0 @@-totality021.idr:8:1-67:-  |-8 | sLevelNotSLevel' (SL (Delay level)) p = sLevelNotSLevel' level Refl-  | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~-Main.sLevelNotSLevel' is possibly not total due to recursive path Main.sLevelNotSLevel' --> Main.sLevelNotSLevel'--totality021.idr:12:1-66:-   |-12 | sLevelNotSLevel (SL (Delay level)) p = sLevelNotSLevel' level Refl-   | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~-Main.sLevelNotSLevel is possibly not total due to: Main.sLevelNotSLevel'--totality021.idr:18:1-26:-   |-18 | v = sLevelNotSLevel l Refl-   | ~~~~~~~~~~~~~~~~~~~~~~~~~~-Main.v is possibly not total due to: Main.sLevelNotSLevel--totality021a.idr:9:1-37:-  |-9 | noNonEmptyPointInt {n} Nil impossible-  | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~-Main.noNonEmptyPointInt is not total as there are missing cases--totality021a.idr:12:1-31:-   |-12 | myVoid = noNonEmptyPointInt [2]-   | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~-Main.myVoid is possibly not total due to: Main.noNonEmptyPointInt-
+ test/totality021/expected.out view
@@ -0,0 +1,30 @@+totality021.idr:8:1-67:+  |+8 | sLevelNotSLevel' (SL (Delay level)) p = sLevelNotSLevel' level Refl+  | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+Main.sLevelNotSLevel' is possibly not total due to recursive path Main.sLevelNotSLevel' --> Main.sLevelNotSLevel'++totality021.idr:12:1-66:+   |+12 | sLevelNotSLevel (SL (Delay level)) p = sLevelNotSLevel' level Refl+   | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+Main.sLevelNotSLevel is possibly not total due to: Main.sLevelNotSLevel'++totality021.idr:18:1-26:+   |+18 | v = sLevelNotSLevel l Refl+   | ~~~~~~~~~~~~~~~~~~~~~~~~~~+Main.v is possibly not total due to: Main.sLevelNotSLevel++totality021a.idr:9:1-37:+  |+9 | noNonEmptyPointInt {n} Nil impossible+  | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+Main.noNonEmptyPointInt is not total as there are missing cases++totality021a.idr:12:1-31:+   |+12 | myVoid = noNonEmptyPointInt [2]+   | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+Main.myVoid is possibly not total due to: Main.noNonEmptyPointInt+
− test/totality021/run 
@@ -1,4 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ totality021.idr --check-${IDRIS:-idris} $@ totality021a.idr --check-rm -f *.ibc
+ test/totality021/run.sh view
@@ -0,0 +1,4 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ totality021.idr --check+${IDRIS:-idris} $@ totality021a.idr --check+rm -f *.ibc
− test/totality022/expected 
@@ -1,6 +0,0 @@-totality022.idr:7:20-29:-  |-7 | f _ [] (RSnoc _ _) impossible -- = ?wat-  |                    ~~~~~~~~~~-f _ [] (RSnoc _ _) is a valid case-
+ test/totality022/expected.out view
@@ -0,0 +1,6 @@+totality022.idr:7:20-29:+  |+7 | f _ [] (RSnoc _ _) impossible -- = ?wat+  |                    ~~~~~~~~~~+f _ [] (RSnoc _ _) is a valid case+
− test/totality022/run 
@@ -1,3 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ totality022.idr --check-rm -f *.ibc
+ test/totality022/run.sh view
@@ -0,0 +1,3 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ totality022.idr --check+rm -f *.ibc
− test/totality023/expected 
@@ -1,6 +0,0 @@-totality023.idr:9:1-10:27:-  |-9 | run (Do x f) = do r <- x-  | ~~~~~~~~~~~~~~~~~~~~~~~~ ...-Main.run is possibly not total due to recursive path Main.run --> Main.run-
+ test/totality023/expected.out view
@@ -0,0 +1,6 @@+totality023.idr:9:1-10:27:+  |+9 | run (Do x f) = do r <- x+  | ~~~~~~~~~~~~~~~~~~~~~~~~ ...+Main.run is possibly not total due to recursive path Main.run --> Main.run+
− test/totality023/run 
@@ -1,3 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ totality023.idr --check-rm -f *.ibc
+ test/totality023/run.sh view
@@ -0,0 +1,3 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ totality023.idr --check+rm -f *.ibc
− test/totality024/expected 
@@ -1,1 +0,0 @@-totality023.idr:5:3:Main.ana is possibly not total due to: Main.ana, go
+ test/totality024/expected.out view
@@ -0,0 +1,1 @@+totality023.idr:5:3:Main.ana is possibly not total due to: Main.ana, go
− test/totality024/run 
@@ -1,3 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ totality023.idr --check-rm -f *.ibc
+ test/totality024/run.sh view
@@ -0,0 +1,3 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ totality023.idr --check+rm -f *.ibc
− test/totality025/expected 
@@ -1,18 +0,0 @@-totality025.idr:3:17-26:-  |-3 | bad1 _ _ _ Refl impossible-  |                 ~~~~~~~~~~-bad1 _ _ _ Refl is a valid case--totality025.idr:12:17-26:-   |-12 | bad2 _ _ _ Refl impossible-   |                 ~~~~~~~~~~-bad2 _ _ _ Refl is a valid case--totality025.idr:16:19-28:-   |-16 | bad3 _ _ _ _ Refl impossible-   |                   ~~~~~~~~~~-bad3 _ _ _ _ Refl is a valid case-
+ test/totality025/expected.out view
@@ -0,0 +1,18 @@+totality025.idr:3:17-26:+  |+3 | bad1 _ _ _ Refl impossible+  |                 ~~~~~~~~~~+bad1 _ _ _ Refl is a valid case++totality025.idr:12:17-26:+   |+12 | bad2 _ _ _ Refl impossible+   |                 ~~~~~~~~~~+bad2 _ _ _ Refl is a valid case++totality025.idr:16:19-28:+   |+16 | bad3 _ _ _ _ Refl impossible+   |                   ~~~~~~~~~~+bad3 _ _ _ _ Refl is a valid case+
− test/totality025/run 
@@ -1,3 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ totality025.idr --check-rm -f *.ibc
+ test/totality025/run.sh view
@@ -0,0 +1,3 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ totality025.idr --check+rm -f *.ibc
− test/totality026/expected 
@@ -1,6 +0,0 @@-totality026.idr:5:8-17:-  |-5 | p Here impossible-  |        ~~~~~~~~~~-p Here is a valid case-
+ test/totality026/expected.out view
@@ -0,0 +1,6 @@+totality026.idr:5:8-17:+  |+5 | p Here impossible+  |        ~~~~~~~~~~+p Here is a valid case+
− test/totality026/run 
@@ -1,3 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ totality026.idr --check-rm -f *.ibc
+ test/totality026/run.sh view
@@ -0,0 +1,3 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ totality026.idr --check+rm -f *.ibc
− test/tutorial001/expected 
+ test/tutorial001/expected.out view
− test/tutorial001/run 
@@ -1,3 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ --check tutorial001.idr-rm -f *.ibc
+ test/tutorial001/run.sh view
@@ -0,0 +1,3 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ --check tutorial001.idr+rm -f *.ibc
− test/tutorial002/expected 
@@ -1,18 +0,0 @@-tutorial002.idr:41:25-29:-   |-41 | Main.natToBin_lemma_1 = proof-   |                         ~~~~~-This style of tactic proof is deprecated. See %runElab for the replacement.--tutorial002.idr:48:18-22:-   |-48 | parity_lemma_1 = proof-   |                  ~~~~~-This style of tactic proof is deprecated. See %runElab for the replacement.--tutorial002.idr:54:18-22:-   |-54 | parity_lemma_2 = proof {-   |                  ~~~~~-This style of tactic proof is deprecated. See %runElab for the replacement.-
+ test/tutorial002/expected.out view
@@ -0,0 +1,18 @@+tutorial002.idr:41:25-29:+   |+41 | Main.natToBin_lemma_1 = proof+   |                         ~~~~~+This style of tactic proof is deprecated. See %runElab for the replacement.++tutorial002.idr:48:18-22:+   |+48 | parity_lemma_1 = proof+   |                  ~~~~~+This style of tactic proof is deprecated. See %runElab for the replacement.++tutorial002.idr:54:18-22:+   |+54 | parity_lemma_2 = proof {+   |                  ~~~~~+This style of tactic proof is deprecated. See %runElab for the replacement.+
− test/tutorial002/run 
@@ -1,3 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ --nocolour tutorial002.idr --check-rm -f *.ibc
+ test/tutorial002/run.sh view
@@ -0,0 +1,3 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ --nocolour tutorial002.idr --check+rm -f *.ibc
− test/tutorial003/expected 
+ test/tutorial003/expected.out view
− test/tutorial003/run 
@@ -1,3 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ tutorial003.idr --check -rm -f *.ibc
+ test/tutorial003/run.sh view
@@ -0,0 +1,3 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ tutorial003.idr --check +rm -f *.ibc
− test/tutorial004/expected 
@@ -1,12 +0,0 @@-tutorial004.idr:46:14-18:-   |-46 | plusredZ_S = proof {-   |              ~~~~~-This style of tactic proof is deprecated. See %runElab for the replacement.--tutorial004.idr:53:14-18:-   |-53 | plusredZ_Z = proof {-   |              ~~~~~-This style of tactic proof is deprecated. See %runElab for the replacement.-
+ test/tutorial004/expected.out view
@@ -0,0 +1,12 @@+tutorial004.idr:46:14-18:+   |+46 | plusredZ_S = proof {+   |              ~~~~~+This style of tactic proof is deprecated. See %runElab for the replacement.++tutorial004.idr:53:14-18:+   |+53 | plusredZ_Z = proof {+   |              ~~~~~+This style of tactic proof is deprecated. See %runElab for the replacement.+
− test/tutorial004/run 
@@ -1,3 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ tutorial004.idr --check --nocolour-rm -f *.ibc
+ test/tutorial004/run.sh view
@@ -0,0 +1,3 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ tutorial004.idr --check --nocolour+rm -f *.ibc
− test/tutorial005/expected 
+ test/tutorial005/expected.out view
− test/tutorial005/run 
@@ -1,3 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ tutorial005.idr --check-rm -f *.ibc
+ test/tutorial005/run.sh view
@@ -0,0 +1,3 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ tutorial005.idr --check+rm -f *.ibc
− test/tutorial006/expected 
@@ -1,37 +0,0 @@-tutorial006a.idr:5:23-24:-  |-5 | vapp (x :: xs) ys = x :: vapp xs xs -- BROKEN-  |                       ~~-When checking right hand side of vapp with expected type-        Vect (S len + m) a--When checking argument xs to constructor Data.Vect.:::-        Type mismatch between-                Vect (len + len) a (Type of vapp xs xs)-        and-                Vect (plus len m) a (Expected type)-        -        Specifically:-                Type mismatch between-                        plus len len-                and-                        plus len m--tutorial006b.idr:10:39-50:-   |-10 |   parity (S (S (j + j)))     | Even = Even {n=S j}-   |                                       ~~~~~~~~~~~~-When checking right hand side of with block in Main.parity with expected type-        Parity (S (S (j + j)))--Type mismatch between-        Parity (S j + S j) (Type of Even)-and-        Parity (S (S (plus j j))) (Expected type)--Specifically:-        Type mismatch between-                plus (S j) (S j)-        and-                S (S (plus j j))-
+ test/tutorial006/expected.out view
@@ -0,0 +1,37 @@+tutorial006a.idr:5:23-24:+  |+5 | vapp (x :: xs) ys = x :: vapp xs xs -- BROKEN+  |                       ~~+When checking right hand side of vapp with expected type+        Vect (S len + m) a++When checking argument xs to constructor Data.Vect.:::+        Type mismatch between+                Vect (len + len) a (Type of vapp xs xs)+        and+                Vect (plus len m) a (Expected type)+        +        Specifically:+                Type mismatch between+                        plus len len+                and+                        plus len m++tutorial006b.idr:10:39-50:+   |+10 |   parity (S (S (j + j)))     | Even = Even {n=S j}+   |                                       ~~~~~~~~~~~~+When checking right hand side of with block in Main.parity with expected type+        Parity (S (S (j + j)))++Type mismatch between+        Parity (S j + S j) (Type of Even)+and+        Parity (S (S (plus j j))) (Expected type)++Specifically:+        Type mismatch between+                plus (S j) (S j)+        and+                S (S (plus j j))+
− test/tutorial006/run 
@@ -1,5 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ --nocolour tutorial006a.idr --check-${IDRIS:-idris} $@ --nocolour tutorial006b.idr --check-${IDRIS:-idris} $@ --nocolour tutorial006c.idr -p effects --check-rm -f *.ibc
+ test/tutorial006/run.sh view
@@ -0,0 +1,5 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ --nocolour tutorial006a.idr --check+${IDRIS:-idris} $@ --nocolour tutorial006b.idr --check+${IDRIS:-idris} $@ --nocolour tutorial006c.idr -p effects --check+rm -f *.ibc
− test/tutorial007/expected 
@@ -1,1 +0,0 @@-Pass
+ test/tutorial007/expected.out view
@@ -0,0 +1,1 @@+Pass
− test/tutorial007/run 
@@ -1,5 +0,0 @@-#!/usr/bin/env bash-${CC:-cc} -shared -fPIC nativetypes.c -o nativetypes.so-${IDRIS:-idris} $@ tutorial007.idr -o tutorial007-./tutorial007-rm -f tutorial007 *.ibc *.so sizefromc.txt
+ test/tutorial007/run.sh view
@@ -0,0 +1,5 @@+#!/usr/bin/env bash+${CC:-cc} -shared -fPIC nativetypes.c -o nativetypes.so+${IDRIS:-idris} $@ tutorial007.idr -o tutorial007+./tutorial007+rm -f tutorial007 *.ibc *.so sizefromc.txt
− test/unique001/expected 
@@ -1,4 +0,0 @@-19,18,17,16,15,14,13,12,11,10,9,8,7,6,5,4,3,2,1,0,END-19,18,17,16,15,14,13,12,11,10,9,8,7,6,5,4,3,2,1,0,END-38,36,34,32,30,28,26,24,22,20,18,16,14,12,10,8,6,4,2,0,END-38,36,34,32,30,28,26,24,22,20,18,16,14,12,10,8,6,4,2,0,END
+ test/unique001/expected.out view
@@ -0,0 +1,4 @@+19,18,17,16,15,14,13,12,11,10,9,8,7,6,5,4,3,2,1,0,END+19,18,17,16,15,14,13,12,11,10,9,8,7,6,5,4,3,2,1,0,END+38,36,34,32,30,28,26,24,22,20,18,16,14,12,10,8,6,4,2,0,END+38,36,34,32,30,28,26,24,22,20,18,16,14,12,10,8,6,4,2,0,END
− test/unique001/run 
@@ -1,6 +0,0 @@-#!/usr/bin/env bash--${IDRIS:-idris} $@ --nocolour unique001.idr -o unique001-./unique001--rm -f unique001 *.ibc
+ test/unique001/run.sh view
@@ -0,0 +1,6 @@+#!/usr/bin/env bash++${IDRIS:-idris} $@ --nocolour unique001.idr -o unique001+./unique001++rm -f unique001 *.ibc
− test/unique004/expected 
@@ -1,75 +0,0 @@-unique001a.idr:35:16-43:50:-   |-35 | showStuff xs = do-   |                ~~ ...-Type mismatch between-        Int -> String-and-        UniqueType (Int -> String)--unique001a.idr:46:17-54:28:-   |-46 | showStuff' xs = do-   |                 ~~ ...-Type mismatch between-        Int -> String-and-        UniqueType (Int -> String)--unique001a.idr:57:17-62:33:-   |-57 | showThings xs = do-   |                 ~~ ...-Type mismatch between-        UniqueType (Int -> String)-and-        Int -> String--unique001b.idr:18:19-42:-   |-18 | showU (x :: xs) = show x ++ "," ++ free xs-   |                   ~~~~~~~~~~~~~~~~~~~~~~~~-Borrowed name xs must not be used on RHS--unique001c.idr:47:14-62:-   |-47 | ndup {a} x = (\f : Int -> a => MkUPair (f 0) (f 1)) (uconst x)-   |              ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~-Unique name f is used more than once--unique001d.idr:4:18:-  |-4 | steal (Read x) = x-  |                  ^-Borrowed name x must not be used on RHS--unique001e.idr:4:12-40:-  |-4 |      Nil : {a : UniqueType} -> BadList a-  |            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~-Constructor Main.Nil has a UniqueType, but the data type does not--unique002.idr:17:10-20:19:-   |-17 | foo xs = do -- let f = \x : Int => showU xs-   |          ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ...-Unique name xs is used more than once--unique002a.idr:17:10-20:19:-   |-17 | foo xs = do let f = \x : Int => showU xs-   |          ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ...-Type mismatch between-        Int -> String-and-        UniqueType (Int -> String)--unique003.idr:20:10-24:19:-   |-20 | foo xs = do let f = \x : Int => showU xs -- can't build this in unique context-   |          ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ...-Type mismatch between-        Int -> String-and-        UniqueType (Int -> String)-
+ test/unique004/expected.out view
@@ -0,0 +1,75 @@+unique001a.idr:35:16-43:50:+   |+35 | showStuff xs = do+   |                ~~ ...+Type mismatch between+        Int -> String+and+        UniqueType (Int -> String)++unique001a.idr:46:17-54:28:+   |+46 | showStuff' xs = do+   |                 ~~ ...+Type mismatch between+        Int -> String+and+        UniqueType (Int -> String)++unique001a.idr:57:17-62:33:+   |+57 | showThings xs = do+   |                 ~~ ...+Type mismatch between+        UniqueType (Int -> String)+and+        Int -> String++unique001b.idr:18:19-42:+   |+18 | showU (x :: xs) = show x ++ "," ++ free xs+   |                   ~~~~~~~~~~~~~~~~~~~~~~~~+Borrowed name xs must not be used on RHS++unique001c.idr:47:14-62:+   |+47 | ndup {a} x = (\f : Int -> a => MkUPair (f 0) (f 1)) (uconst x)+   |              ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+Unique name f is used more than once++unique001d.idr:4:18:+  |+4 | steal (Read x) = x+  |                  ^+Borrowed name x must not be used on RHS++unique001e.idr:4:12-40:+  |+4 |      Nil : {a : UniqueType} -> BadList a+  |            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+Constructor Main.Nil has a UniqueType, but the data type does not++unique002.idr:17:10-20:19:+   |+17 | foo xs = do -- let f = \x : Int => showU xs+   |          ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ...+Unique name xs is used more than once++unique002a.idr:17:10-20:19:+   |+17 | foo xs = do let f = \x : Int => showU xs+   |          ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ...+Type mismatch between+        Int -> String+and+        UniqueType (Int -> String)++unique003.idr:20:10-24:19:+   |+20 | foo xs = do let f = \x : Int => showU xs -- can't build this in unique context+   |          ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ...+Type mismatch between+        Int -> String+and+        UniqueType (Int -> String)+
− test/unique004/run 
@@ -1,14 +0,0 @@-#!/usr/bin/env bash--${IDRIS:-idris} --nobanner --nocolour --quiet --port none <<!-:load unique001a.idr-:load unique001b.idr-:load unique001c.idr-:load unique001d.idr-:load unique001e.idr-:load unique002.idr-:load unique002a.idr-:load unique003.idr-!--rm -f *.ibc
+ test/unique004/run.sh view
@@ -0,0 +1,14 @@+#!/usr/bin/env bash++${IDRIS:-idris} --nobanner --nocolour --quiet --port none <<!+:load unique001a.idr+:load unique001b.idr+:load unique001c.idr+:load unique001d.idr+:load unique001e.idr+:load unique002.idr+:load unique002a.idr+:load unique003.idr+!++rm -f *.ibc
− test/universes001/expected 
@@ -1,14 +0,0 @@-universes001.idr:7:7-21:-  |-7 | foo = Const (Const 0)-  |       ~~~~~~~~~~~~~~~-Universe inconsistency.-        Working on: ./universes001.idr.x-        Old domain: (5,5)-        New domain: (5,4)-        Involved constraints: -                ConstraintFC {uconstraint = ./universes001.idr.x <= ./universes001.idr.z, ufc = universes001.idr:7:7-21}-                ConstraintFC {uconstraint = ./universes001.idr.x < ./universes001.idr.y, ufc = universes001.idr:1:6-8}-                ConstraintFC {uconstraint = ./universes001.idr.z < ./universes001.idr.x, ufc = universes001.idr:1:6-8}-                ConstraintFC {uconstraint = ./universes001.idr.x <= ./universes001.idr.z, ufc = universes001.idr:7:7-21}-
+ test/universes001/expected.out view
@@ -0,0 +1,14 @@+universes001.idr:7:7-21:+  |+7 | foo = Const (Const 0)+  |       ~~~~~~~~~~~~~~~+Universe inconsistency.+        Working on: ./universes001.idr.x+        Old domain: (5,5)+        New domain: (5,4)+        Involved constraints: +                ConstraintFC {uconstraint = ./universes001.idr.x <= ./universes001.idr.z, ufc = universes001.idr:7:7-21}+                ConstraintFC {uconstraint = ./universes001.idr.x < ./universes001.idr.y, ufc = universes001.idr:1:6-8}+                ConstraintFC {uconstraint = ./universes001.idr.z < ./universes001.idr.x, ufc = universes001.idr:1:6-8}+                ConstraintFC {uconstraint = ./universes001.idr.x <= ./universes001.idr.z, ufc = universes001.idr:7:7-21}+
− test/universes001/run 
@@ -1,3 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ universes001.idr --check-rm -f *.ibc
+ test/universes001/run.sh view
@@ -0,0 +1,3 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ universes001.idr --check+rm -f *.ibc
− test/universes002/expected 
@@ -1,14 +0,0 @@-universes002.idr:45:11-48:-   |-45 | russell = lemma (MkMPair (MkMPair R lemma) REFL) -   |           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~-Universe inconsistency.-        Working on: ./universes002.idr.b1-        Old domain: (5,5)-        New domain: (5,4)-        Involved constraints: -                ConstraintFC {uconstraint = ./universes002.idr.b1 <= ./universes002.idr.e7, ufc = universes002.idr:45:11-48}-                ConstraintFC {uconstraint = ./universes002.idr.b1 < ./universes002.idr.c1, ufc = universes002.idr:3:6-10}-                ConstraintFC {uconstraint = ./universes002.idr.b1 <= ./universes002.idr.e7, ufc = universes002.idr:45:11-48}-                ConstraintFC {uconstraint = ./universes002.idr.d1 <= ./universes002.idr.b1, ufc = universes002.idr:3:6-10}-
+ test/universes002/expected.out view
@@ -0,0 +1,14 @@+universes002.idr:45:11-48:+   |+45 | russell = lemma (MkMPair (MkMPair R lemma) REFL) +   |           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+Universe inconsistency.+        Working on: ./universes002.idr.b1+        Old domain: (5,5)+        New domain: (5,4)+        Involved constraints: +                ConstraintFC {uconstraint = ./universes002.idr.b1 <= ./universes002.idr.e7, ufc = universes002.idr:45:11-48}+                ConstraintFC {uconstraint = ./universes002.idr.b1 < ./universes002.idr.c1, ufc = universes002.idr:3:6-10}+                ConstraintFC {uconstraint = ./universes002.idr.b1 <= ./universes002.idr.e7, ufc = universes002.idr:45:11-48}+                ConstraintFC {uconstraint = ./universes002.idr.d1 <= ./universes002.idr.b1, ufc = universes002.idr:3:6-10}+
− test/universes002/run 
@@ -1,3 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ universes002.idr --check-rm -f *.ibc
+ test/universes002/run.sh view
@@ -0,0 +1,3 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ universes002.idr --check+rm -f *.ibc
− test/views001/expected 
@@ -1,5 +0,0 @@-Sorting list-[1, 5, 5, 5, 5, 5, 9, 9, 9, 9, 9, 13, 13, 13, 13, 13, 13, 17, 17, 17, 17, 17, 21, 21, 21, 21, 21, 25, 29, 29, 29, 29, 29, 29, 29, 29, 33, 33, 33, 33, 33, 33, 37, 37, 37, 37, 37, 37, 37, 37, 37, 41, 41, 41, 45, 49, 53, 53, 53, 57, 57, 57, 57, 61, 61, 61, 61, 61, 61, 61, 65, 65, 65, 69, 69, 73, 73, 73, 73, 73, 77, 77, 77, 77, 81, 81, 85, 85, 85, 85, 89, 89, 93, 93, 93, 93, 97, 97, 97, 97]-[97, 97, 97, 97, 93, 93, 93, 93, 89, 89, 85, 85, 85, 85, 81, 81, 77, 77, 77, 77, 73, 73, 73, 73, 73, 69, 69, 65, 65, 65, 61, 61, 61, 61, 61, 61, 61, 57, 57, 57, 57, 53, 53, 53, 49, 45, 41, 41, 41, 37, 37, 37, 37, 37, 37, 37, 37, 37, 33, 33, 33, 33, 33, 33, 29, 29, 29, 29, 29, 29, 29, 29, 25, 21, 21, 21, 21, 21, 17, 17, 17, 17, 17, 13, 13, 13, 13, 13, 13, 9, 9, 9, 9, 9, 5, 5, 5, 5, 5, 1]-Sorting list-[1, 5, 5, 5, 5, 5, 9, 9, 9, 9, 9, 13, 13, 13, 13, 13, 13, 17, 17, 17, 17, 17, 21, 21, 21, 21, 21, 25, 29, 29, 29, 29, 29, 29, 29, 29, 33, 33, 33, 33, 33, 33, 37, 37, 37, 37, 37, 37, 37, 37, 37, 41, 41, 41, 45, 49, 53, 53, 53, 57, 57, 57, 57, 61, 61, 61, 61, 61, 61, 61, 65, 65, 65, 69, 69, 73, 73, 73, 73, 73, 77, 77, 77, 77, 81, 81, 85, 85, 85, 85, 89, 89, 93, 93, 93, 93, 97, 97, 97, 97]
+ test/views001/expected.out view
@@ -0,0 +1,5 @@+Sorting list+[1, 5, 5, 5, 5, 5, 9, 9, 9, 9, 9, 13, 13, 13, 13, 13, 13, 17, 17, 17, 17, 17, 21, 21, 21, 21, 21, 25, 29, 29, 29, 29, 29, 29, 29, 29, 33, 33, 33, 33, 33, 33, 37, 37, 37, 37, 37, 37, 37, 37, 37, 41, 41, 41, 45, 49, 53, 53, 53, 57, 57, 57, 57, 61, 61, 61, 61, 61, 61, 61, 65, 65, 65, 69, 69, 73, 73, 73, 73, 73, 77, 77, 77, 77, 81, 81, 85, 85, 85, 85, 89, 89, 93, 93, 93, 93, 97, 97, 97, 97]+[97, 97, 97, 97, 93, 93, 93, 93, 89, 89, 85, 85, 85, 85, 81, 81, 77, 77, 77, 77, 73, 73, 73, 73, 73, 69, 69, 65, 65, 65, 61, 61, 61, 61, 61, 61, 61, 57, 57, 57, 57, 53, 53, 53, 49, 45, 41, 41, 41, 37, 37, 37, 37, 37, 37, 37, 37, 37, 33, 33, 33, 33, 33, 33, 29, 29, 29, 29, 29, 29, 29, 29, 25, 21, 21, 21, 21, 21, 17, 17, 17, 17, 17, 13, 13, 13, 13, 13, 13, 9, 9, 9, 9, 9, 5, 5, 5, 5, 5, 1]+Sorting list+[1, 5, 5, 5, 5, 5, 9, 9, 9, 9, 9, 13, 13, 13, 13, 13, 13, 17, 17, 17, 17, 17, 21, 21, 21, 21, 21, 25, 29, 29, 29, 29, 29, 29, 29, 29, 33, 33, 33, 33, 33, 33, 37, 37, 37, 37, 37, 37, 37, 37, 37, 41, 41, 41, 45, 49, 53, 53, 53, 57, 57, 57, 57, 61, 61, 61, 61, 61, 61, 61, 65, 65, 65, 69, 69, 73, 73, 73, 73, 73, 77, 77, 77, 77, 81, 81, 85, 85, 85, 85, 89, 89, 93, 93, 93, 93, 97, 97, 97, 97]
− test/views001/run 
@@ -1,6 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ views001.idr -o views001-./views001-${IDRIS:-idris} $@ views001a.idr -o views001a-./views001a-rm -f views001 views001a *.ibc
+ test/views001/run.sh view
@@ -0,0 +1,6 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ views001.idr -o views001+./views001+${IDRIS:-idris} $@ views001a.idr -o views001a+./views001a+rm -f views001 views001a *.ibc
− test/views002/expected 
@@ -1,2 +0,0 @@-Sorting list-[1, 5, 5, 5, 5, 5, 9, 9, 9, 9, 9, 13, 13, 13, 13, 13, 13, 17, 17, 17, 17, 17, 21, 21, 21, 21, 21, 25, 29, 29, 29, 29, 29, 29, 29, 29, 33, 33, 33, 33, 33, 33, 37, 37, 37, 37, 37, 37, 37, 37, 37, 41, 41, 41, 45, 49, 53, 53, 53, 57, 57, 57, 57, 61, 61, 61, 61, 61, 61, 61, 65, 65, 65, 69, 69, 73, 73, 73, 73, 73, 77, 77, 77, 77, 81, 81, 85, 85, 85, 85, 89, 89, 93, 93, 93, 93, 97, 97, 97, 97]
+ test/views002/expected.out view
@@ -0,0 +1,2 @@+Sorting list+[1, 5, 5, 5, 5, 5, 9, 9, 9, 9, 9, 13, 13, 13, 13, 13, 13, 17, 17, 17, 17, 17, 21, 21, 21, 21, 21, 25, 29, 29, 29, 29, 29, 29, 29, 29, 33, 33, 33, 33, 33, 33, 37, 37, 37, 37, 37, 37, 37, 37, 37, 41, 41, 41, 45, 49, 53, 53, 53, 57, 57, 57, 57, 61, 61, 61, 61, 61, 61, 61, 65, 65, 65, 69, 69, 73, 73, 73, 73, 73, 77, 77, 77, 77, 81, 81, 85, 85, 85, 85, 89, 89, 93, 93, 93, 93, 97, 97, 97, 97]
− test/views002/run 
@@ -1,4 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ views002.idr -o views002-./views002-rm -f views002 *.ibc
+ test/views002/run.sh view
@@ -0,0 +1,4 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ views002.idr -o views002+./views002+rm -f views002 *.ibc
− test/views003/expected 
@@ -1,1 +0,0 @@-True
+ test/views003/expected.out view
@@ -0,0 +1,1 @@+True
− test/views003/run 
@@ -1,4 +0,0 @@-#!/usr/bin/env bash-${IDRIS:-idris} $@ views003.idr -o views003 --warnreach-./views003 10000-rm -f views003 *.ibc
+ test/views003/run.sh view
@@ -0,0 +1,4 @@+#!/usr/bin/env bash+${IDRIS:-idris} $@ views003.idr -o views003 --warnreach+./views003 10000+rm -f views003 *.ibc